Network Join Error

Setup and configuration
1

I am very new to this, trying to learn. I have a chirpstack server setup, and a gateway as well. I can see the gateway come online on the server.

I am using a seeed Wio E5 dev kit as the end device. However when trying to connect I it fails gives the following output.

+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done

They both are placed next to each other. I have checked the Join EUI and device EUI multiple times and they match along with the AppKey.

How do I make the wio E5 dev kit join the network?

2

Are you sure that the node and gateway are using the same default channels? I don’t just mean the region, but sometimes we use some variant of the region.

For example: you use US915 or AU915. But due to cost, you use an 8-channel gateway. The 8-channel gateway doesn’t cover the whole spectrum of 64 channels, so the gateway must use the same channels as the device or the gateway might not receive uplinks from the device.
For AS923: we have many, many countries in this region. Thus the LoRaWAN alliance split up AS923 into 4 sub-variants, with different join channels.

If you looked at the “LoRaWAN frames” tab of the gateway, you can see whether the Join Requests are coming in or not.

1 Like
3

As sp is suggesting, this is likely a band-mismatch between device and gateway/chirpstack. Check that the gateway is set to the same subband as the device, also ensure you are using the correct MQTT topic prefix.

4

Thank you for the reply. I do understand that the channels are split into subbands and verified the info on both my node and gateway.

when checking the log on the chirpstack gateway I find the following

Tue Jan  7 22:13:47 2025 user.info chirpstack-concentratord-sx1302[3010]: Frame received, uplink_id: 3916900524, count_us: 358797991, freq: 904500000, bw: 125000, mod: LoRa, dr: SF7, ftime_received: false, ftime_ns: 0
Tue Jan  7 22:13:47 2025 user.info chirpstack-gateway-mesh[2731]: Frame received - [uplink_id: 3916900524, freq: 904500000, rssi: -16, snr: 14.25, mod: [LORA - sf: 7, bw: 125000]]
Tue Jan  7 22:13:47 2025 user.info chirpstack-gateway-mesh[2731]: Relaying uplink LoRa frame, uplink_id: 3916900524, downlink_id: 3745131817, mesh_packet: [Uplink hop_count: 1, uplink_id: 4, relay_id: f10ac2bc, mic: 15a8c5d8]
Tue Jan  7 22:13:47 2025 user.info chirpstack-gateway-mesh[2731]: Sending mesh frame - [downlink_id: 3745131817 - [freq: 868500000, power: 16, mod: [LORA - sf: 7, bw: 125000], timing: [IMMEDIATELY]]]
Tue Jan  7 22:13:47 2025 user.err chirpstack-concentratord-sx1302[3010]: Frequency is not within min / max gateway frequencies, downlink_id: 3745131817, freq: 868500000
Tue Jan  7 22:13:47 2025 user.err chirpstack-gateway-mesh[2731]: Handle event error: Tx Ack error: TX_FREQ

any idea on how to resolve this? or what the issue could be?

5

Excuse me if I am wrong, I am new to this. But do we need to have a MQTT topic prefix? I am using the UDP forwarder. I do not understand the difference in both.

6

In your earlier post, the logs suggest you are using Chirpstack’s concentratord and not a UDP packet forwarder. What are you really using and where is this MQTT prefix mentioned?

As for the error about downlink frequency range: I guess that you are using US915, but something is involving EU868. Did you select the correct channel plan in Chirpstack, in the device’s profile? Does concentratord point to the correct MQTT topic, which refers to US915?

7

The MQTT topic prefix is necessary, it is in your chirpstack MQTT forwarder (or gateway bridge if using that), it decides what MQTT topic to post the uplink to and if posted to the wrong topic Chirpstack will not see it or will process it incorrectly. If you are using the UDP packet forwarder on your gateway, it must be forwarding packets to a gateway bridge / MQTT forwarder, as that is the component that translates the packets to MQTT for chirpstack.

But the issue here actually seems to be a gateway mesh issue, do you mean to be using the mesh? If so you need to set the region in your mesh configuration to us915. If you look at the logs, you receive an uplink from your device on a us915 frequency, then the gateway mesh tells concentratord to queue the message (to be passed to another gateway) in the eu868 frequencies. Concentratord rejects this as it is out of bounds for us915. So these specific logs are a mesh misconfiguration.

This seems very strange to me, as in order to use the mesh I would assume you are using the gateway OS or atleast a rak. Both should have the MQTT forwarder. If there are still issues after fixing your mesh region please explain your architecture and devices some more.

8

Thanks for the quick reply. I dont think I quite understand how to use the MQTT/UDP forwarder.

