Selecting PCB mounted storage device for logging. Options and pros/cons?

[fastline]

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.

 

[Visitor]

You left out one critical detail – how much storage is required?

 

[rjenkinsgb]

My first thought is a FRAM (Ferroelectric) memory.

They are not as cheap as flash or eeprom, but have extremely fast and near unlimited write capability and exceptional data retention.

Example:

https://www.mouser.co.uk/datasheet/2/100/001-84499_FM25V10_1_Mbit_128K_X_8_Serial_SPI_F_RAM-915634.pdf

 

[fastline]

Sorry, I left out the storage size because we don't yet know how much might be required. There will be two ways to obtain data. One is time based in which only a single sensor read per day would be acceptable. Otherwise there will be a trigger to only log when the DUT is working. Once that occurs, the DUT could run for 1min, or run for hours. In those cases, we might log the first 5min of operation with a data pull every 10sec, then no other data logged until DUT turns off, then log every 10sec for the following 5min. These are not firm settings and there will be a lot of other variables so we are not logging senseless data.

The DUT might only run 3-4x/day, or might not run at all for days. However the DUT could run for many hours but we will be doing a cross check for sensor inputs so if the readings stay relatively the same, there would be no need to log more points until the DUT turns off.

Each data pull would basically record a reading from a couple sensors, and a real time stamp.

I would say we would like to get as much memory as practical but nothing we are doing should take too much memory. I would say really 1M would probably gather a ton of data, but if we can get 1G for nearly the same price, why not....

 

[Les Jones]

Have you considered using a microcontroller system. to capture the data and send that via a serial link to a Raspberry Pi. You could write a program in "C" to run on the Raspberry Pi to write the data to an SD card.

Les.

 

[fastline]

This is a battery device so we are on a strict power diet and need to keep things as lean as practical.

 

[Nigel Goodwin]

This is a battery device so we are on a strict power diet and need to keep things as lean as practical.

Adding a PI for no reason would be a bit silly

Just write to an SD card direct from the micro - or as already mentioned, use a FRAM as they are fast and hassle free. As you're intending to pot, a FRAM (or multiple FRAM's) sounds a good idea.

However, you need to work out what your requirements actually are, rather than just randomly making it as large as you can.

As you're essentially wanting a 'black box', why not just buy one? - they are freely available for drones etc. and simply write all the serial data to a micro SD card. The units are Arduino based, EXTREMELY tiny (about the size of a micro SD card), simple to use, dead cheap and come with source code so you can mod it as required. Be aware, that sometimes they come unprogrammed - and have no programming interface (for size reasons) - something to be aware of.

Openlog Black Box Flight Data Recorder Setup Guide

In this guide we will walk you through the process of how to install and setup your openlog black box flight data recorder for your naze32 (or similar) flight controller. If you purchased your unit from Unmanned Tech, then it will already come with a recent version of the black box firmware...

www.dronetrest.com