Interesting – I would treat the logging the SD as just a step on the way to having it registered on the remote site database/cloud – whatever the transmission method.
I’ve done it in the past on a serial SPI flash, with two pointers, one for the next log sample and then a following pointer for what was last
ACKed remotely. It works because its direct access on the serial flash – not a file. This also allowed a UDP type packet in a mesh XPB 900Mhz network
Since ram is likely to be a limitation, and persistent storage is SD card, I would think it needs be stored on the SD card.
For an SD, maybe a way would be if the sensor reading transmission isn’t successful (ie never attempted, or not ACKed from the remote site) for whatever reason, its stored in a separate SD file <reading_staged.json> .
The logging happens as per defined schedule. The wireless connection also has an algorithm for connection attempts. (ie attempt connect every 4th logging interval, or every 24hrs, AND only if there is adequate power [battery voltage] -so makes extended solar loss more manageable)
Then when a connection attempt to the remote site is successful, if the file <reading_staged.json> exists, the current reading is written on to the end of the file. Then renamed to <reading_upload.json> and transmitted sequentially from the file.
If the connection is lost halfway through, then any undelivered records are written to <reading_staged.json>, and delete <reading_upload.json>.
Just an idea.
What I’ve also found useful is a <record_num>, and that has enabled me visually audit on the cloud database to see if there are missing records.
Well easy to have ideas. Still working my way through.
I get the Digi WiFi XB2B-WFWT-001 and the new Digi CAT-M1 XB3-C-A2-UT-001 Xbees on Thursday. THe Cat-M1 is very exciting from the power point of view as its designed for data delivery and faster to connect to the cell power from power off.