Hi I’m testing the Automatic Data Recovery feature on RAK7258 GW.
The GW was offline for 40 mins and then reconnected.
I’ve not seen any buffered messages sent.
My end-device sends every 10 mins
I have a Copy of data_recovery file after Wan re-connection but can’t upload this to forum.
Any ideas? Also what chance of a tool that allowed offline reading of data_recovery file which looks like a custom fomat.
Lawrence
Hei @iiLaw,
Can I ask for a bit more info.
Firmware Version.
Can you attach the log, a link to a cloud storage should do.
You should have seen the packets that are to be buffed in red in the logger and the ones that are forwarded after the connection was restored from the buffer in green, in theory atleast.
Any chance the issue is in the SD card ? (kind of a dumb question, but just making sure we have it all covered).
I will try to replicate the issue and see what happens.
Regards
Vladislav
Hi a few questions the GW had an 16 GB SD card in it?
Does it ship with one?
There are Log files form 2019 … I’m wondering if this is an old SD card left in the GW?
Log questions:
Are logs managed OR does the disk just fill up?
If managed what is the purge strategy?
when are logs written to disk looks like every 24 hrs ish?
how do you view current log that are NOT written?
The last log file ends an hour before my testing yesterday so have NO logs for my test!
BTW log level set at Notice do you want me to set to Debug and run the test again?
I’m wondering if I’ve got a defective unit I had to run some cmd line sht to get the cellular interface working.
// log and data recovery
RAK GW: V1.1.0062_Release_r202
LNS: TTI v3.8.4
Ok I did a 4 hour outage and it worked 
// A bit off topic but feel relevant
In TTI rx_metadata in TTI data API the time stamp is unusable. I though would be usable if a the GW has a good Stat connection for timing?
timestamp: 711839427
received_at LNS : “2020-06-27T16:45:28.165046968Z”
For periodic data I can rebuild timestamps based on framecount but not for asyn uplinks.
Lawrence
You are probably confusing the rolling microsecond timer with a calendar-clock-timer which it is not meant to be. Essentially it measures (32-bit rolling) microseconds since the last fresh start of the concentrator chip, uncorrelated to anything else. Though given historical context you might be able to approximately correlate it after the fact, unless there’s a concentrator restart it presumably won’t drift that much.
Stats messages are uplink direction only and do not include any concentrator timing information.
Chris, I’m always learning so many thanks for your response.
I’ve known that the TS was usable but not why!
It’s clear I don’t have clue on the role of GNSS at the GW as don’t do locational stuff.
Given that most device I work with have different payload signatures for periodic and event uplinks I think I can do an acceptable job of recreating. The RAK store and forward feature helps with the vagaries of Cellular operators who have numerous ways of killing your backhall.
Lawrence
Another option to consider is running instead your own software on the gateway which saves what you actually need.
Chris we’ve done that for many years with Multitech AEP which has LNS and Node-RED as App server where we have a basic store and forward feature. But that is to a cloud end-point say on AWS IoT.
I used basic station for a year and half before Tracknet were brought out by Semtech.
It was rock solid so that is a the destination for Gateways. The RAK store & forward is a plus but about to start deploying in Africa where this feature might become more critical.