Logging realtime sensor data to flash

RE: Logging realtime sensor data to flash

Stefan Birnir Sverrisson — Wed, 29 Apr 2015 06:48:57 GMT

Yes, you are correct, it is not possible to store data in flash 100 times per second and advertise at the same time. What you could do is to store the data in RAM instead, i.e. in a variable. If you have bonded with the central device (Android device) then the peripheral should have all information about the central device. Then you could periodically perform direct advertising (ADV_DIRECT_IND), which will take maximum 1.28 seconds. It will try to connect directly with a specific central. For those 1.28 seconds, you can store ECG data in RAM. If the device has not connected after 1.28 seconds, you can store the RAM data in flash in order to preserve RAM space before advertising again. You could also advertise normally (ADV_IND slower advertising interval) and include only the specific central address in a whitelist for the advertising.

RE: Logging realtime sensor data to flash

augustio — Tue, 21 Apr 2015 13:24:02 GMT

Ok. How then can I implement this feature such that data is not lost when a remote device is not in range. The idea here is that I have a peripheral that transmits ECG data 100 times per second to an android device. When the connected android device goes out of range, the connection is lost and then the peripheral, which is nrf51822 should start saving the data to flash while at the same time waiting for the android device to reconnect. Is it possible for the android device, which already has the address of the peripheral from the former connection, to reconnect without the peripheral advertising? If not, how do I implement this feature? Thanks.

RE: Logging realtime sensor data to flash

Stefan Birnir Sverrisson — Tue, 21 Apr 2015 13:12:02 GMT

You should not do advertising and perform flash operation at the same time. This is ensured in i.e. the ble_app_hrs example in nRF51 SDK 6.1.0, see the advertising_start in main.c. Also in nRF51 SDK 8.0.0, see ble_advertising_start.

So if you want to flash application data, then stop advertising, perform the flash operations and then restart advertising again.

RE: Logging realtime sensor data to flash

Stefan Birnir Sverrisson — Tue, 21 Apr 2015 13:06:21 GMT

@Kosidinma There is a pstorage example here that uses 1.5 pages in flash (the pstorage_test_multipage_page_aligned function). I think the general rule to follow is to have blocks alligned with pages, i.e. to have block size e.g. 128 or 1024 bytes. Also note the two notes in the pstorage documentation:

*- In case blocks span across multiple flash pages update and clear of blocks might not work as expected

Loading, storing, updating and clearing of each block is supported. A single operation can not be requested for multiple blocks. However, clear is permitted on requested blocks. This is the only exception.*

RE: Logging realtime sensor data to flash

John — Tue, 21 Apr 2015 12:22:12 GMT

Sorry, I've never had to implement anything like this so I do not have an example. If you search this forum there are discussions touching on pstorage usage when the data spans more than one page.

RE: Logging realtime sensor data to flash

Kosidinma — Mon, 20 Apr 2015 23:26:26 GMT

Hi, please could you give a pstorage example code showing this? I need to write at least 20kb sensor data as the value changes, read and periodically send said values on instruction and then clear the flash on system off. Thank you, this would be very helpful as most of the code i've seen show storage of predefined data of small size( 10 blocks of 16 bytes of known value)

RE: Logging realtime sensor data to flash

John — Mon, 20 Apr 2015 12:15:36 GMT

Yes, that is certainly possible. You will have to decide on your approach as there are several ways to crack this nut. If you want to manage the flash yourself there are sd_flash_xxxxxx functions for writing, reading and erasing flash. If you want some abstraction and help managing the flash access you can use the pstorage utility and its API. I also believe there may be a higher level of abstraction through use of a device manager facility but I am not familiar with that.