Concentratord PPS Drift and TOO_EARLY Rejection

Question

The setup I use:
Raspberry Pi 5, Seeed WM1302, L76K GPS Module
Chirpstack Gateway OS

DISTRIB_ID='ChirpStack Gateway OS'
DISTRIB_RELEASE='4.9.0'
DISTRIB_REVISION='r28959-29397011cc'
DISTRIB_TARGET='bcm27xx/bcm2712'
DISTRIB_ARCH='aarch64_cortex-a76'
DISTRIB_DESCRIPTION='ChirpStack Gateway OS 4.9.0 Base'
DISTRIB_TAINTS='no-all'

Using the Semtech - LoRa(R) CoreCell 868MHz (SX1302CSS868GW1) as shield model because somehow my L76K can emit u-blox messages.

From what I have seen this is a rather niche problem we have been facing:

When the GPS signal goes bad the PPS signal will fall behind, and it will drift away from the internal counter of the SX1302 (INST). However, when the GPS signal is back at healthy levels again the Concentratord can't seem to recover from the previous invalid timing state, which then leads all received downlinks (including the Class-B beacons) to be rejected with TOO_EARLY code because the GPS timestamp of the said downlink is scheduled so so far away from the internal counter of SX1302 (INST). That leaves the restart of the Concentratord as the only option for recovery.

The Semtech's lora_pkt_fwd did not handle this, and it seems like Concentratord does not handle it either so I believe a reliable way to detect this kind of invalid state ((INST - PPS) > Threshold, despite having healthy GPS fix) would at least enable user to react quicker and preemptively reset the internal counter by restarting the Concentratord.

Would love to hear your thoughts or any pointers to be able to implement this and contribute to the Concentratord.

Orne Brocaar · Answer

as shield model because somehow my L76K can emit u-blox messages

This has been mentioned before, but I never managed to make this work. As far as I know, there is no documentation stating that the L76K supports the u-blox.

It might as well be that this is the source of the problem. E.g. it looks like the uBlox binary protocol, but at some point it starts failing.

If you are interested in diving into how the time-sync works:

This is where it parses the uBlox binary data: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/handler/gps.rs#L99
After the binary data is handled by the Semtech HAL, this Concentratord function is called: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/handler/gps.rs#L280

If you set the log-level to TRACING, you should be able to see this log every second: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/handler/gps.rs#L311.

faruk · Answer

Hey @brocaar, I figured the problem is indeed the GPS module but not the way you think, the userspace GPS output is fully compatible with U-BLOX 7 (haven't verified byte-by-byte but haven't had a parsing issue so far either and Class B comm just works along with location). I believe Seeed is shipping their HATs with modified GPS firmware, because I can see some binary nonsense when I call cat /dev/ttyAMA0 along with the NMEA lines.

The problem however lies within how both modules handle the PPS signal. U-BLOX 7 basically locks to GPS time and maintains the 1 Hz PPS signal even if the signal dies later on, however the Quectel L76K uses the PPS pin to inform the receiver about loss of signal and does not maintain the 1 Hz waves. Which causes difference in INST and PPS within the SX1302. Since U-BLOX is practically not available in where I live, I am thinking about possible solutions to avert this and would love to have your comments on this as well.

Concentratord PPS Drift and TOO_EARLY Rejection

2 Answers