RAK2287 + RPI4B Gateway shows as disconnected

Gateways RAK Gateways
1

Hello and thank you for your help!

I am part of the Amateur Radio Club at the University of Colorado, Boulder. As a club activity, we are hoping to place TTN gateways at favorable locations on the campus and throughout the city (at the homes of students and club members). The intention is to install gateways so that students at the College of Engineering (or anyone who is interested in TTN) can experiment with IOT devices.

I have purchased 8 RAK2287modules with PiHats, antennas and sma-ufl coaxial cables, and a handful of RPi 4B and 3B computers.

I tried to bring the first gateway online by following the guide at RAKwireless.com
Quick-Start Guide.

I believe that the RPi is connected to the WiFi at my home because:

  1. It shows up on the router dashboard as a connected device.
  2. From the RPi, I can “ping” www.google.com and it receives data.

I registered the gateway through the TTN console, taking care to make sure that the EUI reported by the device and the EUI on the console are matched.

The live data on the console shows no errors.

I did NOT select “authentication required” on the console.

The address on the .json file is nam1.cloud.thethings.network which is, I think, correct.

I selected the US band plan when I configured the RAK 2287.

When I run:
sudo systemctl status ttn-gateway.service
it shows that the system is active (running).

What diagnostics or logs can I run and post that would help me to understand why the device shows as disconnected in the TTN console?

Thank you for you help!

Gabriel

2

Welcome, nice project!

Forum search on “gateway shows disconnected” which will lead TL;DR, status is unreliable. You should see stat updates every 30 seconds are so, plus actual device traffic.

The docs are most excellent but can’t fill in some of the nuances of the vast body of knowledge that is stored on the forum!

Hopefully you’ll have some devices as well so you can see traffic on a gateway - that is the acid test.

3

As Nick suggests acid test is if you have active devices near by you should see traffic in the associated application/device console. If nothing might be worth checking if backhaul/ISP isnt blocking port 1700…this needs to be open for correct gw operation using the Semtech UDP packet forwarder which is the RAK default I believe… less common these days but early on many ISP’s tel/cell/cableco’s blocked and need prompting to open up.

4

Thanks! I’ve ordered two IOT devices from seeedstudio.com so that I can test my gateway. I’ll make sure the devices (temperature/humidity sensors) are physically distant from the base station and that the signal has to pass through a few walls before reaching the gateway.

I tried changing the “keepalive_interval” to 5 seconds (from the default of 10s).

I did see that the gateway shows disconnected status is unreliable. My concern is that it doesn’t look like the gateway has ever connected to TTN. Other than waiting for my IOT devices to arrive, is there a way to verify that I have set up the gateway correctly?

5

This:

in the gateway console.

If this is the “keepalive_interval”, 30 seconds is a good balance - much less than this and you are needlessly poking the free shared community servers, much more and the LNS won’t know if that gateway is available for downlinks.

You can query the PacketBroker which is peering service run by TTI:

https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id=GATEWAY_ID_HERE

Use your gateway id, remembering the eternal phrase of forum despair that the gateway id is the one you set and is not the gateway EUI.

6

when you registered the gateway on the console you did used the nam1 cluster?
just that the eu one is top of the list and a essay mistake to make

and u used this frequency plan
image

what is your gateway eui?

nice project thought to introduce students to iot :muscle:

7

Please don’t. It won’t help and just puts additional load on the shared servers.

For debugging, can you check the process list on the gateway to see if there is something with pkt or packet in the name running?
Next can you check if there is any logging in /var/log related to the packet forwarder?
Did you download the json file from TTN and put it in place? It should be called global_conf.json and there should not be a local_conf.json in the same folder (or anywhere else on the gateway)

Above is assuming the instructions resulted in installation of the Semtech UDP packet forwarder. If it installs BasicStation there will still be a log file but the configuration will be different and require additional steps at TTN.

8

I’ve changed the “keepalive_interval” to 30 seconds to avoid sending unnecessary traffic and overusing network resources. The suggestion to change it came from a forum post (maybe on the RAK website?), but I’m having trouble finding that post so that it can be updated.

I’ve started with the low hanging fruit of checking port 1700. From my windows computer, I think I can use TELNET to check the ports. I followed this guide.
Results:
I can connect to port 80 (as a test).
I cannot connect to port 1700.

Action: As soon as my housemate wakes up, I will get the password to the router and check and open port 1700.

I did select the frequency plan “United States 902-928 MHz, FSB 2 (used by TTN)”

