RAK5146 + ChirpStack OS: Concentratord Crash After Adding 869.5 MHz (LoRaWAN P-band)

jagd700 · May 2, 2025, 9:15am

I am using a RAK5146 concentrator (SX1303-based) with ChirpStack Gateway OS 4.7.0 Full (for Raspberry Pi).
I modified the configuration files (region_eu868.toml, chirpstack-concentratord.toml, chirpstack-gateway-mesh.toml) to add 869.5 MHz as an extra channel, intending to operate in the LoRaWAN P-band (869.4–869.65 MHz) where higher transmit power (up to 27 dBm) and 10% duty-cycle is allowed.

After applying these changes, the ChirpStack Concentratord service crashes or fails to fully initialize.

Details of the changes:
In region_eu868.toml:
Removed 867900000 Hz from regions.gateway.channels.
Added 869500000 Hz to regions.gateway.channels.
Removed 867900000 Hz from regions.network.extra_channels.
Added 869500000 Hz to regions.network.extra_channels.

In chirpstack-gateway-mesh.toml:
Configured mesh communication to operate on 869500000 Hz.

In chirpstack-concentratord.toml:
Updated to match the new regional plan.

Theoretically, the RAK5146 is able to use the LoRaWAN P-band and it is legal to do so. So why is this not working?

brocaar · May 2, 2025, 9:21am

Most likely, this is caused by hardware limitations of the SX130X. The configured channels need to fit within the supported bandwidth of the two radios on the concentrator module. Based on the channel configuration each radio will be configured to a center frequency and and each channel gets assigned to one of the two radios. The supported bandwidth of each radio is ~ 1 MHz.

Most likely, you will see this error in your logs:

github.com/chirpstack/chirpstack-concentratord

chirpstack-concentratord-sx1302/src/config/helpers.rs

master


      
          
              let radio_bandwidth = get_radio_bandwidth(bandwidth);
              for (i, radio_freq) in radios.iter().enumerate() {
                  if chan_min >= radio_freq - (radio_bandwidth / 2)
                      && chan_max <= radio_freq + (radio_bandwidth / 2)
                  {
                      return Ok(i);
                  }
              }
          
              Err(anyhow!("channel does not fit in radio bandwidth"))
          }
          
          #[cfg(test)]
          mod tests {
              use super::super::vendor::semtech;
          
              #[test]
              fn test_get_radio_frequencies() {
                  let tests = vec![
                      (

jagd700 · May 9, 2025, 6:39pm

Hi Brocaar, thank you very much for your detailed explanation — that was extremely helpful!

Just to clarify and follow up:

Is there any way to solve this limitation and still include the 869.5 MHz channel? For example, is it possible to explicitly configure the center frequencies of the radios to better accommodate that frequency?
From your explanation, I understand that the concentratord assigns the radios’ center frequencies automatically. Is there a way to override or manually configure them?
If manual configuration is not possible, would an alternative approach be to select a set of channels that are closer together (e.g., removing some of the default 867.x or 868.x MHz channels) in order to ensure all used channels fall within two 1 MHz bandwidth windows? Would this workaround be sufficient to include 869.5 MHz?

Jason_Reiss · May 9, 2025, 9:07pm

Removing the 867 channels should help.
867.9 could be used and grouped with 868.1,3,5 to fit in 1MHz.