I have two RPis, both with the same RAK-5146 gateway.
On the RPi 3B, it works without problems.
I installed the next version of CS, this time on the Raspberry Pi OS Bookworm.
I installed all components by hand.
The web interface on port 8080 works.
I configured the device profile, gateway, application, and device inside an application with parameters copied and pasted from the RPi 3B installation. It doesn’t work.
The end device can’t join the gateway.
Events look like this:
Who knows what might be wrong?
RPi 4B is brand new, and RAK-5146 is brand new, too.
I have the same problems with CS OS 4.x, but only on the RPi 4B.
I made several attempts to have a working installation based on the RPi 4B, but without success.
I haven’t used the Pi + RAK yet.
However for this symptom, generally there are few possible reasons I experience with other gateways.
-
The node keeps crashing/restarting after sending the Join requests. This happens especially for DIY nodes.
-
The frequencies for CS, gateway and nodes do not match.
Node sends uplink to gateway to CS at frequency X.
CS sends Join Accept to gateway. Gateway should send Join Accept to node at frequency X too.
-
Check the delay and offset for downlink.
The Join Accept may come down too late or too early or mismatched DR.
I will check it today, but :).
Why does it work on RPi 3B without problems? The same end node was used in both cases.
My params for the region:
I don’t see any differences besides the different regions we are using.
I can’t believe it. Is it possible that the gateway on the RPi 3B doesn’t check DevEUI? I had two nodes that had software with the wrong DevEUIs. They didn’t work with the gateway that had RPi4 B on the board. I ported them to the environment where two other nodes had correct DevEUIs. They worked with the gateway with RPi 4B on the same board. I reprogram these nodes by setting up DevEUI to zeros (the nodes send the right DevEUI now by default). And surprise, they connected to the gateway and worked the third day.
Strange.
From this point of time, I always set up DevEUI in the code to zeroes. So, I mustn’t register DevEUIs for the new nodes.
I’m using the Lora E5 Mini end node device.
DevEUI of the nodes should be unique and non-zeros.
However, a gateway does not care about the DevEUI of the nodes.
Only Chirpstack server/LoRaWAN server care about the DevEUI of the nodes.
LoRaWAN gateways are dumb/stupid packet forwarder only.
@IoTThinks, when I saw “gateway” I thought “CS.” next, I thought about the CS Server.
I’m using STM32CubeIDE to program the Lora E5 Mini node. When I write zeroes as a DevEUI in a .h header file, this tool fills the right DevEUI. It gets it from the node.
Look what I mean:
This way, I don’t need to remember the DevEUIs of my Lora nodes. It simply works for me.
You may read more to understand why you need a unique DevEUI for each node.
Esp when you use OTAA for the nodes.
Else you will hit weird issue as sharing devEUI is against the design.
All zero DevEUI does not make sense to me, too.
I think you didn’t understand. These zeroes are only in the .h header file. But when you listen to UART from the end node, you might see the right DevEUI for this end node. When I have zeroes in the .h header file, I tell the compiler: “Hey, could you please replace these zeroes with the right DevEUI from the end node?”. And the compiler answered: “Yes, of course.”
1 Like
