Issue with GPS Synchronization in LoRa Packet Forwarder-waveshare SX1302 pi Hat

[ABHITHLALC]

Greeting, I am encountering difficulties with GPS synchronization in the Lora gateway. My hardware setup is: Raspberry Pi 3B+ and SX1302 LoRaWAN Gateway HAT by waveshare. I've successfully connected to TTN and can forward Lora packets to the network server without any issues. However, I'm having trouble getting GPS coordinates from the Lora gateway. It keeps showing a synchronization warning. Did I miss any additional required configurations to retrieve GPS data?

I have used sudo cat /dev/ttyS0 command for checking GPS port and getting this value

$GLGSV,3,2,09,69,45,304,19,88,15,054,32,81,36,109,24,67,16,171,,0*77
$GLGSV,3,3,09,68,57,213,15,0*48
$GNRMC,052330.000,A,1057.27606,N,07619.38087,E,0.00,190.74,140224,,,A,V*0C
$GNVTG,190.74,T,,M,0.00,N,0.00,K,A*28
$GNZDA,052330.000,14,02,2024,00,00*4C
$GPTXT,01,01,01,ANTENNA OK*35
▒b ▒▒▒;▒$GNGGA,052331.000,1057.27606,N,07619.38087,E,1,20,0.6,81.2,M,-92.9,M,,*5F
$GNGLL,1057.27606,N,07619.38087,E,052331.000,A,A*4A
$GNGSA,A,3,02,03,04,07,08,09,14,17,21,22,30,194,1.2,0.6,1.1,1*08
$GNGSA,A,3,78,80,79,69,88,81,,,,,,,1.2,0.6,1.1,2*38
$GPGSV,4,1,15,01,,,29,02,24,121,38,03,05,164,17,04,43,148,27,0*5B
$GPGSV,4,2,15,07,37,355,40,08,38,043,35,09,83,217,22,14,35,280,31,0*6C
$GPGSV,4,3,15,17,28,203,27,21,21,105,35,22,23,260,25,30,20,325,37,0*6F
$GPGSV,4,4,15,194,16,053,41,195,17,083,32,199,31,099,28,0*61
$GLGSV,3,1,09,78,13,036,35,82,21,163,,80,11,292,31,79,25,344,27,0*7D
$GLGSV,3,2,09,69,45,304,22,88,15,054,32,81,36,109,24,67,16,171,,0*7F
$GLGSV,3,3,09,68,57,213,15,0*48
$GNRMC,052331.000,A,1057.27606,N,07619.38087,E,0.00,190.74,140224,,,A,V*0D
$GNVTG,190.74,T,,M,0.00,N,0.00,K,A*28
$GNZDA,052331.000,14,02,2024,00,00*4D
$GPTXT,01,01,01,ANTENNA OK*35

The part of the config file is:

"gateway_conf": {
        "gateway_ID": "0016C001F10AC60C",
        /* change with default server address/ports */
        "server_address": "eu1.cloud.thethings.network",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        /* adjust the following parameters for your network */
        "keepalive_interval": 10,
        "stat_interval": 30,
        "push_timeout_ms": 100,
        /* forward only valid packets */
        "forward_crc_valid": true,
        "forward_crc_error": false,
        "forward_crc_disabled": false,
        /* GPS configuration */
        "gps_tty_path": "/dev/ttyS0",
        /* GPS reference coordinates */
        "ref_latitude": 0.0,
        "ref_longitude": 0.0,
        "ref_altitude": 0.0,
        /* Beaconing parameters */
        "beacon_period": 0,
        "beacon_freq_hz": 869525000,
        "beacon_datarate": 9,
        "beacon_bw_hz": 125000,
        "beacon_power": 14,
        "beacon_infodesc": 0
    },

And these are the terminal logs after running the packet forwarder

