search

chirpstack / chirpstack-concentratord

Concentrator HAL daemon for LoRa gateways.
https://www.chirpstack.io/
MIT License
76 stars 57 forks source link

Add GPS support for Waveshare SX1302 hat. #30

Closed errolt closed 2 years ago

errolt commented 2 years ago

Summary

Please add support for the GPS on the Waveshare LORA shield.

What is the use-case?

To have location and time sync

Implementation description

The GPS on the Waveshare board seems to be an L76K GPS that has been reprogrammed to output Ublox binary and NMEA data. The only issue is that the RMC message contains an extra field at the end, before the CRC. This breaks the default SX1302_hal driver, for which I have created the following request/bug: https://github.com/Lora-net/sx1302_hal/issues/90

I can't figure out of this repo pulls in that sx1302_hal repo. Should the RMC issue be fixed in sx1302_hal before the GPS can be used in chirpstack, or can the issue be fixed in this repo?

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

Not yet. No documentation, that I can find, about building this repo.

brocaar commented 2 years ago

Yes, ideally this should be fixed in the SX1302 HAL first :-)

L76K GPS that has been reprogrammed to output Ublox binary

Do you have a source for this?

errolt commented 2 years ago

Do you have a source for this?

No, but the GPS is "weird". It seems to ignore all commands, such as to turn off some NMEA messages. Its binary format doesn't match the format in the L76K manual.

And, even though the binary format for the L76K does not match the UBLOX binary format(for starters, the start/sync chars doesn't match), for some reason the SX1302_HAL's ubx decoder successfully decodes the binary data from the L76K on the current Waveshare HAT.

So the only issue with the GPS on the waveshare hat is the 14'th field in the RMC decoder.

brocaar commented 2 years ago

for some reason the SX1302_HAL's ubx decoder successfully decodes the binary data from the L76K on the current Waveshare HAT.

Please note that the reason the HAL depends on the binary UBLOX interface is the GPS time. The time in the NMEA is the UTC time, which contains leap seconds. Class-B depends on the GPS time, which does not contain leap seconds. This is critical for Class-B, as the introduction of a new leap second would offset all Class-B ping slots. Unless devices are aware by this, it would break all communication.

To provide the GPS time, UBLOX provides a binary interface. Maybe the Semtech HAL does not throw errors on the binary output of the L76K, but does it decode the GPS time correctly?

Anyway, the best place to get this supported is in the Semtech HAL.

errolt commented 2 years ago

I'm not quite sure what the GPS time is supposed to be, but this is the output from the HAL with gps debugging enabled. GPS time seems to be +-18 seconds ahead of UCT?

Note: Valid RMC sentence, GPS locked, date: 2022-11-24T19:41:04.000Z
Warning: localization error processing not implemented yet
Note: ignored NMEA sentence
Note: ignored NMEA sentence
Note: ignored NMEA sentence
ERROR: TOO SHORT TO BE A VALID UBX MESSAGE
Note: parsing UBX frame> b5 62 01 20 10 00 d0 02 d3 18 
ERROR: UBX message incomplete
Note: parsing UBX frame> b5 62 01 20 10 00 d0 02 d3 18 03 00 00 00 bd 08 12 07 
ERROR: UBX message incomplete
Note: parsing UBX frame> b5 62 01 20 10 00 d0 02 d3 18 03 00 00 00 bd 08 12 07 0a 00 00 00 d9 6f 24 47 
  GPS time = 19:41:22
SUCCESS: UBX message decoded
sync successfull

I will ping back here to enable the GPS in the waveshare device profile once the HAL is fixed. https://github.com/chirpstack/chirpstack-concentratord/blob/1cf97500aa6b53e8f92bbfbe953df7570838dfe6/chirpstack-concentratord-sx1302/src/config/vendor/waveshare/sx1302_lorawan_gateway_hat_eu868.rs#L162

errolt commented 2 years ago

I see that https://github.com/Lora-net/sx1302_hal has not been updated in 18 months, so no hope in getting movement there.

aalku commented 7 months ago

Hello. What's the status on this? I am totally new in LoRa and I bought this module that uses the same driver, it is a hat too, and the GPS doesn't seem to work either but I don't know if it's for the same reason.

https://www.elecrow.com/lr1302-868m-915m-lorawan-hat-for-rpi-sx1302-long-range-module-support-rpi-1-2-3-4-5-series.html

I can open the serial port from ssh while the software is running, so I guess the port is not already open, and I get the NMEA strings from it, but I don't know how to tell chirpstack to use that serial port. I guess I can't because I would need a specific board definition for that hat and not to borrow one that seems to work. 😅 But I'm not sure of any of this and I don't really know if I need a new feature or the problem is the same as this one.

Thanks for any help you can give.