Sensors are not joining the LoRa network OTTA

1

Good morning Chirpstack community,

I recently ran into the issue that my devices are no longer able to join the LoRa network.

I am running Chirpstack Network Server v4.4.2

I see the following behaviour:

  • the device sends a JoinRequest, which Chirpstack successfully receives
  • Chirpstack responds with a JoinAccept
  • I can see the JoinAccept being transmitted by the Gateway in its logs
  • however, after a few minutes the device again attempts to rejoin the network with another JoinRequest

This tells me that the device is somehow not receiving the JoinAccept from Chirpstack.

I ruled out bad reception, since the device is practically next to the gateway.

I also see this behaviour with a completely different LoRa device, so it must be a Chirpstack configuration issue.

From what I could tell, its possibly related to the RX1 / RX2 settings in region_eu868.toml.

Initially a few months ago when I deployed Chirpstack, rx_delay=1 mostly worked and then I changed it to rx_delay=2 and it seems from that point onwards it never quite worked again, even if I changed it back to rx_delay=1. This is the only regions.network settings that I changed.

My questions:

  1. Could you please explain a good process to debug this behaviour, i.e. for which logs should I look out for, because I am not exactly sure what to expect

  2. Any advice on how I should configure Chirpstack to get this working again?

Many thanks in advance!

2

Here is what the JoinRequest looks like on Chirpstack:

{
    "phy_payload": {
        "mhdr": {
            "m_type": "JoinRequest",
            "major": "LoRaWANR1"
        },
        "mic": [
            43,
            209,
            238,
            120
        ],
        "payload": {
            "dev_eui": "a81758fffe0b58c3",
            "dev_nonce": 55238,
            "join_eui": "043e68d3d3e0ba82"
        }
    },
    "rx_info": [
        {
            "channel": 2,
            "context": "0RqmtA==",
            "crcStatus": "CRC_OK",
            "gatewayId": "503139534d404750",
            "location": {},
            "metadata": {
                "region_common_name": "EU868",
                "region_config_id": "eu868"
            },
            "rfChain": 1,
            "rssi": -66,
            "snr": 7.25,
            "time": "2023-11-10T08:41:37.972353+00:00",
            "uplinkId": 2817
        }
    ],
    "tx_info": {
        "frequency": 868500000,
        "modulation": {
            "lora": {
                "bandwidth": 125000,
                "codeRate": "CR_4_5",
                "spreadingFactor": 7
            }
        }
    }
}

And here is what the JoinAccept looks like on Chirpstack:

{
    "phy_payload": {
        "mhdr": {
            "m_type": "JoinAccept",
            "major": "LoRaWANR1"
        },
        "mic": [
            6,
            115,
            18,
            234
        ],
        "payload": "5b762fe233fdeb55e3dfa58c532b015a7795d078bdf116b4c52b3d26"
    },
    "tx_info": {
        "context": "0RqmtA==",
        "frequency": 868500000,
        "modulation": {
            "lora": {
                "bandwidth": 125000,
                "codeRate": "CR_4_5",
                "polarizationInversion": true,
                "spreadingFactor": 7
            }
        },
        "power": 14,
        "timing": {
            "delay": {
                "delay": "5s"
            }
        }
    }
}

On the gateway logs, it seems that the delay between JoinRequest and JoinAccept is always the same (one second or less), so it seems that the rx_delay has no influence?

3

This is not the issue. The ~ 1 second that you mention are between receiving the join-request and sending the join-accept to the gateway. It is not the timestamp of transmission.

I ruled out bad reception, since the device is practically next to the gateway.

A device really close to a gateway can lead to issues as the received signal might overdrive the gateway radio, causing the uplink being reported on two channels. In this case ChirpStack might send the downlink on the wrong channel.