The gateway console shows that the gateway server address is “nam1.cloud.thethings.network”
When I open /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json on the RPi, I can see the following:

“server_address”: “nam1.cloud.thethings.network”,

I used the global_conf.json file that was generated by the software from RAKwireless when I setup the gateway following their guide.

The EUI of the gateway is E45F01FFFEB95A01
The gateway ID as shown on the console is eui-e45f01fffeb95a01

The live data on the console shows no activity since I initially created the gateway and updated the location.

On the RPi, I ran the command “ps -A |less” to see the process list
I see the process “lora_pkt_fwd”

I tried to query the PacketBroker by entering the following into the browser:
https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id=eui-e45f01fffeb95a01

Result: {“message”:“store: not found: get gateway”}

Thanks!

9

You can’t. Port 1700 should be using UDP and telnet only works for TCP. Other tools won’t work either because you need something that talks the right protocol on port 1700/UDP and nothing apart from a packet forwarder does implement that protocol.

Download the one available in the TTN gateway console and use that one.

Have you checked /var/log/ for logfiles? Information in a log is very valuable when debugging issues.

10

I setup port forwarding on my router to open port 1700. I think I did it correctly.

I made a copy of the global_conf.json file that was on the RPi (/opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json) and moved it to a folder on my PC as a backup.

I downloaded the global_conf.json file from the TTN console, and moved it into the directory /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/ on the RPi using WinSCP. Next, I ran sudo gateway-config and selected option 3 “Restart packet-forwarder”

I also looked at the directory /var/log/ and there are a number of log files and directories. I’m not sure which ones I should examine or post here.

alternatives.log
btmp
chirpstack-network-server
journal
mosquito
README
sysstat
apt
chirpstack-application-server
dpkg.log
lastlog
postgresql
redis
wtmp
bootstrap.log
chirpstack-gateway-bridge
faillog
monit.log
private
runit

11

Results:

The RPi now fails to connect to the Wifi. I can no longer connect to the RPi via PUTTY.

I got out a keyboard and an HDMI cable and, when I power up the RPi, there is a new behavior.

During bootup, it shows:
[ OK ] Stopped ttm-gateway.service - THe Things Network Gateway
[ OK ] Started ttm-gateway.service - THe Things Network Gateway
[ OK ] Stopped ttm-gateway.service - THe Things Network Gateway
[ OK ] Started ttm-gateway.service - THe Things Network Gateway
[ OK ] Stopped ttm-gateway.service - THe Things Network Gateway
…
[ FAILED] Failed to start NetworkManager-wait-online. Service - Network Manager Wait Online

Following that, the RPi boots up but does not connect to wifi and I cannot connect via PUTTY.

12

I was able to revert to the previous configuration by removing the PiHat with the RAK2287, reconfiguring the wifi, and copying the backup copy of the global_conf.json file from my PC to the RPi using WinSCP.

The boot sequence is the same as before. When I login and run:
sudo systemctl status ttn-gateway.service
this is what I see:
gabriel@rak-gateway:~ $ sudo systemctl status ttn-gateway.service
â—Ź ttn-gateway.service - The Things Network Gateway
Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; preset: enabled)
Active: active (running) since Sun 2023-11-05 19:30:28 UTC; 5min ago
Main PID: 763 (start.sh)
Tasks: 2 (limit: 9291)
CPU: 4min 48.362s
CGroup: /system.slice/ttn-gateway.service
├─763 /bin/bash /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh
└─777 ./lora_pkt_fwd

Nov 05 19:30:28 rak-gateway systemd[1]: Started ttn-gateway.service - The Things Network Gateway.
Nov 05 19:30:30 rak-gateway ttn-gateway[779]: CoreCell reset through GPIO17…

13

This is the global_conf.json file that is currently on the RPi, and was generated by the RAKwireless install procedure. I changed one line since my last post:
“gateway_ID”: “E45F01FFFEB95A01”,
It originally had “gateway_ID”: “AA555A0000000000”,

