Basic station protocol

#1

Hi Heltec

i have just tested the basic station protocol 2.0.5 on the HM-02 gateway.
it compiles fine and is fully functional.
you can find it here: https://github.com/lorabasics/basicstation

would be great to have this protocol in a new firmware for the gateway.
the udp forwarder is a little bit outdated.

#2

Thank you I’ll give this a try. Could you post your configuration here?

#3

Hello,

Would that also work with the HT-M01 ?

#4

Since the TTN update to V3 running the ht-m01 gateway with the udp forwarder is showing the gateway as offline despite it’s forwarding packets. I gave it a try to switch the HT-M01 from the udp forwarder to basic station (cups mode) and followed this tutorial:

The gateway is connecting to the ttn but it doesn’t seem to receive any packets from the nodes. There are some error messages about time sync issues in the log but the internet doesn’t seem to be sure if that would prevent the transfers:
Time sync rejected: quality=171 threshold=165

Any advice?

#5

I figured it out. The TTN is setting the gateway to subband 2 correctly. I had to change it in the nodes too. The time sync issues are still there but don’t seem to prevent downlinks or uplinks.

#6

Thank you for this post. It helped me realize that my cubecell HTCC-AB02 was incorrectly provisioned. I used the
SendReceive.ino and LoraWan.ino programs to create a “ping test” to the HT-M02 gateway. Very helpful in diagnosing my issues.

I am still receiving the following errors.

To gather these errors, I ran the following commands from the serial output of the HT-M02.
journalctl -u lrgateway -f

Apr 28 17:38:17 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:17.633 [SYN:INFO] Time sync qualities: min=349 q90=873 max=888 (previous q90=995)
Apr 28 17:38:17 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:17.633 [SYN:INFO] MCU/SX130X drift stats: min: +9.0ppm  q50: -29.5ppm  q80: -54.7ppm  max: -77.6ppm - threshold q90: -62.3ppm
Apr 28 17:38:17 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:17.633 [SYN:INFO] Mean MCU drift vs SX130X#0: -4.0ppm
Apr 28 17:38:26 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:26.039 [SYN:VERB] Time sync rejected: quality=1057 threshold=873
Apr 28 17:38:32 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:32.342 [SYN:VERB] Time sync rejected: quality=925 threshold=873
Apr 28 17:38:34 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:34.702 [HAL:ERRO] [lgw_get_temperature:1558] temperatur 27.777000
Apr 28 17:38:34 HT-M02 lrgateway.sh[433]: 2025-04-28 17:38:34.702 [RAL:DEBU] [CRC FAIL] 905.100MHz -13.25/-124.2 SF9/BW125 (mod=16/dr=9/bw=4) xtick=a42b62de (2754306782) 52 bytes: E09E8D4A85DDE31B750AB4F7B3A22119DAD5B18ADDBF5853A54CAA0D655C7F91213990E3F52F381E9477D5E180944404EB3DAB17
#7

Do you end up with an uplink on the device console?

That is the main test - gateway logs do give rather a lot of misleading output, like the very small time differences between various components. The CRC FAIL is pretty typical in a gateway log - it’s usually a LoRa packet that is heard that is not from a LoRaWAN device so not sending a packet in the format expected - or a LoRaWAN device that’s just not quite in range enough for its settings. The SNR/RSSI at SF9 is close to the limits, so not a complete surprise that it fails CRC.

If that’s actually your device (match the timestamp with the device log), then it may be too close to the gateway and is distorting the signal. Was that your device?

So, concentrate on getting your device uplinking OK.