Tried the commands you suggested, to no avail.
Meanwhile, your recommendation gave me a hint to dug up more deep into the code. And found a few things.
1. There is a program to test GPS, including time: sx1302_hal/libloragw/test_loragw_gps .
2. The program, by itself, is not very informative, so better turn on the debug option at sx1302_hal/libloragw/library.cfg
3. It clearly shows that time does come from the commands querying GPS output. There we have the 1999-11-30... and other timestamps, all wrong.
4. Digging a bit further, I noted that there are lots of references on the code to UBX. UBX is an alternative to NMEA, a proprietary one from U-Blox. I have no information that Quectel supports such protocol. Anyway, the test program seems to constantly complain on wrong strings.
So It could be this: Semtech code is tuned on UBX and naturally everything goes wrong as UBX is not a supported protocol (or badly supported). Right now I cannot be sure at 100% that this is the core of the problem, however, a fast test I did with one script, trying to read UBX sentences, ended in nothing. It seems there is no UBX.
Besides, for the moment, I am using the RP2040 LoRaWAN RA-08H as a test base for your gateway. The old version btw. You seem to have a new one.
What I am not using is TTN or any cloud stuff to link the gateway to anything else. I use the Chirpstack V4 server for this and it works fine. I have a large and long experience with LoraWAN systems (several devices, 5 kinds of gateways, three types of servers) so I don't even look there for any problems . Besides, we don't have here infrastructure to experience with TTN and similar stuff.
I'm sorry I didn't express myself clearly before. If possible, could you send me the program you compiled and the associated files in a zip package? Because the source code on GitHub we verified is fine. Thanks in advance for your patience and co-operation during these days.
The binary, configuration and the source. Take note that GPIO pins in reset_lgw.sh are configured for kernel 6.6, where radical changes were made to GPIO. The old numbering DOES NOT work from 6.6 upwards (https://github.com/domoticz/domoticz/issues/6040).
OS is one of the latest official Raspberry Pi OS, based on Debian 12. I didn't test any other OS on this hardware.
Hello @ektanoor ,
The source code is working fine. But your GPS output is not the same as ours. For more details, please see image 1. GPS data is not getting properly.
Please refer to picture 2 to comment out the 2141-2167 lines of code. And compile again to see if the wrong timestamp still appears.
Comments
Tried the commands you suggested, to no avail.
Meanwhile, your recommendation gave me a hint to dug up more deep into the code. And found a few things.
1. There is a program to test GPS, including time: sx1302_hal/libloragw/test_loragw_gps .
2. The program, by itself, is not very informative, so better turn on the debug option at sx1302_hal/libloragw/library.cfg
3. It clearly shows that time does come from the commands querying GPS output. There we have the 1999-11-30... and other timestamps, all wrong.
4. Digging a bit further, I noted that there are lots of references on the code to UBX. UBX is an alternative to NMEA, a proprietary one from U-Blox. I have no information that Quectel supports such protocol. Anyway, the test program seems to constantly complain on wrong strings.
So It could be this: Semtech code is tuned on UBX and naturally everything goes wrong as UBX is not a supported protocol (or badly supported). Right now I cannot be sure at 100% that this is the core of the problem, however, a fast test I did with one script, trying to read UBX sentences, ended in nothing. It seems there is no UBX.
Hello ektanoor, just to confirm with you, are you using Elecrow's LR1302 gateway module and LR1302 HAT?
Of course. What else I could use if I am writing to you? Look:
https://aliexpress.ru/item/1005006280046924.html?sku_id=12000036604526385
Besides, for the moment, I am using the RP2040 LoRaWAN RA-08H as a test base for your gateway. The old version btw. You seem to have a new one.
What I am not using is TTN or any cloud stuff to link the gateway to anything else. I use the Chirpstack V4 server for this and it works fine. I have a large and long experience with LoraWAN systems (several devices, 5 kinds of gateways, three types of servers) so I don't even look there for any problems . Besides, we don't have here infrastructure to experience with TTN and similar stuff.
Could you please send us the source code? We want to try and see if we can reproduce your question.
I posted it before, in April 5. Here:
https://github.com/Elecrow-RD/LR1302_loraWAN/tree/master
I'm sorry I didn't express myself clearly before. If possible, could you send me the program you compiled and the associated files in a zip package? Because the source code on GitHub we verified is fine. Thanks in advance for your patience and co-operation during these days.
The binary, configuration and the source. Take note that GPIO pins in reset_lgw.sh are configured for kernel 6.6, where radical changes were made to GPIO. The old numbering DOES NOT work from 6.6 upwards (https://github.com/domoticz/domoticz/issues/6040).
OS is one of the latest official Raspberry Pi OS, based on Debian 12. I didn't test any other OS on this hardware.
Hello @ektanoor ,
The source code is working fine. But your GPS output is not the same as ours. For more details, please see image 1. GPS data is not getting properly.
Please refer to picture 2 to comment out the 2141-2167 lines of code. And compile again to see if the wrong timestamp still appears.
Yes, packets are coming with the correct timing. Thank you a lot.