Receive data in 2 or more gateways simultaneusly

I have 2 Raspberry + RAK2245 Gateways installed with a slightly different hardware setup, meaning that one uses a raspberry 3 and the other a raspberry 4. I’ve correctly set up ChirpStack on the raspberry 3 Gateway that I will be referring to as Rak3 and I can successfully send and receive data using a Temperature, Humidity, and Environmental sensor.

I’ve replicated the same configuration on the Rak3 Gateway meaning that I have copied the initial Rak4 Application key to the Rak3, I’ve set the Gen Application key to both of them to 00 00 00 … (because this way it works and have no idea if or why should I need to set this up) and I have also copied the Device EUI from the Rak4 configuration
to the Rak3.

I’m using the Environment_Monitoring.ino and I’ve correctly edited and uploaded the nodeDeviceEUI[8] , nodeAppEUI[8] and nodeAppKey[16] variable accordingly.

Now even if I can see both gateways showing an Activation status, the Rak3 Gateway doesn’t get any data while the other does.







Can you please tell me what needs to be done in order to receive the data in both gateways?

Hello @digib
Are you using OTAA?
Your device can only join on one network server, not on two at the same time. So if your device sends out a Join Request, and you have registered the device on both network servers, the Join Accept used by the WisNode is the one which comes first.
With the Join Accept, the server sends a well a new encryption key (AppSkey and NwSkey) that will be used from that point on for the encryption of the packets. So only the network server that sent the Join Accept first is able to decrypt the packets and process them. The other one will ignore them.

Yes, I’m using OTAA.
I’ve acknowledged that only one network server will receive the packets. Is there a way that I could send the data to both gateways?
If not, what are the other options if for example one of the gateways is not reachable - can I switch to the other one?

Think about following configuration:
RPi(1) - Gateway + Chirpstack LoRaWAN server
RPi(2) - Gateway only, forwarding packets to Chirpstack LoRaWAN server on RPi(1)

If the LoRaNode is in range of both RPi(1) and RPi(2), both gateways forward the packet ot the Chirpstack LoRaWAN server. The server figures out by himself that the packet has arrived twice and discards one.

If the LoRaNode is in range of RPi(1) only, the gateway of RPi(1) forwards the packet to the LoRaWAN server.

If the LoRaNode is in range of RPi(2) only, the gateway of RPi(2) forwards the packet to the LoRaWAN server on RPi(1)

That is how LoRaWAN works. You cannot have a Node registered on two servers.

Ok, got that! Thanks for the detailed explanation. Now I need to figure out how to make RPi(2) a Gateway Only. Any resources on that?

I am not an expert in building gateways (I prefer our Edge Gateways). But I would look in the RAK2245 section for help on this.

Install the RAK software as per instructions, when asked, install as gateway, do NOT choose Chirpstack.

Ultimately once you have more than one gateway you probably want to run Chirpstack (or whatever) server in the cloud.

You can have one pi running as a bare gateway forward its traffic to chirpstack running on the other, but only if you can route packets directly between them, eg, typically only if they’re both on the same local network. Typically in an actual deployment the gateways would be some distance apart, and have distinct connections to the Internet. At that point rather than messing with firewals or VPNs or tunnels to allow incoming traffic, its a lot simpler to just run the server in the cloud and have both gateways (both running as just a gateway) connect to it.

That also means that if you have a hardware failure of a gateway, or its SD card, or it gets stolen, you can just start up another gateway to point at the cloud server, which still has all of your node secrets and even OTAA sessions.

Chirpstack should have fairly straightword instructions for setting it up in the cloud, you can probably also get an instance managed by someone else or a shared multi-tenant one.