But I did check the mesh settings and it was indeed in EU868. I have changed it since to US915, and now I see the logs come out as:

Thu Jan  9 20:16:51 2025 user.info chirpstack-concentratord-sx1302[2060]: Frame received, uplink_id: 16269800, count_us: 2993115204, freq: 904100000, bw: 125000, mod: LoRa, dr: SF10, ftime_received: false, ftime_ns: 0
Thu Jan  9 20:16:51 2025 user.info chirpstack-gateway-mesh[3006]: Frame received - [uplink_id: 16269800, freq: 904100000, rssi: -102, snr: -6.25, mod: [LORA - sf: 10, bw: 125000]]
Thu Jan  9 20:16:51 2025 user.info chirpstack-gateway-mesh[3006]: Relaying uplink LoRa frame, uplink_id: 16269800, downlink_id: 599674891, mesh_packet: [Uplink hop_count: 1, uplink_id: 7, relay_id: f10ac2bc, mic: 1a9cd1b5]
Thu Jan  9 20:16:51 2025 user.info chirpstack-gateway-mesh[3006]: Sending mesh frame - [downlink_id: 599674891 - [freq: 903500000, power: 21, mod: [LORA - sf: 10, bw: 125000], timing: [IMMEDIATELY]]]
Thu Jan  9 20:16:51 2025 user.info chirpstack-concentratord-sx1302[2060]: Enqueueing immediate packet, downlink_id: 599674891, current_counter_us: 2993128126
Thu Jan  9 20:16:51 2025 user.info chirpstack-gateway-mesh[3006]: Enqueue acknowledged, downlink_id: 599674891
Thu Jan  9 20:16:52 2025 user.warn chirpstack-concentratord-sx1302[2060]: GPS time reference is not valid, age: 1736479012.61002892s
Thu Jan  9 20:16:52 2025 user.info chirpstack-concentratord-sx1302[2060]: Scheduled packet for TX, downlink_id: 599674891, count_us: 2994128126, freq: 903500000, bw: 125000, mod: LoRa, dr: SF10

this happens when I try to connect using my wio e5 dev kit, and it still fails to join the network.

My current setup is:

  • I have a raspberry pi with an rak2287 and pihat behaving as a gateway, with chirpstack OS booted onto the raspberry pi.
  • I am using chirpstack server setup in Europe whose server address I have access to. US915 has been added as a device profile for that server.
  • I am using a wio e5 dev kit acting as an node device.

So currently I have added the Gateway EUI and dev kit eui to the server as a gateway and device respectively. I added the server address in the UDP forwarder settings on the gateway’s page, this got the gateway to shown as active on the chirpstack server dashboard.

My end goal is to be able to send data from the e5 dev kit which I am controlling using the ardino ide on my Mac, to the gateway which relies it to the chirpstack server and then forward it back to another web app I have.

9

I dont think I quite understand this. However I was using the mesh settings in EU868 but I have sorted that out now. I have explained my setup and goal in the another post in this thread if that’s of any context.

10

I think you are mistaken on the terminology here, if you are using Chirpstack OS, you are using the MQTT forwarder, not the UDP forwarder.

So in my understanding you only have a single gateway correct? If so you do not want to enable the gateway mesh. The gateway mesh is meant for gateway to gateway communication in a setup where you have multiple and only some of them can access the internet. From those logs it looks like the gateway is trying to pass the uplinks to another gateway, which from what you have described of your setup is not what you want.

Disable the gateway mesh. Then configure the MQTT forwarder: disable the “mesh” tab of the mqtt forwarder and enable the regular one, set the MQTT topic prefix to “us915_0” or whichever subband your devices use, point it at your chirpstack server.

This would likely solve your issues, if not the problem could lie with the code of your dev kit, or potentially the server config of the device.

11

When I wrote my reply above, I saw uplink frequencies like 904500000. This indicates that you are using US915 devices and gateways. Then the error we have indicates 868500000, which is wrong for US915. So I thought that Chirpstack must be incorrectly determining the downlink channel to send the response on, which was how this problem comes about. It’s succinctly explained by @Liam_Philipp.

From your latest log snippets, the error during downlinks is indeed gone. But we don’t actually see any mention of join request. Do you find any? If not that would bring us back to the first point: why can’t we see the join requests from your device?

Are there any logs that indicate join requests are being received at the LoRa gateway? I don’t know much about the Chirpstack Gateway OS stuff as I have been working on the industry-standard things like BasicStation and the UDP packet forwarder. But I think it should let you know whether join requests are appearing.

By the way, if you intended to have more things like Chirpstack’s mesh, maybe we could leave that out until later? I think we should get the device communicating with the LNS first, directly with a single gateway.