Ursalink UG87, chirpstack and Device Time Request

fma · October 21, 2020, 1:59pm

Hello!

We are trying to sync the rtc of our device with lora network. The server seems to support it and it works flawless. Now here comes the trouble.

Recently we have bought ursalink UG87 gateways, they seem to work fine except that they do something to chirpstack server and DTR stops working. It seems to be related with the GPS configuration of the device.
If we configure packet forwarder to use GPS the server stops sending the correct timestamp:

But if we disable packet forwarder gps, it seems to work properly and the device syncs:

Is this a known issue or am i doing something wrong?
I have tested it with the latest chirpstack server version installed over docker, and our old chirpstack server (version 2.8.2)

Thanks in advance

brocaar · October 21, 2020, 2:02pm

Could you please post a screenshot of the timeSinceGPSEpoch of the received uplink and the returned timeSinceGPSEpoch in the downlink mac-command?

fma · October 21, 2020, 2:11pm

Hi Brocaar, thanks for the fast answer.

I have this logs. They are from this morning but they should be valid:

This is our UG87 Receiving data (The other gateways are NULL):
imagen

And this is the mac-command response:

And this is the mac-command response when the UG87 is disconnected (Working)

brocaar · October 21, 2020, 3:49pm

Please note the timeSinceGpsEpoch, this is not correct!

GPS Epoch is a continuous time system for all satellites and observation systems. It is represented in seconds since Jan 5, 1980

(frequency - What is GPS epoch? - Geographic Information Systems Stack Exchange)

Your gateway is reporting 2.308 seconds past this epoch!

fma · October 21, 2020, 5:26pm

Ooh, I see, as we suspected seems that the error is in the gateway and no LoRaServer. Will contact with Ursalink.

Thanks! Did not know how it was managed.

brocaar · October 21, 2020, 7:06pm

Is it using the Semtech UDP Packet Forwarder? In that case you could also confirm this by looking at the UDP packets (using tcpdump).

fma · October 22, 2020, 7:09am

It seems that Ursalink is using some kind of custom packet forwarder as it has implemented multi point.
The thing is that it seems to be on ursalink end, we tried with our multitech gateway and semtech packet forwarder (the one that we usually work with) and this is what we saw:

The first one is the Ursalink, the second one is one of our multitechs with tha gps enabled.
When this happends Chirpstack seems to work fine and sends the correct time to the device, I suspect that Ursalink is doing another thing with that “timeSinceEpoch” var as it is always a value between 1 and 3 seconds (Maybe time since sync?)

Ursalink seems to use some kind of OpenWRT SO and we cannot change the packet forwarder to do more tests. The only thing that’s left is reaching ursalink and asking them.

Thanks for the help