Ensuring fail-safe data storage in battery-powered IoT sensor nodes


February 02, 2019

Nilesh BadodekarGirija chougala,-February 02, 2019

The antenna power of a BLE system depends directly on how often the sensor node is trying to ‘connect’ and upload data to a hub. While BLE can support the upload of ~500 bytes every 10ms, rarely does a sensor node collect data at this 50KB/s rate. Typical environmental parameter sensing systems capture 100-500 bytes/s, depending upon the sensing element. This allows the BLE system to be designed for longer connection intervals to increase battery life. Longer connection intervals force the system to store logs of more data points than a system that has the freedom to upload data at will. Typical internal memory of an IoT controller ranges from 64Kbytes to 256Kbytes and major portions of this memory is occupied by the BLE stack and user APIs required for performing ADC and other housekeeping tasks on the node. This causes the system to run out of internal memory when storing the data logs, so logs must often be stored in external memory.

Since IoT sensor nodes are battery powered, external memory must be non-volatile to ensure data reliability. While there are a wide range of non-volatile technologies in the market, system designers prefer using a memory that offers a simple interface and the best reliability. The most common candidates for external non-volatile memory are EEPROM, Flash, and ferroelectric RAM (F-RAM). However, because Flash/EEPROM technologies were originally designed to offer good read performance, there are have severe drawbacks when they are continuously written to.

A Flash cell can be “programmed” to contain new data only if the cell is erased beforehand. Programming a cell allows a change of state from logic ‘1’ to logic ‘0’. During the next update, if the cell needs to hold a logic ‘1’, the cell must first be erased.  To optimize erase speed and program times, Flash manufacturers use different page, block, and sector architectures. A page is the smallest quantum of data that can be programmed into the flash at one time. Flash devices contain an internal page size buffer that allows for temporary storage of data and once transfer from the external interface is complete, the device initiates a page program operation on a page that is already erased in the main array. If this page contains old data, it must be erased prior to a program operation.

Every time an erase is performed, the Flash cell deteriorates, which is quantified as endurance in a Flash datasheet. Typically, the best Flash devices are rated for endurance cycling of one hundred thousand erase-program cycles, after which they are no longer guaranteed to reliably store data. While this number appears large, we will demonstrate that this endurance falls short even in low-end data logging systems.

Some manufacturers implement byte programming and delayed programming from buffer to Flash memory. While these features do simplify the program operation into the device, they do not address Flash’s underlying endurance limitations. To compensate for these limitations, the system designer is forced to implement a complex file system to handle wear leveling of cells that also adds overhead and slows down the system. Similar drawbacks exist for EEPROMs.

We designed three systems based on F-RAM, EEPROM, and Flash that emulate typical IoT sensor data-logging behavior by performing data-acquisition of parameters like temperature, humidity, pressure, and acceleration. These systems were optimized using the best BLE connection interval and identical local storage algorithms. For the purpose of simplicity, we selected a slow BLE connection interval of 4 seconds and a data sampling rate of 100 bytes/s. Every sample consists of a snapshot of all the sensor data as well as a few marker bytes that will allow the receiving hub to parse the information and provide feedback to the operator.

Figure 3: F-RAM-based IoT Sensor Node. (Source: Cypress)

Figure 4: Flash-based IoT Sensor Node. (Source: Cypress)

Figure 5: EEPROM-based IoT Sensor Node. (Source: Cypress)

< Previous
Page 2 of 3
Next >

Loading comments...