pi@raspberrypi:~/Documents/sx1302_hal/packet_forwarder $ sudo ./lora_pkt_fwd -c test_conf
*** Packet Forwarder ***
Version: 2.1.0
*** SX1302 HAL library version info ***
Version: 2.1.0;
***
INFO: Little endian host
INFO: found configuration file test_conf, parsing it
INFO: test_conf does contain a JSON object named SX130x_conf, parsing SX1302 parameters
INFO: com_type SPI, com_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
INFO: antenna_gain 0 dBi
INFO: Configuring legacy timestamp
INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
INFO: radio 0 enabled (type SX1250), center frequency 867500000, RSSI offset -215.399994, tx enabled 1, single input mode 0
INFO: radio 1 enabled (type SX1250), center frequency 868500000, RSSI offset -215.399994, tx enabled 0, single input mode 0
INFO: Lora multi-SF channel 0>  radio 1, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1>  radio 1, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2>  radio 1, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4>  radio 0, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5>  radio 0, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6>  radio 0, IF 200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7>  radio 0, IF 400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7, Explicit header
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: test_conf does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to 0016C001F10AC60C
INFO: server hostname or IP address is configured to "eu1.cloud.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: GPS serial port path is configured to "/dev/ttyS0"
INFO: Reference latitude is configured to 0.000000 deg
INFO: Reference longitude is configured to 0.000000 deg
INFO: Reference altitude is configured to 0 meters
INFO: Beaconing period is configured to 0 seconds
INFO: Beaconing signal will be emitted at 869525000 Hz
INFO: Beaconing datarate is set to SF9
INFO: Beaconing modulation bandwidth is set to 125000Hz
INFO: Beaconing TX power is set to 14dBm
INFO: Beaconing information descriptor is set to 0
INFO: test_conf does contain a JSON object named debug_conf, parsing debug parameters
INFO: got 2 debug reference payload
INFO: reference payload ID 0 is 0xCAFE1234
INFO: reference payload ID 1 is 0xCAFE2345
INFO: setting debug log file name to loragw_hal.log
INFO: [main] TTY port /dev/ttyS0 open for GPS synchronization
CoreCell reset through GPIO23...
SX1261 reset through GPIO23...
CoreCell power enable through GPIO18...
CoreCell ADC reset through GPIO13...
Opening SPI communication interface
Note: chip version is 0x10 (v1.0)
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
ARB: dual demodulation disabled for all SF
INFO: found temperature sensor on port 0x39
INFO: [main] concentrator started, packet can now be received
INFO: concentrator EUI: 0x0016c001f10ac60c
WARNING: [gps] GPS out of sync, keeping previous time reference
WARNING: [gps] GPS out of sync, keeping previous time reference
INFO: [down] PULL_ACK received in 160 ms
INFO: [down] PULL_ACK received in 162 ms
INFO: [down] PULL_ACK received in 162 ms

##### 2024-02-14 05:11:23 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### SX1302 Status ###
# SX1302 counter (INST): 30734644
# SX1302 counter (PPS):  30497647
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
#--------
src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Valid time reference (age: 0 sec)
# no valid GPS coordinates available yet
### Concentrator temperature: 49 C ###
##### END #####

JSON up: {"stat":{"time":"2024-02-14 05:11:23 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":49.1}}
INFO: [down] PULL_ACK received in 159 ms
^C
##### 2024-02-14 05:11:26 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (123 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 1 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### SX1302 Status ###

Any guidance or suggestions would be greatly appreciated. Thanks in advance.

[150d]

