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.
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.
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 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.
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.
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.”