How to setup multiple channels in 1 region? (US915) v4

First, I know there is a ton of documentation out there, but I can not seem to find a good guide on how to set up US915 and define the 8 channel groups? This would be subbands 1-8. Right now I am running on subband 1. In certain situations I may want to use different subbands for different applications. It looks like I need to set up multiple gateway server applications. Can anyone point to a guide to get this implemented?

I already have the chirpstack.toml with all of the subbands listed.

Yes, it appears that you need multiple gateway bridges (GWBs). I suppose this is how Chirpstack identifies the channel plan and backhaul protocol of the gateway, which is by the gateway bridge that it communicated with. By extension, the GWB is associated with a channel plan by a “region ID”. I say “channel plan” because you are using US915 for all these GWBs, but they use different channel layouts.

You start multiple instances of the gateway bridge, each time specifying the configuration file it should refer to for its settings. This file defines the MQTT topics that the GWB component will interact with, which indicate the region ID to Chirpstack.
If you use Docker Compose, you can define each instance as a separate container. If you use Linux directly, you can start and manage each instance with different systemd service units.

Please note that channels are defined within the gateway, if you use the GWMP/UDP Packet Forwarder. If you use BasicStation, the channels are defined within the gateway bridge’s configuration file.

I am running Linux. Docker makes more sense once I can figure that out. I’ll have to research a bit on how to run multiple gateway server instances at the same time. That is where I am stuck.

You can do it from Linux. I don’t have much experience with using Chirpstack directly on Linux because I am a Windows user and our production deployments involve Kubernetes.

There should be a systemd service unit installed. Probably under /etc/systemd/system or /usr/lib/systemd/system.

You probably need to duplicate this. There should be a command inside that starts the chirpstack-gateway-bridge, specifying the configuration file to use. You need to update this line, for every copy you make.

Once you are done with that, do:

sudo systemctl daemon-reload

You can then enable and start the individual services, with systemctl:

sudo systemctl enable chirpstack-gateway-bridge-us915_0
sudo systemctl start chirpstack-gateway-bridge-us915_0
2 Likes

Neither file specifies anything related to the toml file or specific subband. It simply calls the program. It also shows both files are not writable. I did some searching and could not find any other files.

The running of multiple gateway servers seems the most logical way, but I can not find out how to do it.

Looking for additional options or advice.

Please refer to the documentation: Configuration - ChirpStack open-source LoRaWAN® Network Server documentation

In the event no configuration file is specified, it will look in these areas:

  • chirpstack-gateway-bridge.toml (current working directory)
  • $HOME/.config/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml
  • /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml

But you can add the -c option, to pass along a path to a specific configuration file to use.

If the file is not writable, that is probably because you do not have the necessary privileges to. You can sudo to temporarily give yourself the rights to modify/create files in that folder.
This is kind of a basic thing to know about this OS, so it might be that you need to get more experience with working with this OS.

I resolved the file writable issue :+1:

I guess the issue I am first having is that I do not understand how to run multiple chirpstack-gateway-bridge services. If I could run X number of these then they would essentially all point to the same chirpstack-gateway.bridge.toml. From there I could duplicate a .toml and then set it up for each running service.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.