Per my other threads, I am looking to do some logging with a microcontroller system. The system 'may' have wifi connectivity but that is not guaranteed so retrieval of data may need to be forced at certain times only when invoked.
The intent is to determine how many days or months worth of data we can fit on a storage device and allow the system to scrub off old data as new comes in. This is assuming a "dump" of the data is never invoked in which there would be a 'wipe' of the storage device and let it start over.
Basically there are 2 objectives here. 1) have reasonable storage space so the intervals of retrieving data are reduced. 2) Always have a most recent log of data (example, past 2mo). We will be using this sort of like a 'black box', so in the event of a failure of the device we are monitoring, this would provide that snapshot back in time to see what caused the failure.
In some instances, what is likely is the uC system will be completely ignored, data never really retrieved, BUT if there is a failure, then and only then will the most recent data become useful and need to be retrieved.
I mention all this because I am not sure how to calculate or consider the amount of 'writes' and this framework has to be considered because we are trying to design around a 10yr life cycle. Because this device will be subjected to the elements, we intend to pot everything and having an SD slot may just create issues. If we did use SD, I might put it on the board, then just pot over it. EEPROM is being considered but curious if we have other options?
What I am considering is saving segments of data in volatile memory and moving that to the non-volatile memory in segments. But since we will be running on battery power, I need to think carefully so we don't lose any data.
Any thoughts on the type of memory to select here? I guess if we were moving data to memory 1x/day, 10yrs would only be 3600 writes. What is probably most important is rock solid reliability! If the storage device fails, because it is all potted, the entire device is mostly dead as a logging device.
The intent is to determine how many days or months worth of data we can fit on a storage device and allow the system to scrub off old data as new comes in. This is assuming a "dump" of the data is never invoked in which there would be a 'wipe' of the storage device and let it start over.
Basically there are 2 objectives here. 1) have reasonable storage space so the intervals of retrieving data are reduced. 2) Always have a most recent log of data (example, past 2mo). We will be using this sort of like a 'black box', so in the event of a failure of the device we are monitoring, this would provide that snapshot back in time to see what caused the failure.
In some instances, what is likely is the uC system will be completely ignored, data never really retrieved, BUT if there is a failure, then and only then will the most recent data become useful and need to be retrieved.
I mention all this because I am not sure how to calculate or consider the amount of 'writes' and this framework has to be considered because we are trying to design around a 10yr life cycle. Because this device will be subjected to the elements, we intend to pot everything and having an SD slot may just create issues. If we did use SD, I might put it on the board, then just pot over it. EEPROM is being considered but curious if we have other options?
What I am considering is saving segments of data in volatile memory and moving that to the non-volatile memory in segments. But since we will be running on battery power, I need to think carefully so we don't lose any data.
Any thoughts on the type of memory to select here? I guess if we were moving data to memory 1x/day, 10yrs would only be 3600 writes. What is probably most important is rock solid reliability! If the storage device fails, because it is all potted, the entire device is mostly dead as a logging device.