RAK831 with RPI 3B+ suddenly not working anymore

Dear TTN-fellows,

my RAK831 module has been working fine for a couple of months since yesterday when I plugged out the internet (I have done that a couple of times). The RPI 3B+ is fine, I can connect to it via putty, it has internet access. I have tried readding the gateway and followed the most recent installation guide:

I have received following error msg, can I check whether the module is broken?:

pi@ttn-gateway:~/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS $ sudo ./install.sh
/home/pi/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS/lora /home/pi/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS
The Things Network Gateway installer
Version master
Gateway configuration:
Detected EUI ASDF from eth0
Host name [rak-gateway]:
Latitude [0]:
Longitude [0]:
Altitude [0]:
Installing dependencies…
Reading package lists… 0%
Reading package lists… Done
Building dependency tree
Reading state information… Done
dialog is already the newest version (1.3-20190211-1).
git is already the newest version (1:2.20.1-2).
minicom is already the newest version (2.7.1-1).
The following package was automatically installed and is no longer required:
rpi.gpio-common
Use ‘sudo apt autoremove’ to remove it.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
/opt/ttn-gateway /home/pi/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS/lora
/opt/ttn-gateway/lora_gateway /opt/ttn-gateway /home/pi/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS/lora
make all -e -C libloragw
make[1]: Entering directory ‘/opt/ttn-gateway/lora_gateway/libloragw’
*** Checking libloragw library configuration ***
Release version : 3.1.0
SPI interface : Linux native SPI driver
*** Configuration seems ok ***
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_hal.c -o obj/loragw_hal.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_gps.c -o obj/loragw_gps.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_reg.c -o obj/loragw_reg.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_spi.native.c -o obj/loragw_spi.o
src/loragw_spi.native.c:56: warning: “SPI_SPEED” redefined
#define SPI_SPEED 2000000

In file included from inc/config.h:11,
from inc/loragw_spi.h:29,
from src/loragw_spi.native.c:34:
inc/imst_rpi.h:15: note: this is the location of the previous definition
#define SPI_SPEED 8000000

