beitler
commented
2 years ago Hi @upwis-gabriel, you are right to assess that the latency on your SPI interface is quite high. The time sync statistics quantify this assessment further:
2021-11-02 12:00:53.564 [SYN:INFO] Time sync qualities: min=665 q90=3045 max=3469 (previous q90=2431)
2021-11-02 12:01:38.894 [SYN:INFO] MCU/SX130X drift stats: min: -1.9ppm q50: +34.2ppm q80: +102.2ppm max: +139.7ppm - threshold q90: +138.2ppmThe time sync quality is basically the time it takes to read out a register from the sx130x (in milliseconds). In your case q90 of the time sync quality is between 2.5 and 3 seconds. This is beyond expected bounds. Also, the measured MCU drift is quite high with values around 140 ppm q90. This may also be an indication that the SPI transfers are also subject to significant jitter.
For your reference, here are the time sync quality and drift values rpi4-based corecell reference design:
[SYN:INFO] Time sync qualities: min=237 q90=242 max=260 (previous q90=259)
[SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: +0.0ppm q80: +0.5ppm max: +0.5ppm - threshold q90: +0.5ppmConcerning the PPS sync acquisition problem there seem to be a couple things wrong, but in summary it looks like the xtick register is definitely not latching on PPS. Judging by the xtime=0x82000080519E6E your gateway was running for 35 minutes, which matches your description. However, the observed latched xtick 0x82000100000000 is definitely not right as this value is in the future relative to your 'current' xtime - hence the negative value in this warning:
2021-11-02 12:33:58.665 [SYN:ERRO] No PPS pulse for ~-2138 secsHave you checked that the xtick register is latched on every PPS (assuming you have the GPS setting enabled in the HAL).
upwis-gabriel
smtc-bot
We were having issues with the time sync on the regular LoRa Packet Forwarder and figured that we'd try this one instead. The setup is as follows: The gateway is custom and based on a TI SOC. It is running ubuntu over a kernel by TI. This board is an expansion for an existing base gateway, so the I/O was limited. Because of that an FTDI usb-serial adapter is used to run both the SPI via MPSSE and the GPS serial port. By modifying libFTDI and libMPSSE to allow for microframes the SPI latency is fairly low, with several complete exchanges occurring within a millisecond. libloragateway was modified so that all the SPI HAL functions instead call on the MPSSE functions. The SPI communication tests from libloragw seem to work just fine. libloragw is taken from sx1302_hal 1.0.5 and further patched with the corecell patch from lgw1302. I also increased DFLT_TX_AIM_GAP to 50 ms in order to reduce the risk of latency being an issue. Basic Station connects to a chirpstack server on another device using chirpstack-gateway-bridge with authorization disabled. The following is the station.conf:
It seems to work for a while, but constantly prints about time sync being rejected. Here is a small sample of what it prints:
After about half an hour it seems to obtain the first PPS pulse (although I can see that the PPS pin on the RAK2287 is pulsing every second on a scope). Then it tries to time sync with the network server with what looks like completely incorrect times:
Time since last PPS seems to be negative, so something is off. Now, I realize this is not a supported gateway and the interface we're using is not ideal. But if anyone has an idea about what the issue could be or where to start looking that would be greatly appreciated.