{
    "SX130x_conf": {
        "com_type": "SPI",
        "com_path": "/dev/spidev0.0",
        "lorawan_public": true,
        "clksrc": 0,
        "antenna_gain": 0, /* antenna gain, in dBi */
        "full_duplex": false,
        "fine_timestamp": {
            "enable": false,
            "mode": "all_sf" /* high_capacity or all_sf */
        },
        "radio_0": {
            "enable": true,
            "type": "SX1250",
            "freq": 904300000,
            "rssi_offset": -215.4,
            "rssi_tcomp": {"coeff_a": 0, "coeff_b": 0, "coeff_c": 20.41, "coeff_d": 2162.56, "coeff_e": 0},
            "tx_enable": true,
            "tx_freq_min": 923000000,
            "tx_freq_max": 928000000,
            "tx_gain_lut":[
                {"rf_power": 12, "pa_gain": 1, "pwr_idx": 6},
                {"rf_power": 13, "pa_gain": 1, "pwr_idx": 7},
                {"rf_power": 14, "pa_gain": 1, "pwr_idx": 8},
                {"rf_power": 15, "pa_gain": 1, "pwr_idx": 9},
                {"rf_power": 16, "pa_gain": 1, "pwr_idx": 10},
                {"rf_power": 17, "pa_gain": 1, "pwr_idx": 11},
                {"rf_power": 18, "pa_gain": 1, "pwr_idx": 12},
                {"rf_power": 19, "pa_gain": 1, "pwr_idx": 13},
                {"rf_power": 20, "pa_gain": 1, "pwr_idx": 14},
                {"rf_power": 21, "pa_gain": 1, "pwr_idx": 15},
                {"rf_power": 22, "pa_gain": 1, "pwr_idx": 16},
                {"rf_power": 23, "pa_gain": 1, "pwr_idx": 17},
                {"rf_power": 24, "pa_gain": 1, "pwr_idx": 18},
                {"rf_power": 25, "pa_gain": 1, "pwr_idx": 19},
                {"rf_power": 26, "pa_gain": 1, "pwr_idx": 21},
                {"rf_power": 27, "pa_gain": 1, "pwr_idx": 22}
            ]
        },
        "radio_1": {
            "enable": true,
            "type": "SX1250",
            "freq": 905000000,
            "rssi_offset": -215.4,
            "rssi_tcomp": {"coeff_a": 0, "coeff_b": 0, "coeff_c": 20.41, "coeff_d": 2162.56, "coeff_e": 0},
            "tx_enable": false
        },
        "chan_multiSF_All": {"spreading_factor_enable": [ 5, 6, 7, 8, 9, 10, 11, 12 ]},
        "chan_multiSF_0": {"enable": true, "radio": 0, "if": -400000},  /* Freq : 903.9 MHz*/
        "chan_multiSF_1": {"enable": true, "radio": 0, "if": -200000},  /* Freq : 904.1 MHz*/
        "chan_multiSF_2": {"enable": true, "radio": 0, "if":  0},       /* Freq : 904.3 MHz*/
        "chan_multiSF_3": {"enable": true, "radio": 0, "if":  200000},  /* Freq : 904.5 MHz*/
        "chan_multiSF_4": {"enable": true, "radio": 1, "if": -300000},  /* Freq : 904.7 MHz*/
        "chan_multiSF_5": {"enable": true, "radio": 1, "if": -100000},  /* Freq : 904.9 MHz*/
        "chan_multiSF_6": {"enable": true, "radio": 1, "if":  100000},  /* Freq : 905.1 MHz*/
        "chan_multiSF_7": {"enable": true, "radio": 1, "if":  300000},  /* Freq : 905.3 MHz*/
        "chan_Lora_std":  {"enable": true, "radio": 0, "if":  300000, "bandwidth": 500000, "spread_factor": 8,						/* Freq : 904.6 MHz*/
                           "implicit_hdr": false, "implicit_payload_length": 17, "implicit_crc_en": false, "implicit_coderate": 1},
        "chan_FSK":       {"enable": false, "radio": 1, "if":  300000, "bandwidth": 125000, "datarate": 50000}						/* Freq : 868.8 MHz*/
    },

    "gateway_conf": {
        "gateway_ID": "E45F01FFFEB95A01",
        /* change with default server address/ports */
        "server_address": "nam1.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/ttyAMA0",
        /* GPS reference coordinates */
        "ref_latitude": 0.0,
        "ref_longitude": 0.0,
        "ref_altitude": 0,
        /* Beaconing parameters */
        "beacon_period": 0,	/* disable class B beacon, set to 128 enable beacon */
        "beacon_freq_hz": 923300000, 
        "beacon_freq_nb": 8, 
        "beacon_freq_step": 600000, 
        "beacon_datarate": 12, 
        "beacon_bw_hz": 500000, 
        "beacon_power": 27
    },

    "debug_conf": {
        "ref_payload":[
            {"id": "0xCAFE1234"},
            {"id": "0xCAFE2345"}
        ],
        "log_file": "loragw_hal.log"
    }
}