I believe I found the root cause. In your quote (and I'm seeing the same problem on my own hardware as well) you logged the following NMEA message:

$GNRMC,052331.000,A,1057.27606,N,07619.38087,E,0.00,190.74,140224,,,A,V*0D

This message has 14 data fields in total. According to all NMEA specs I've checked in the process it should only have 13 fields, and that's what packet_forwarder expects. If the number of fields doesn't match, the basic GPS time sync fails, and if this is not done, no position is accepted either.

The patch (as in: "make it work and don't care") is easy: Just make packet_forwarder accept the message with 14 fields, the last one (which is the superfluous one) doesn't hurt. This preliminary fix is running fine on my system without the earlier problem.

However, a true solution (as in: "why is this field number 14 there in the first place?") I can not provide. The trailing ",V" in your message just shouldn't be there as much as I understand.

[rlimberger]

Did you solve this? I am running into the same problem.

[150d]

In the meantime I did some more research and found that the NMEA spec is not as absolute as I assumed it to be. Apparently, there are a number of manufacturers who transmit messages not strictly conforming to the spec, so the parsing needs to accomodate for this (see discussion from the developers of gpsd, they are recommending the gpsd unified communication syntax over NMEA for exactly this reason.)

Therefore the case at hand doesn't appear to be that out of the ordinary, but rather "NMEA business as usual". And since the required payload of the GNRMC message is not affected by the unexpected addition, it may as well just be ignored.

So yes, I believe you can actually call it a "solution" instead of just a "patch".

[rlimberger]

Got it, thank you. Could you share this code?

[ABHITHLALC]

Thak you for the response , I will check it out let you know the result.

[150d]

It's trivial, really:

In libloragw/src/loragw_gps.c, you'll find:

832 if (nb_fields != 13) {

Change that to something like:

832 if ( (nb_fields != 13) && (nb_fields != 14) ) {

This change will accept NMEA G?RMC messages with 13 or 14 fields, not only those with 13 as before. The L76K receiver apparently defaults to sending 14-field-messages.

[ABHITHLALC]

Thank you for you response. After adding to adapt nb_field 14, now it woking.

[150d]

Excellent, thanks for the feedback!

PS: Does anyone know how to get the change into the repository? Is there even a maintainer still active? I can see pull requests still pending from 2022, not sure if it's worth creating another one.

[rachase]

I made these changes but still having some issues.
The code was on line 532 thought, not 832?

Its picking out the GPS coords now, but the timing is still off.

# SX1302 counter (INST): 90725791
# SX1302 counter (PPS):  90671076
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:431:jit_print_queue(): INFO: [jit] queue is empty
#--------
src/jitqueue.c:431:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# Valid time reference (age: 1 sec)
# GPS coordinates: latitude 42.34331, longitude -83.07263, altitude 198 m
ERROR: invalid I2C file descriptor
### Concentrator temperature unknown ###
##### END #####

JSON up: {"stat":{"time":"2024-03-24 21:48:33 GMT","lati":42.34331,"long":-83.07263,"alti":198,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":0.0}}
WARNING: [gps] GPS out of sync, keeping previous time reference
WARNING: [gps] GPS out of sync, keeping previous time reference

[errolt]

Excellent, thanks for the feedback!

PS: Does anyone know how to get the change into the repository? Is there even a maintainer still active? I can see pull requests still pending from 2022, not sure if it's worth creating another one.

I tried a few years ago to get this exact change in. This repo ONLY supports UBLOX gpses, and the Waveshare decided to use a non UBLOX gps.

See https://github.com/Lora-net/sx1302_hal/issues/90#issuecomment-1329169154

[VladoPortos]

Ah man, I was waiting whole night to get it to catch a lock, then checking with gpsd in the morning, packet forwarder just don't understand the GPS... and gpsd had perfect lock with GPS data.... I'm going to try the fix with 14-field-messages. Or maybe give the chirpstack gateway os a try, since it looks like the maintainer abandoned this repo :(

[mcoracin]

Hello @VladoPortos , this repo is not abandoned, but the support of various GPS receiver is out of the scope of this project. ;) We give an example for Ublox receiver, but fill free to adapt according to your specific hardware.

The main focus of this repo is the libloragw part, which is the driver of the SX1302 chip.

Though, in the next release I'll add a fix for the issue described here.

[VladoPortos]

Hi @mcoracin, ah ok... I'm sorry. I'm just frustrated a bit, since documentation for Lora - anything, is not done well for people who try to learn it. For some reason I kind of expected since this repo is linked from https://www.waveshare.com/wiki/SX1302_LoRaWAN_Gateway_HAT that it should work. However seems like none of the Lora packet forwarders support anything but Ublox,. So why the hell waveshare sticked L76K on to their HAT? This one is working fine for linux with gpsd, but none of the packet forwarders I tried supports it. The packet forwarding works fine, I got that part working, just not sure why to include GPS on the board and not support it, thus I assume this repo is not really related to waveshare at all, right ?

[mcoracin]

You're right, this repo is not related to Waveshare at all. This repo aims to provide an official driver for Semtech SX1302/SX1303 chips for LoRa Gateways (libloragw). It also provides a simple implementation of a Packet Forwarder (as we always did in Semtech) to easily connect to LoRaWAN Network Servers which support our UDP protocol. But by no mean it aims to support any flavors of Raspberry Pi HATs which exist with a sx1302/1303.

By the way, the GPS is only needed if you want to do LoRaWAN Class-B, or if you are using a sx1303 for fine timestamping. For regular LoRaWAN Class-A, there is no need for a GPS.

[timiman]

I was having the same issue with packet_forwarder and "no valid GPS coordinates available yet". Changing of the nb_fields variable in loragw_gps.c to support 14 fields gps responses was successful. But receiving warnings like below: WARNING: [gps] GPS out of sync, keeping previous time reference , even if GPS data get picked correctly by TTN v3.

[mcoracin]

Hello all, just for information, the necessary change to support various possible number of fields in the RMC sentence will be done in next release, which should happen during the summer.

[150d]

Thanks, appreciate that!

[pacmac]

It's trivial, really:

In libloragw/src/loragw_gps.c, you'll find:

832 if (nb_fields != 13) {

Change that to something like:

832 if ( (nb_fields != 13) && (nb_fields != 14) ) {

This change will accept NMEA G?RMC messages with 13 or 14 fields, not only those with 13 as before. The L76K receiver apparently defaults to sending 14-field-messages.

Thank you, this also worked for me.