Gateway unable to run Class B without time source

Gateways Dragino Gateways
1

I have the same problem with LPS8V2. This looks like the primary suspect:

... [S2E:INFO] Beaconing every 2m8s on 869.525MHz(1) @ DR3 (frame layout 2/8/17)
... [S2E:INFO] Beaconing suspend - missing GPS data: time 
... [___:INFO] CoreCell reset through GPIO20...
lgw_stop:1202:  --- IN
Note: LoRa concentrator was not started...

If i understand correctly the GW bases the time for class B beaconing on the GPS time, which it doesn’t get since there’s no builtin GPS.
In turn the whole LoRa stack resets.
I e-mailed their tech support and I’m waiting for the response.

2

That’s a bit of a stretch for a thread hijack - read a bit more of the forum and you can start your own topic!

However, moved to own topic!

As you’ve surmised that you need a GNSS time source to run Class B, what do you anticipate Dragino is going to say when they respond?

3

Thanks for the warning.

Dragino tech support did answer with some follow up questions and I sent them a reply with detailed logs and this quick analysis.

You can see that each reset causes the ‘Disconnect gateway’ event in TTN (timestamps are 2h apart due to timezone)

Gateway log TTN Console live data Time difference
2024-08-28 07:17:31.440 [___:INFO] CoreCell reset through GPIO20… 9:17:48 Disconnect gateway 17s
2024-08-28 07:17:49.039 [CUP:INFO] Connecting to CUPS … https://eu1.cloud.thethings.network:443 (try #1) 9:17:49 Connect gateway 0s
2024-08-28 07:17:57.160 [___:INFO] CoreCell reset through GPIO20… 9:18:14 Disconnect gateway 17s
2024-08-28 07:18:14.666 [CUP:INFO] Connecting to CUPS … https://eu1.cloud.thethings.network:443 (try #1) 9:18:15 Connect gateway 1s
2024-08-28 07:18:22.785 [___:INFO] CoreCell reset through GPIO20… 9:19:05 Disconnect gateway 43s
2024-08-28 07:19:05.861 [CUP:INFO] Connecting to CUPS … https://eu1.cloud.thethings.network:443 (try #1) 9:19:06 Connect gateway 1s
2024-08-28 07:19:13.970 [___:INFO] CoreCell reset through GPIO20… 9:19:31 Disconnect gateway 18s
2024-08-28 07:19:31.510 [CUP:INFO] Connecting to CUPS … https://eu1.cloud.thethings.network:443 (try #1) 9:19:32 Connect gateway 1s

About 17s after each of the CoreCell reset through GPIO20 events, the TTN gets the Gateway Disconnect. Then the Gateway reconnects using CUPS and the TTN registers a GW Connected event about a second after.

4

Can you check if there’s a disconnect event in The Things Stack Console? Errors would probably be logged there.

5

The OP appears to have edited his post to say that there are disconnects showing in the console.

Which given the gateway resets isn’t total news.

Sadly we still appear to have the reality disconnect of Class B on a gateway with no GPS but no acknowledgement of such.

8

If the gateways lorawan stack (BasicsStation) resets because of the missing GPS sync (because of a missing GPS) it is not surprising the gateway disconnects at TTN. Effectively the software that creates the connection exits so the connecting is disrupted.

Why is the software configured to use class B beaconing if the hardware required is missing a required component? What suggestions did you get from Dragino support?

9

There is also the potential issue of the Fair Use Policy

10

So after some e-mails with Dragino we discovered the underlying issue.

There seems to be a bug in timezone settings and the gateway only functions correctly when it’s set to UTC timezone. Once that was set everything is working as expected.

B-class beaconing symptom was just a side effect of the GW being unable to determine UTC time (apparently due to failed TZ conversion). Then the GW switched to fallback method to get the time - GPS (which it doesn’t have).

I do believe this would also solve the hijacked thread’s problem as it was a firmware issue all along.

1 Like
11

That’s a nasty issue to have and debug. Glad it has been resolved.

1 Like
12

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.