Resend data when gateway back in view

NB I do not yet own a Sodaq ONE, and my kickstarter TTN gateway and Arduino nodes has not yet arrived, so my question is largely theoretical. I’ve been using Zigbee, Wifi, BT for some while however and I understand the limitations of LoRa node/gateway transmissions traffic.

I cannot see a similar question on this forum.

I want to attach a GPS to a piece of mobile equipment which may sometimes go out of range of my private LoRa network. Lets say I want to take a GPS reading every hour. Imagine that one day between midday and 3pm the gateway was not visible to the SodaqOne node attached to this equipment, at 4 pm the network was found, so the missing data can be resent.

My questions to you are these …

A. Where on the Sodaq ONE could I store GPS data and timestamp for those 3 message events? I see there is EEPROM, SRAM and FLASH

B. Which of these would be natural data storage and does it depend on how big my Arduino program is?

C. Has anyone come across a similar Arduino pattern like this before ?

In pseudocode this would be something like :


if GPS == true
  message = GPS reading + timestamp

if gateway available 
  send message
   if response true && message queue empty - quit
   else store message

if there are stored messages in queue
 foreach stored messages in queue
  send message

if gateway response not received
  store message in queue

sleep for another hour

I’d really like to achieve this without having to add SD card support because this would be another drag on battery and also become another failure point. I believe everything is do-able, but just wondered how simple it would be with a LoRaONE. I could accept that if battery ran out, the stored data would be lost.

This requirement seems not to have been addressed by other LoRa/GPS suppliers, and I wondered if I was alone in having it.


The biggest issue you have is that a single message depending on the spreadingfactor have limitations in size and airtime.

When you need a SD card for storage you will have too much data to transmit.
ACK also will eat airtime.

How critical is the data you send? Maybe its ok to loose some data and send an average of the data with the new data every time?