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.
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.
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.
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.
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.
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:
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?
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
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:
Then change SX1301_RESET_BCM_PIN=25 with SX1301_RESET_BCM_PIN=17
In a start.sh file and install with
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.
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.