Allow the use of USB connected GPS

[errolt]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Allow the use of USB connected GPSes. If the SX1302 HAL is used as-is, then it only enables UBlox binary messages on the UART port of the GPS. Even if the binary messages is enabled manually and saved to GPS flash, at startup the HAL disables binary messages on all ports except UART.

What is the use-case?

Adding a USB GPS to systems that doesn't ship with an integrated GPS, or that ships with a non Ublox GPS.

Implementation description

Fork the SX1302 HAL so that modifications can be made. The maintainers for the HAL cater for a very ideal world use case, and anything that diverge from that ideal case is ignored.

Once forked, during GPS init, enable ublox messages on all GPS ports, not just UART1

Can you implement this by yourself and make a pull request?

No, as the HAL needs to be forked.

[brocaar]

Actually, I already made some changes which makes this possible using gpsd (https://gpsd.gitlab.io/gpsd/). This was needed to support the latest Multitech Conduit firmware.

By directly using the /dev/ttyXXXX, only one process can read from the GNSS module. Using gpsd, multiple processed can consume from the gpsd. In the case of the Multitech Conduit firmware, the gpsd initializes the GNSS module on boot (including the UBlox binary messages for GPS time), and the Concentratord can directly consume from the gpsd, including receiving the UBlox binary messages (in this case, Concentratord / the HAL doesn't do any GNSS setup).

This is the commit which added support for gpsd to the sx1302: https://github.com/chirpstack/chirpstack-concentratord/commit/54aa840b605715f6784f62f343905908e91ead42.

---

Adding a USB GPS to systems that doesn't ship with an integrated GPS

Please note that this is likely not going to work as expected. The PPS (pulse per second) pin of the GNSS module must be connected to the SX1301/2/3 for accurate scheduling of downlinks and for the fine-timestamp.

... or that ships with a non Ublox GPS.

Please note that the reason why the Semtech HAL requires a Ublox module is because it can expose the GPS time using the binary Ublox format. The NMEA data gives you the UTC time, which includes leap-seconds. The GPS time does not include leap seconds and for this reason Class-B scheduling is based on GPS time, not UTC time.

Supporting non-Ublox modules would therefore require more work as it requires setting up the GNSS module to expose GPS time (if the module supports this at all), as well as parsing the non-standard NMEA output of this GNSS module.

[errolt]

This is the commit which added support for gpsd to the sx1302: 54aa840.

I saw that, but couldn't figure out what the difference is, as it still references a /dev/ttyXXX path.

Please note that the reason why the Semtech HAL requires a Ublox module is because it can expose the GPS time using the binary Ublox format. The NMEA data gives you the UTC time, which includes leap-seconds. The GPS time does not include leap seconds and for this reason Class-B scheduling is based on GPS time, not UTC time.

Yes, I have been through this before. My board(waveshare hat) has a GPS. The PPS pin is connected to the SX1302, it outputs valid ublox data, but the RMC message isn't standard and is rejected by HAL.

So I wanted to add a USB Ublox GPS to get the GPS time, for ClassB messages, letting the onboard GPS provide the PPS, but the USB GPS providing coordinates and GPS time.

Looks like it will be simpler to just stick with the modified HAL and the default Semtech packet forwarder.

PSA: Stay away from the Waveshare Lora hat.

[brocaar]

Btw, I have opened this issue: https://github.com/Lora-net/sx1302_hal/issues/92. I'm not sure if that will be accepted or not. If not, maybe it could be something to include in the Concentratord. In this case, maybe there isn't any need to use the Semtech HAL for GNSS reading / parsing, it could be done directly using Rust.

I saw that, but couldn't figure out what the difference is, as it still references a /dev/ttyXXX path.

It is an enum which could point to a path, to use gpsd you would set it to this: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/config/vendor/multitech/mtac_003e00.rs#L176

In this case it will connect to the localhost gpsd port.

[errolt]

Btw, I have opened this issue: Lora-net/sx1302_hal#92. I'm not sure if that will be accepted or not. If not, maybe it could be something to include in the Concentratord. In this case, maybe there isn't any need to use the Semtech HAL for GNSS reading / parsing, it could be done directly using Rust.

That would be great. Either implemented in HAL, or even better, HAL's GPS code just ignored and implemented in concentratord.

It is an enum which could point to a path, to use gpsd you would set it to this: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/config/vendor/multitech/mtac_003e00.rs#L176

Ahh, thanks. That now makes sense. Will try to implement that on my gateway.

[brocaar]

Just to let you know, we came to the conclusion that using the time from the NMEA data is not accurate enough. A binary protocol is needed for accurate time synchronization. Please see the above issue.