We are currently using a single RAK2287/Raspberry Pi running the RAK-customized ChirpStack platform, connected to a cellular modem for backhaul to our servers. This setup yields amazing coverage over the city. (4+ km radius!) I will call this a “RAK Unit” for easy discussion below.
Even so, there are certain areas of the city where this coverage will not reach. So we would like to add at least one more RAK Unit identical to the above. The RAK Units would be separated by some distance, but near enough to each other that it is possible they will both hear some of the same end devices. In other words, there would be overlapping coverage between the two devices.
What is the suggested way to configure a setup with multiple receiver units like this, to ensure end devices can talk to whichever RAK Unit can hear them best? Or is it necessary to add each end device to only one RAK Unit, having pre-determined which unit receives the best signal?
If you are using Chirpstack this is taken care of already. The way LoRaWAN works is like this:
Gateways (RAK Unit in your case) receive transmission from multiple nodes, also one node can be heard from multiple gateways. They forward this to the LoRaWAN Network server stack, in your case Chirpstack. Any packets that are duplicated are removed and only one is left. Thus, you can safely extend the coverage overlapping it even.
So my difficulty is in understanding how the multiple independent chirpstack installations talk to each other.
In my case each rak device is connected to a raspberry pi running the entire chirpstack app stack independently. They are not connected to a common cloud server. These pi units are located in physically disparate locations, with no awareness of or connection to each other.
Is there a way to make the chirpstack apps aware of each other via either cellular internet or the Lora radio so that they can perform deduplication on incoming packets from end devices?
Maybe I need to change the setup to move one or more of the chirpstack modules to a commonly accessible cloud server instead of running all modules locally on each pi?
Your case seems to be a very peculiar one. Why are you running a ChirpStack on every Gateway, to begin with?
If you want to perform de-duplication of packet, just have 1 chirpstack that takes care of all the packets, right?
This is kind of the way LoRaWAN was designed, multiple gateways with duplicated packets talking to one server that de-duplicates
Running Chirpstack or another server on the gateway itself is effectively a “demo mode” or “small, isolated network” mode. Easy to get started, but limited in that a node can only “belong” to one gateway and if something happens to that gateway, the node session records may be lost.
For a multi-gateway network you should switch to a single instance of Chirpstack running the cloud, which indeed is the traditional LoRaWAN architecture. That way nodes seamlessly use whichever gateway is best, and you can replace gateways with no interruption in service.
@cstratton OK that makes sense.
I was running the “stack” that is downloadable from RAK’s github which installs all components of Chirpstack on the local RPi.
You shouldn’t need to actually download a new image, I believe there’s a way to simply disable the copy of chirpstack running on the pi, but keep the gateway bridge running locally.
And then you point the gateway bridge running on the pi at your cloud install - the chirpstack site has directions for setting that up.
