Lora network-server received messages : timestamps

[Brian Wyld]

Hi,

I’m using the UDP messages sent by the lora network server (AppPortUp=1784), and would like to know exactly when the lora frame was received.
There are 2 timestamps in the JSON.
The first one:
“timestamp”:”2015-12-28T17:25:16Z”
is “real” formatted clock time, but only accurate to the nearest second. The other one:
“tmst”:3173772811
is more accurate (ms?) and exactly what I want (ts of the end of the reception of the frame). But as it’s not the usual ‘ms since epoch’, I can’t see how to relate it to the “real” time….

Is there a way to get ‘timestamp’ to be ms accuracy? Or to relate ‘tmst’ to clock time?

thanks in advance

Brian

[Jason Reiss]

The “tmst” value is a timestamp internal to the packet-forwarder processes. The network server uses this value to schedule the downlink packets.

The “timestamp” value is added by the network server when it receives the UDP packet from the forwarder.

We could include the ms in the timestamp but the would not accurately represent the exact received time of the frame at the radio.

The “tmst” value is a clock from the start of packet-forwarder, you could reference the process start time. But this time is in second resolution so not accurate to ms.

> ps -eo pid,comm,lstart

[Brian Wyld]

Hi,

Ok… Any reason why the tmst value is not just ms since epoch? Any chance it could be?

Brian

[Brian Wyld]

Hi Jason,

I’m trying to use the tmst value : what units is it? ms? uS?
The ‘info’ for the lora rx object in nodeRED says just
“Internal timestamp of “RX finished” event (32b unsigned)”

thanks for any info on this…

Brian

[Jason Reiss]

It is in micro-seconds.

[Brian Wyld]

Ok, thanks.
Looking at the code of the pkt_forwarder, it seems that it creates a timestamp to ms precision (‘time’) in the packet it forwards. However, the lora-network-server doesn’t pass this data on after it has processed the packet?

thanks

Brian

[Brian Wyld]

Hi Jason,

It’d be much nicer if the network-server just passed on the ‘time’ attribute from the pkt-forwarder as the rx time : more accurate and closer to the radio reception…

I’ve been trying to use the tmst value together with the timestamp to get a more accurate timestamp, but now I’ve discovered that the drift in the tmst value is very high : something like 15-25ms per minute! I was trying to use this to sync my objects to 1-2ms precision, but this kind of drift makes that impossible…

Any ideas on how to get a 1 or 2ms precision rx timestamp on these packets?

thanks

Brian

[Jason Reiss]

We can pass the full value from the packet forwarder in a future version. Not sure on a time table at the moment however.

[Brian Wyld]

Ok.. Added to the requests about the management of the tx queue I guess I can make a list…

I’d like to update to 0.0.9. I see the release notes,but I can’t see the package (latest referenced on the downloads page is 0.0.8). Can you give me the good url for the package please?

thanks

Brian

[Jason Reiss]

The downloads page has been updated.
http://www.multitech.net/developer/downloads/

[Brian Wyld]

Ok thanks! I’ll see if that fixes my ‘delayed downlink’ issue…

A+

brian

[Brian Wyld]

Hi Jason,

I’ve upgraded to 0.0.9, no particular issues, but no fixes for my problem of ‘no tx’….

My main problem is that I’m really stuck here without having the ‘time’ attribute coming through from the pkt-forwarder into the decoded /up stream. I can’t get my application to sync up its objects without this….

Is there a way to get a fast-tracked build of lora-network-server with this feature?

thanks!

Brian

[Jason Reiss]

Please open a case at https://support.multitech.com/ to share more info of your ‘no tx’ issue and see about getting dev build.

[Brian Wyld]

Hi Jason,

I opened 5067328 and 5067329 for the ‘tx’ and ‘timestamp’ issues.

Thanks

Brian

[Author]

Posts