src/loragw_spi.native.c:164:5: error: conflicting types for ‘lgw_spi_w’
int lgw_spi_w(void *spi_target, uint8_t spi_mux_mode, uint8_t spi_mux_target, uint8_t address, uint8_t data) {
^~~~~~~~~
In file included from src/loragw_spi.native.c:34:
inc/loragw_spi.h:64:5: note: previous declaration of ‘lgw_spi_w’ was here
int lgw_spi_w(void *spi_target, uint8_t address, uint8_t data);
^~~~~~~~~
src/loragw_spi.native.c: In function ‘lgw_spi_w’:
src/loragw_spi.native.c:180:25: error: ‘LGW_SPI_MUX_MODE1’ undeclared (first use in this function); did you mean ‘LGW_SPI_ERROR’?
if (spi_mux_mode == LGW_SPI_MUX_MODE1) {
^~~~~~~~~~~~~~~~~
LGW_SPI_ERROR
src/loragw_spi.native.c:180:25: note: each undeclared identifier is reported only once for each function it appears in
src/loragw_spi.native.c: At top level:
src/loragw_spi.native.c:213:5: error: conflicting types for ‘lgw_spi_r’
int lgw_spi_r(void *spi_target, uint8_t spi_mux_mode, uint8_t spi_mux_target, uint8_t address, uint8_t *data) {
^~~~~~~~~
In file included from src/loragw_spi.native.c:34:
inc/loragw_spi.h:73:5: note: previous declaration of ‘lgw_spi_r’ was here
int lgw_spi_r(void *spi_target, uint8_t address, uint8_t *data);
^~~~~~~~~
src/loragw_spi.native.c: In function ‘lgw_spi_r’:
src/loragw_spi.native.c:231:25: error: ‘LGW_SPI_MUX_MODE1’ undeclared (first use in this function); did you mean ‘LGW_SPI_ERROR’?
if (spi_mux_mode == LGW_SPI_MUX_MODE1) {
^~~~~~~~~~~~~~~~~
LGW_SPI_ERROR
src/loragw_spi.native.c: At top level:
src/loragw_spi.native.c:264:5: error: conflicting types for ‘lgw_spi_wb’
int lgw_spi_wb(void *spi_target, uint8_t spi_mux_mode, uint8_t spi_mux_target, uint8_t address, uint8_t *data, uint16_t size) {
^~~~~~~~~~
In file included from src/loragw_spi.native.c:34:
inc/loragw_spi.h:83:5: note: previous declaration of ‘lgw_spi_wb’ was here
int lgw_spi_wb(void *spi_target, uint8_t address, uint8_t *data, uint16_t size);
^~~~~~~~~~
src/loragw_spi.native.c: In function ‘lgw_spi_wb’:
src/loragw_spi.native.c:287:25: error: ‘LGW_SPI_MUX_MODE1’ undeclared (first use in this function); did you mean ‘LGW_SPI_ERROR’?
if (spi_mux_mode == LGW_SPI_MUX_MODE1) {
^~~~~~~~~~~~~~~~~
LGW_SPI_ERROR
src/loragw_spi.native.c: At top level:
src/loragw_spi.native.c:326:5: error: conflicting types for ‘lgw_spi_rb’
int lgw_spi_rb(void *spi_target, uint8_t spi_mux_mode, uint8_t spi_mux_target, uint8_t address, uint8_t *data, uint16_t size) {
^~~~~~~~~~
In file included from src/loragw_spi.native.c:34:
inc/loragw_spi.h:93:5: note: previous declaration of ‘lgw_spi_rb’ was here
int lgw_spi_rb(void *spi_target, uint8_t address, uint8_t *data, uint16_t size);
^~~~~~~~~~
src/loragw_spi.native.c: In function ‘lgw_spi_rb’:
src/loragw_spi.native.c:349:25: error: ‘LGW_SPI_MUX_MODE1’ undeclared (first use in this function); did you mean ‘LGW_SPI_ERROR’?
if (spi_mux_mode == LGW_SPI_MUX_MODE1) {
^~~~~~~~~~~~~~~~~
LGW_SPI_ERROR
make[1]: *** [Makefile:90: obj/loragw_spi.o] Error 1
make[1]: Leaving directory ‘/opt/ttn-gateway/lora_gateway/libloragw’
make: *** [Makefile:10: all] Error 2

You seem to be mixing up two different repos

Is fairly ordinary, pretty much just using the code straight from Semtech

But

Seems to have RAK customization to account for the SPI speed limitation resulting from the unfortunate and mistaken inclusion of a slow SPI level shifter in the RAK2245, and internal API changes to add some sort of SPI mux (maybe to use two concentrator cards?).

If you have a RAK831 you should probably start from the previous repository.

If you have RAK2245, either use the previous one and edit it to reduce the SPI speed, or use the newer repository.

In either case you should probably start clean, without any leftover lora or gateway related files from a previous install, as it looks like some of the customizations break compatibility.

There actually is a newer one which supports:

  • RAK831
  • RAK833
  • RAK2245
  • RAK2247
  • RAK7243

Why do you suggest to use the old(er) RAK831-only version instead?
It appears to be no longer maintained.

How about because it appears to be a very light wrapper which fetches and builds the Semtech code with no dubious vendor meddling more than the bare minimum of customization needed to make the RAK831 work (which is actually next to nothing more than making the software match the way they suggest you wire the chip select and reset to a pi)

(in actuality, back when I was using a pi, I had no problem bringing up a RAK831 using someone’s iC880 instructions - there’s not really anything on a RAK831 between the header and the SX1301 chip)

It appears to be no longer maintained.

What maintenance (to the minimal wrapper) would be needed?

It doesn’t appear to be pinned to a specific version of the Semtech repos, so any change there should end up in a new installation.

I can agree with that. :slightly_smiling_face:

Thank you a lot for your help guys.
I have followed this guide:

And the gateway successfully installed but with the wrong gateway-ID:
B8 27 EB FF FE 3E 2A 55
I think it is a standard ID

Where can I edit the gateway ID?

Thank you guys, it is kind of working now:
Though the last successful online time was 20 min ago:

● ttn-gateway.service - The Things Network Gateway
Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-10-25 11:16:44 BST; 54s ago
Main PID: 986 (start.sh)
Tasks: 8 (limit: 2200)
Memory: 1.3M
CGroup: /system.slice/ttn-gateway.service
├─ 986 /bin/bash /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh
└─1018 ./lora_pkt_fwd

Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: packets received with no CRC will NOT be forwarded
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: [main] concentrator started, packet can now be received
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: WARNING: [gps] could not get GPS time from GPS
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: Disabling GPS mode for concentrator’s counter…
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: WARNING: [gps] could not get GPS time from GPS
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: host/sx1301 time offset=(1571998606s:171983µs) - drift=1921130319µs
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: INFO: Enabling GPS mode for concentrator’s counter.
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: WARNING: [gps] could not get GPS time from GPS
Oct 25 11:17:02 rak-gateway ttn-gateway[986]: WARNING: [gps] could not get GPS time from GPS

Gateway ID would be in the local_conf.json

Note your log message is only the normal startup noise, you haven’t quoted any messages which would indicate if it is actually running or not.

If it is running, and if you have a node in range properly sending, you’ll see messages in the system log. Probably something like journalctl -f to follow that.

log_rak831.txt (41.5 KB)

Thank you a lot cslorabox!
The gateway is not showing up on TTN anymore (had already 30.000 transmissions) but in the log you suggested (journalctl -f) it shows some reception events. If it’s not too much demanded, could you please have a look at the log?
Thank you!

INFO: [down] the last 6 PULL_DATA were not ACKed, exiting application

That is key. Your gateway is either not managing to contact a TTN server, or not getting a reply.

Make sure the server details in local_conf.json are correct for your region. Make sure the pi has network connectivity.

Make sure the gateway ID now listed in the logs is the correct one. Make sure when you registered that with TTN you checked the “legacy packet forwarder” box and weren’t on the page that gives you a key for some other protocol this software setup can’t support.

Check the slack ops channel or whatever it is to see if TTN is simply broken again.

If you are beyond some unusual firewall that could be an issue. Apparently also there are some types of NAT systems that don’t work well when there is more than one gateway with the legacy UDP protocol on the local subnet, though that is evidence of a bad NAT in the router/cable modem or whatever it is.