Here is the global_conf.json file that is from the TTN console:
{
  "SX1301_conf": {
    "lorawan_public": true,
    "clksrc": 1,
    "antenna_gain": 0,
    "radio_0": {
      "enable": true,
      "type": "SX1257",
      "freq": 904300000,
      "rssi_offset": -166,
      "tx_enable": true,
      "tx_freq_min": 923000000,
      "tx_freq_max": 928000000
    },
    "radio_1": {
      "enable": true,
      "type": "SX1257",
      "freq": 905000000,
      "rssi_offset": -166,
      "tx_enable": false
    },
    "chan_multiSF_0": {
      "enable": true,
      "radio": 0,
      "if": -400000
    },
    "chan_multiSF_1": {
      "enable": true,
      "radio": 0,
      "if": -200000
    },
    "chan_multiSF_2": {
      "enable": true,
      "radio": 0,
      "if": 0
    },
    "chan_multiSF_3": {
      "enable": true,
      "radio": 0,
      "if": 200000
    },
    "chan_multiSF_4": {
      "enable": true,
      "radio": 1,
      "if": -300000
    },
    "chan_multiSF_5": {
      "enable": true,
      "radio": 1,
      "if": -100000
    },
    "chan_multiSF_6": {
      "enable": true,
      "radio": 1,
      "if": 100000
    },
    "chan_multiSF_7": {
      "enable": true,
      "radio": 1,
      "if": 300000
    },
    "chan_Lora_std": {
      "enable": true,
      "radio": 0,
      "if": 300000,
      "bandwidth": 500000,
      "spread_factor": 8
    },
    "chan_FSK": {
      "enable": false
    },
    "tx_lut_0": {
      "pa_gain": 0,
      "mix_gain": 8,
      "rf_power": -6,
      "dig_gain": 0
    },
    "tx_lut_1": {
      "pa_gain": 0,
      "mix_gain": 10,
      "rf_power": -3,
      "dig_gain": 0
    },
    "tx_lut_2": {
      "pa_gain": 0,
      "mix_gain": 12,
      "rf_power": 0,
      "dig_gain": 0
    },
    "tx_lut_3": {
      "pa_gain": 1,
      "mix_gain": 8,
      "rf_power": 3,
      "dig_gain": 0
    },
    "tx_lut_4": {
      "pa_gain": 1,
      "mix_gain": 10,
      "rf_power": 6,
      "dig_gain": 0
    },
    "tx_lut_5": {
      "pa_gain": 1,
      "mix_gain": 12,
      "rf_power": 10,
      "dig_gain": 0
    },
    "tx_lut_6": {
      "pa_gain": 1,
      "mix_gain": 13,
      "rf_power": 11,
      "dig_gain": 0
    },
    "tx_lut_7": {
      "pa_gain": 2,
      "mix_gain": 9,
      "rf_power": 12,
      "dig_gain": 0
    },
    "tx_lut_8": {
      "pa_gain": 1,
      "mix_gain": 15,
      "rf_power": 13,
      "dig_gain": 0
    },
    "tx_lut_9": {
      "pa_gain": 2,
      "mix_gain": 10,
      "rf_power": 14,
      "dig_gain": 0
    },
    "tx_lut_10": {
      "pa_gain": 2,
      "mix_gain": 11,
      "rf_power": 16,
      "dig_gain": 0
    },
    "tx_lut_11": {
      "pa_gain": 3,
      "mix_gain": 9,
      "rf_power": 20,
      "dig_gain": 0
    },
    "tx_lut_12": {
      "pa_gain": 3,
      "mix_gain": 10,
      "rf_power": 23,
      "dig_gain": 0
    },
    "tx_lut_13": {
      "pa_gain": 3,
      "mix_gain": 11,
      "rf_power": 25,
      "dig_gain": 0
    },
    "tx_lut_14": {
      "pa_gain": 3,
      "mix_gain": 12,
      "rf_power": 26,
      "dig_gain": 0
    },
    "tx_lut_15": {
      "pa_gain": 3,
      "mix_gain": 14,
      "rf_power": 27,
      "dig_gain": 0
    }
  },
  "gateway_conf": {
    "gateway_ID": "E45F01FFFEB95A01",
    "server_address": "nam1.cloud.thethings.network",
    "serv_port_up": 1700,
    "serv_port_down": 1700,
    "servers": [
      {
        "gateway_ID": "E45F01FFFEB95A01",
        "server_address": "nam1.cloud.thethings.network",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        "serv_enabled": true
      }
    ]
  }
}
14

