HTTP integration uplink JSON doesn't include timeSinceGpsEpoch

baz · December 19, 2018, 11:46am

Hello All,

I’ve been playing with the HTTP integration recently and have managed to receive packets sent from my device. However, in the ‘rxInfo’ section of the uplink JSON, there are a number of fields that are displayed in the loraserver GUI (live frames) that do not get sent via the HTTP integration POST.

The main field that I need is the timeSinceGpsEpoch as I need an accurate timestamp for the reception of the packet at the gateway. While testing, I can see (from the live frames page) that there is a 1 second difference between the ‘time’ and ‘timeSinceGpsEpoch’ fields.

Is there an easy way to include this field? Any suggestions will be gratefully received. I’m happy to try any mods or hacks to get it going, though I have no experience with Go.

Many thanks for any help you can give.
Barry

brocaar · December 19, 2018, 1:02pm

Please note that timeSinceGpsEpoch (used for Class-B) does not include leap-seconds, an UTC timestamp does have leap-seconds. This might explain the time difference you’re seeing?

Lwave · December 19, 2018, 1:04pm

Hi brocaar,

I have similar problem. Didn’t resolved yet. I am using RAK831 raspberry pi based gataway. I think that problem is on gateway site, but it obvious that GPS works well. There is screenshot of its log.

brocaar · December 19, 2018, 1:08pm

Why is is obvious that the GPS works well?

baz · December 19, 2018, 1:21pm

Thanks for your help. I’m not sure the issue is leap-seconds. I’m converting the timeSinceGpsEpoch value with the tool at: https://www.andrews.edu/~tzs/timeconv/timeconvert.php and it is coming out 1 second ahead of the value in ‘Time’. I guess there could be an issue there if it is an old tool. Unfortunately I’m not able to investigate further until tomorrow now.

Where is the ‘Time’ value generated? is it from the gateway timestamp or the system time when the packet is received by the forwarder?

Either way, I’m doing some time comparisons based on the beacon time, which is GPS time so it would be really helpful if there was a way to get timeSinceGpsEpoch via HTTP integration.

Thanks again,
Barry

brocaar · December 19, 2018, 1:28pm

The time comes from the gateway too: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L133. It should be equal to the time since GPS epoch duration.

You can find a tool to convert between the GPS epoch duration and timestamp here: https://github.com/brocaar/loraserver/blob/master/internal/gps/gps.go.

Lwave · December 19, 2018, 1:39pm

GPS works, because coordinates is updated automatically on appserver after registering gateway. I also looked that raspberry pi receives continuous correct NMEA data from ttyAMA0 serial port and in global_conf.json parameter “gps_tty_path”: “/dev/ttyAMA0” is correct.

brocaar · December 19, 2018, 1:48pm

Ok. That information I could not guess from your post Anyway, LoRa Gateway Bridge uses the data that is forwarded by the packet-forwarder. I recommend you use tcpdump to find out if the time field is populated (see also https://www.loraserver.io/guides/troubleshooting/gateway/). The first think to confirm is if the gateway is actually sending the time field.

Lwave · December 19, 2018, 1:56pm

Thanks lot,

I am also think that, problem i in gateway side.

Lwave · December 19, 2018, 3:12pm

This is the data from gateway TCP log.
{“rxpk”:[{“tmst”:4161007475,“chan”:0,“rfch”:1,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9.0,“rssi”:-32,“size”:34,

I think that, time from gateway is “tmst”, but that is the format to decode it?

On the other side i started mosquitto_sub, this is what is received:

application/2/device/03509000a0070be2/rx {“applicationID”:“2”,“applicationName”:“app”,“deviceName”:“STM32_Lora”,“devEUI”:“03509000a0070be2”,“txInfo”:{“frequency”:868300000,“dataRate”:{“modulation”:“LORA”,“bandwidth”:125,“spreadFactor”:7},“adr”:true,“codeRate”:“4/5”},“fCnt”:0,“fPort”:1,“data”:“LAAAAAAAAAAAAAAAAAAAAAAAAAAA”,“object”:{“1”:44,“2”:0,“3”:0,“4”:0}}

Why there is no time field in it?

brocaar · December 20, 2018, 11:04am

It is not, please see packet_forwarder/PROTOCOL.TXT at master · Lora-net/packet_forwarder · GitHub.

Lwave · December 20, 2018, 11:41am

Thanks,

Now i see that there is no tmms velue in json strim. So it sends system time default.
I changed loragateway and packet forwarder and using thingsnetworks gateway software and getting results like this.

baz · December 20, 2018, 12:32pm

Thanks for the link to the tool. Not sure how to use it, but I have manually checked the values and get the same thing:
lora-pkt

If you take the timeSinceGpsEpoch 1229340585 and add the UTC epoch offset 315964800, then subtract the 18 leap seconds, you get 1545305367 which is 2018-12-20 11:29:27 (not 11:29:26 as in the image).

Not sure where to go from here. What could be causing the difference? Is there anything I can test to debug the problem further? Or is it possible to add timeSinceGpsEpoch to the HTTP integration post data?

brocaar · December 20, 2018, 2:31pm

I recommend you post this at https://github.com/Lora-net/packet_forwarder/ and see if they can explain this. Maybe you have found a bug in the packet-forwarder?

I prefer to not add this to the HTTP integration as these timestamps should be equal and I prefer to not expose this field to the end-user. Once added, people start using it and removing will be impossible without breaking setups.

However, the source is open, so you could always add this yourself for testing

Yash_Pahwa · December 21, 2018, 7:31am

Could you please elaborate about the gateway and the software you changed, to make things work!

Also Could you please share the links to get proper software of TheThingsNetwork packet-forwarder.

Thanks in advance!

Lwave · December 21, 2018, 9:34am

I have RAK831 based gateway on raspberry pi. RAK831 gateway board came with adapter board, with GPS quectel L70 receiver soldered on it. At this time everything works except GPS epoch time. This will be compatibility problem between hardware and packet forwarder.
I am using this installer, this is a branch for master repository. You can download it with:

git clone -b spi https://github.com/ttn-zh/ic880a-gateway.git

Then change SX1301_RESET_BCM_PIN=25 with SX1301_RESET_BCM_PIN=17
In a start.sh file and install with

sudo ./install.sh

that’s it.

This installation scrip using legacy thingsnetwork gateway and packet forwarder. Actually they closed their packet forwarder repository and no longer supporting it, but i think that it’s still more recent one.

brocaar · December 21, 2018, 2:29pm

The L70 chip is not compatible with the Semtech packet-forwarder: https://github.com/Lora-net/lora_gateway#v500.

The first time I ordered my RAK381, I also received a convertor board with an L70. As their product page said it would ship with a u-blox GPS module, I asked for a replacement as this module is compatible with the packet-forwarder.

Lwave · December 21, 2018, 4:11pm

Very clear answer.

Thank you.

Yash_Pahwa · December 26, 2018, 5:25pm

It’s not working as per the semtech v2 reference design, but can this setup be used for the TDoA algorithm given in COLLOS? , as we are getting the time parameter!