How to install a Waveshare SX1302 Hat on a Raspi as Gateway

i enable spi and it fixed my issue immediately.

Hello,

I am trying to configure sx1302 lorahat on a Rpi as gateway. Currently I am facing the following issue.

Opening SPI communication interface
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: [main] failed to start the concentrator

I have followed the following web links

https://community.element14.com/technologies/internet-of-things/b/blog/posts/set-up-elecrow-ttn-lorawan-gateway-on-raspberry-pi

My spi is enable
I have also tried changing the reset pin in reset_lgw.sh

Even tried pressing the connector, nothing has worked.

Not sure how to fix it. Any help is appreciated, thanks.

1 Like

I see though you have a Waveshare Conc bd you are also linking to Elecrow instaltion guide(s)…be aware that though there are many mPCIe f/f boards out in the market many have slightly different configurations and minor changes to the connector pin-out (Elecrow, Waveshare, RAK, Seeed, etc…). Some have an additional SX12xx transceiver on board (to support LBT etc.) others dont and reset pins may vary, so be absolutely sure which version and pin out you have and use matching s/w config… Havent yet looked at specific differences for this pair myself (future project) but worth you checking…and perhaps report back here what you find.

Thanks for the response! will check the pin configuration and revert back. Thanks again!

So i also have G-nicerf lorawan 1302 module with pi 3 b+ and im using the sx1302_hal github repo to find the uid and ./test_loragw_com and ./test_loragw_sx1250 but unable to get the output and getting same errors like :-
Opening SPI communication interface
Note: chip version is 0x05 (v0.5)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: [main] failed to start the concentrator

Im working over raspberry os, Guidance will be appreciated alot

P.s :- I have also tried to change reset_lgw.sh pin from 23 to 17 and also tried to open both i2c and spi but no response im getting.

I have problems with installing,too… Output:

pi@loranet:~/Documents/sx1302_hal/util_chip_id $ ./chip_id
./reset_lgw.sh: 26: echo: echo: I/O error
./reset_lgw.sh: 27: echo: echo: I/O error
./reset_lgw.sh: 28: echo: echo: I/O error
./reset_lgw.sh: 29: echo: echo: I/O error
./reset_lgw.sh: 32: cannot create /sys/class/gpio/gpio23/direction: Directory nonexistent
./reset_lgw.sh: 33: cannot create /sys/class/gpio/gpio22/direction: Directory nonexistent
./reset_lgw.sh: 34: cannot create /sys/class/gpio/gpio18/direction: Directory nonexistent
./reset_lgw.sh: 35: cannot create /sys/class/gpio/gpio13/direction: Directory nonexistent
CoreCell reset through GPIO23…
SX1261 reset through GPIO23…
CoreCell power enable through GPIO18…
CoreCell ADC reset through GPIO13…
./reset_lgw.sh: 45: cannot create /sys/class/gpio/gpio18/value: Directory nonexistent
./reset_lgw.sh: 47: cannot create /sys/class/gpio/gpio23/value: Directory nonexistent
./reset_lgw.sh: 48: cannot create /sys/class/gpio/gpio23/value: Directory nonexistent
./reset_lgw.sh: 50: cannot create /sys/class/gpio/gpio22/value: Directory nonexistent
./reset_lgw.sh: 51: cannot create /sys/class/gpio/gpio22/value: Directory nonexistent
./reset_lgw.sh: 53: cannot create /sys/class/gpio/gpio13/value: Directory nonexistent
./reset_lgw.sh: 54: cannot create /sys/class/gpio/gpio13/value: Directory nonexistent
Opening SPI communication interface
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: failed to start the gateway
pi@loranet:~/Documents/sx1302_hal/util_chip_id $

I’ve bought this set for my pi4:

Regards Kristian

Hi!

I am using a Waveshare SX1303 HAT and installed it following their instructions. I do not see any error in the output, but TTN says the gateway is offline/disconnected. Am I doing something wrong here or is TTN wrong?
The GPS does not get a fix. Is that a problem for the TTN connection?

This lets me think that it actually works:

### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
[...]
INFO: [up] PUSH_ACK received in 42 ms
INFO: [down] PULL_ACK received in 42 ms
INFO: [down] PULL_ACK received in 43 ms
Full Output
*** 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.json, parsing it
INFO: test_conf.json 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.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000000
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/serial0"
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.json 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/serial0 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 0x12 (v1.2)
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: 0x[a valid EUI here]
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 46 ms
INFO: [down] PULL_ACK received in 44 ms
INFO: [down] PULL_ACK received in 43 ms

##### 2024-08-28 15:39:11 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): 30730891
# SX1302 counter (PPS):  30332251
# 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: 30 C ###
##### END #####

JSON up: {"stat":{"time":"2024-08-28 15:39:11 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":30.0}}
INFO: [up] PUSH_ACK received in 42 ms
INFO: [down] PULL_ACK received in 42 ms
INFO: [down] PULL_ACK received in 43 ms

What do you think? I have also problems connecting my end devices to TTN. That is a different story, but it might be caused by the fact that there is no working gateway in their radius. So I have a hard time testing/validating the connection.

Thanks for your help!

Not looked at detailed install instructions of late but that looks familar - are you by chance slavishly following the instructions word for word and litterally copying the GW EUI in the instructions - which is commented as being an example - vs adding your own GW EUI? If using a PI then best option is use the Pi network MAC add to generate a viable unique GW EUI - use Enet MAC if available is usual convention unless say a Pi0W with WiFi only and hence no Enet MAC then obviously use that…pad middle order bytes with FFFE - search will show lots of examples of this method.

Then re-register with GW if your chossing using new GW EUI; if GW already registered under a name of you choise then just edit the existing GW-EUI to correct one and see how you go from there.

You should atleast see status messages coming through and wont see actual device traffic until you have yours up and running unless there are other devices in range which the GW will then hear

Unless running with known good GPS offering, suggest you just use “Location” in device settings (TTN Console) to set manualy;

That is promising and suggests that atleast GW reset has correctly occured and all configured ready to rock and roll…

Good luck!

Thank you very much! It works now. I have overlooked that you have to modify not only the parameters in the servers array but also in the gateway_conf itself refering to Waveshare’s instructions especially visible in this image.

Hi Kristian,
Have you been able to find a solution for this? I do get the exact same error messages on a RasPi 3B+ at the moment and have wasted hours trying to fix it.
Regards
Thorsten

The above errors have something to do with the fact that the script is using sysfs (deprecated in 2015) to access the gpio. sysfs is still accessible, but the way GPIOs are addressed has been changed. It looks like you have to identify the correct gpiochip and then offset the gpio numbers by the start address of the chip.
I’m not sure how much of the rest of the gateway depends on sysfs and is now rendered unusable without major rework.
The best workaround seem to be to go back to an older Buster or Bullseye image of Raspbian. Buster did the trick for me. Older images can be found at:
Index of /raspios_arm64/images incl. Desktop
Index of /raspios_lite_arm64/images no desktop