For readability of your messages please use the formatting tools at the top of the text entry box in stead of just dumping in large amounts of text.

All domestic routers use connection tracking so port forwarding should not be required and may even be harmful as it might interfere with connection tracking.

Next time just use systemctl to restart the packet forwarder. That makes sure there are no side effects that might undo your changes and also warns you if the restart fails for some reason.

Doesn’t look right of course. I don’t know why the RAK provided software things there is an issue without seeing some logging. Making networkmanager dependend on the packet forwarder successfully starting sounds very unwise. The packet forwarder should not be started before the network is up and running so this seems the wrong way around.

There should be a lot more logging. Have you tried journalctl?

There should have been (or is) a file called local_conf.json that overrides some settings from the global_conf.json, specifically the gateway_ID. At least that is the way that the authors of the packet forwarder intended things to be handled. I can’t comment on what RAK did as none of my gateways runs the software stack as setup by RAK.

Just to make sure: the gateway_ID you list matches the EUI you entered in the TTN console? Never mind what is in the ID field, the EUI is what matters for the gateway to show connected at some time.

15

Just to clarify this head buster - in the packet forwarder conf, ID is EUI.

On the console the ID is the ID and the EUI is the EUI.

16

TTN console shows the following:
Gateway EUI E45F01FFFEB95A01
Gateway ID eui-e45f01fffeb95a01

In the global_conf.json file on the RPi it shows:
“gateway_ID”: “E45F01FFFEB95A01”,

I don’t know what logs are helpful to debug this issue but I will post anything that is helpful. Please tell me what logs you would like to see and I will try to find them and upload them with the proper formatting.

17

On the console, the live data only shows:
" Waiting for events from eui-e45f01fffeb95a01…"
There is no other activity

18

UPDATE:

I think I have resolved the problem by changing the “reset_lgw.sh” file.

I changed “SX1302_RESET_PIN=17” to “SX1302_RESET_PIN=25”

The clue that led me to this possible solution was found here:

pi@rak-gateway:~ $ systemctl status ttn-gateway.service
â—Ź ttn-gateway.service - The Things Network Gateway
     Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Mon 2023-11-06 00:18:27 UTC; 3s ago
    Process: 5959 ExecStart=/opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh (code=exited, status=1/FAILURE)
   Main PID: 5959 (code=exited, status=1/FAILURE)
        CPU: 68ms

Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: INFO: packets received with no CRC will NOT be forwarded
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: This is uart for GPS.
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: Opening SPI communication interface
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: Note: chip version is 0x07 (v0.7)
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: ERROR: Failed to set SX1250_0 in STANDBY_RC mode
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: ERROR: failed to setup radio 0
Nov 06 00:18:27 rak-gateway ttn-gateway[5968]: ERROR: [main] failed to start the concentrator
Nov 06 00:18:27 rak-gateway systemd[1]: ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
Nov 06 00:18:27 rak-gateway systemd[1]: ttn-gateway.service: Failed with result 'exit-code'.

Google searching the phrase “Failed to set SX1250_0 in STANDBY_RC mode” led me to both the RAKWireless forum and Github. The posts linked below were helpful.

https://forum.rakwireless.com/t/error-failed-to-set-sx1250-0-in-standby-rc-mode/6340/5

https://github.com/Lora-net/sx1302_hal/issues/67

https://forum.seeedstudio.com/t/wm1302-gateway-pi-hat-getting-started-issue/262814

Of course, the real test is if the gateway remains connected and if devices can connect to it and send data to the servers. I will post updates if the connection is unstable or if IOT devices cannot connect and upload data through TTN.

Thanks for the help!

1 Like
19

this gateway is not yet in the data base

20

Oh yes it is!

{"netID":"000013","tenantID":"ttn","id":"eui-e45f01fffeb95a01","eui":"E45F01FFFEB95A01","clusterID":"nam1.cloud.thethings.network","updatedAt":"2023-11-06T10:14:04.692289Z","location":{"latitude":40.03113459872599,"longitude":-105.24139270710158,"altitude":1655,"accuracy":0},"antennaPlacement":"INDOOR","antennaCount":1,"online":true,"frequencyPlan":{"region":"US_902_928","loraMultiSFChannels":[903900000,904100000,904300000,904500000,904700000,904900000,905100000,905300000]},"rxRate":0,"txRate":0}