Automatic Data Recovery - Time Stamps

LPWAN Industrial Gateways / Concentrators RAK7258
1

Issue: Date/Time Stamps for recovered data.

Setup: RAK7258 connected to Things network, Automatic data recovery toggled ON on the RAK7258

LoRa® Server: Things network

Details:
The Date/time stamps reflect the date/time the data is transfered to the things network and not the datatime of the actual recording made by the RAK Gateway…

Is there a way to fix this? / is there anyother date/time stamp somewhere in the messages that can be used?

data recovery
data recovery1019×401 23.3 KB

looking at the data stored, it does indeed store the data/time of the enteries sent/received and not the data/time recorded.

[
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-18T17:42:35.878387432Z”,
“watts”: 0
},
{
“amps”: 21.557,
“device_id”: “energysensor2”,
“raw”: “AUkBJFQ1AQAAAAA=”,
“time”: “2020-08-19T00:14:04.734433144Z”,
“watts”: 5173.679999999999
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.734485444Z”,
“watts”: 0
},
{
“amps”: 21.665,
“device_id”: “energysensor2”,
“raw”: “AUkBJFShAQAAAAA=”,
“time”: “2020-08-19T00:14:04.734525445Z”,
“watts”: 5199.599999999999
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.736019653Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.736121053Z”,
“watts”: 0
},
{
“amps”: 21.768,
“device_id”: “energysensor2”,
“raw”: “AUkBJFUIAQAAAAA=”,
“time”: “2020-08-19T00:14:04.801782706Z”,
“watts”: 5224.32
},
{
“amps”: 21.811,
“device_id”: “energysensor2”,
“raw”: “AUkBJFUzAQAAAAA=”,
“time”: “2020-08-19T00:14:04.803571016Z”,
“watts”: 5234.64
},
{
“amps”: 21.655,
“device_id”: “energysensor2”,
“raw”: “AUkBJFSXAQAAAAA=”,
“time”: “2020-08-19T00:14:04.803866217Z”,
“watts”: 5197.200000000001
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.803915118Z”,
“watts”: 0
},
{
“amps”: 21.923,
“device_id”: “energysensor2”,
“raw”: “AUkBJFWjAQAAAAA=”,
“time”: “2020-08-19T00:14:04.804012118Z”,
“watts”: 5261.5199999999995
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.804198419Z”,
“watts”: 0
},
{
“amps”: 21.849,
“device_id”: “energysensor2”,
“raw”: “AUkBJFVZAQAAAAA=”,
“time”: “2020-08-19T00:14:04.822211916Z”,
“watts”: 5243.76
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.822223916Z”,
“watts”: 0
},
{
“amps”: 21.9,
“device_id”: “energysensor2”,
“raw”: “AUkBJFWMAQAAAAA=”,
“time”: “2020-08-19T00:14:04.868951767Z”,
“watts”: 5256
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.870021773Z”,
“watts”: 0
},
{
“amps”: 21.779,
“device_id”: “energysensor2”,
“raw”: “AUkBJFUTAQAAAAA=”,
“time”: “2020-08-19T00:14:04.870213274Z”,
“watts”: 5226.96
},
{
“amps”: 21.891,
“device_id”: “energysensor2”,
“raw”: “AUkBJFWDAQAAAAA=”,
“time”: “2020-08-19T00:14:04.87130948Z”,
“watts”: 5253.839999999999
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.872241085Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.872419986Z”,
“watts”: 0
},
{
“amps”: 21.894,
“device_id”: “energysensor2”,
“raw”: “AUkBJFWGAQAAAAA=”,
“time”: “2020-08-19T00:14:04.872506687Z”,
“watts”: 5254.5599999999995
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.941156456Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.941190856Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.941712659Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.943102966Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.943134566Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor2”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.943165367Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:04.943676869Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:05.026639215Z”,
“watts”: 0
},
{
“amps”: 0,
“device_id”: “energysensor1”,
“raw”: “AUkBJAAAAQAAAAA=”,
“time”: “2020-08-19T00:14:05.026701416Z”,
“watts”: 0
},

2

Dear @jambo90210,

Maybe this forum can answer your question

image
image762×381 19 KB

3

This is expected behavior, and there really isn’t any “fix” for it using standard components.

The issue is that delayed submission of packets to a network server is simply not supported in the LoRaWAN spec, which provides for real-time operation only.

There’s simply no provision in the protocol from a gateway to a server to say “this is a delayed submission, consider it to have been received at time x and do not enforce frame counter rollback checks against it”

Given that there’s no way to submit delayed traffic properly, playing it back as if it had just been received creates two problems:

  • if the packets are played back out of order, or if the network server has seen a more recent packet from that node arriving through any other gateway, then it will silently ignore all packets with LoRaWAN header frame counts below or matching the highest it has yet seen.

  • packets are recorded with the time they were submitted to the network server, not the time they were received over the air.

Because this kind of of delayed playback is unsupported in the spec, there’s not really much you can do:

  • you could embed timing information from the node in the packet itself, or the if the transmission interval is fixed, figure out an approximate time based on the advance of the frame count from the last timely received packet

  • you could replace the software trying to do this with a custom solution, that adds a received time header and submits the delayed packets to a custom network server that is able to make use of this outsid-the-spec information

4

Aha, thanks for the confirmation, I was wondering if there was a constraint and not a product thing.