NHS3100 endurance

[martinsmarco]

Dear Support

After reading the NHS3100 documentation, I understood that the device stores data in the eeprom and then moves it to Flash.

Assuming a logger application where all measurement are to be stored, and a sampling rate of one sample per minute is desired, the EEPROM endurance will limit the lifetime of the device to <10 days. (1 sample/min = 1440samples/day= 14400 samples/10 day)

Is this coorect?

Thanks in advance

[driesmoors]

Hi,

Both the Flash and the EEPROM have a guaranteed endurance limit of 10k writes (although in all practical use cases, the effective number will be much higher). For EEPROM, this limit applies on each page. EEPROM is divided in 64 pages of 64 bytes each, of which the lower 58 pages are free for the application to use.

Assuming one sample occupies a full 16 bits, you can thus reach the theoretical limit of 580.000 samples (let's ignore the fact that there won't be enough Flash space available to move the filled EEPROM rows to).

It gets a bit trickier if you want to store some housekeeping in EEPROM, e.g. the number of samples already stored. This cannot be stored on a fixed location if your use case wants to store more than 10.000 samples.

The SDK provides a so-called 'storage' module to overcome this: it will ensure that EEPROM and Flash can be fully filled with samples, allows non-aligned samples widths (e.g. 11 bits) without adding padding bits, and provides a possibility to compress the data before it is being moved from EEPROM to Flash. It will store some housekeeping values in EEPROM to ensure all samples can still be read out even after a power loss, while guaranteeing the endurance limit will never be hit.

Using the storage module, you can thus store samples without worrying about the endurance limit. More information about the storage module can be found in the html documentation: see docs/FirmwareDevelopmentDocumentation/index.html in the SDK.

Best regards,
Dries.

[martinsmarco]

Hi Dries

Thanks for your reply

Could you clarify the 580.000 samples? I'm sorry but it was not clear to me how you reach that number.

Regarding the logger application: assuming a samples (let say 16bit) every minute, the firmware is writing a this value to the EEPROM and once reaching a specified limit will move it to the Flash. Is this correct?

Every time a sample is stored in the EEPROM, a full EEPROM page is "energized", correct? Is the consecutive sample stored in the same EEPROM Page?

From the storage module documentation I'm not able to retrieve this info..

Thanks again

Marco

[driesmoors]

Hello martinsmarco,

With a minimum of 10.000 writes per page, and 58 EEPROM pages at your proposal, there is a theoretical limit of 58 * 10.000 samples that can be stored, provided they are 16-bit and all have to pass via EEPROM. It is a ridiculously high number, only mentioned to assure you we are able to store a large amount of samples.

The storage module will write the samples back to back. And indeed, as per my understanding, writing to an address 'energizes' the whole page it is part of.

Suppose you assign 3 kB of EEPROM as data storage (see storage_dft.h). Then data will be stored, in that area, packed, from low to high address. Whenever the amount of data is bigger than a configurable limit, or when the assigned EEPROM space is full, all data is then 'flushed' to Flash. After that, EEPROM can be re-used. With 3kB of assigned EEPROM space, and a sample width of 16 bits, there are ~1500 samples that can be stored in EEPROM before it must be dumped in Flash. Depending on your compression algorithm (if you have one) and your free Flash space, this can then be repeated a number of times. Say, 20. This would then give you a maximum of ~20*1500 samples (stored in Flash) + ~1500 samples (stored in EEPROM) = ~31500 samples.

There are a large number of parameters that can be tweaked to increase this number. For instance, changing the bit-width of a sample from 16 bits to 15 bits will immediately give you a gain of more than 3000 extra samples that can be stored. See docs/1018DataStorage.pdf for some more information.

Also, starting from SDK v9, the TLogger firmware application has implemented an example (lossless) compression algorithm that you can easily disable or enable in firmware.

I hope this clarifies somewhat,
Best regards,
Dries.