Announcing ChirpStack Concentratord

I would like to announce a new ChirpStack Component, the ChirpStack Concentratord! :confetti_ball:

The most used Packet Forwarder currently is the Semtech UDP Packet Forwarder. Support is provided by the ChirpStack Gateway Bridge which handles the UDP communication and transforms this into MQTT payloads. This has been and still is working great, but it has its limitations.

One of the recurring questions I’m getting is if the ChirpStack Network Server supports duty-cycle support. While it would be possible to implement these calculations at the Gateway Bridge or Network Server, technically they should be performed as close to the chipset as possible as a gateway could be shared by multiple networks. The Concentratord would be the right place to implement duty-cycle calculations in the future and expose this to the Network Server.

With the Concentratord I also want to make it easier to configure a gateway. Instead of having to know all the calibration values / tx power table values of a specific gateway, With the Concentratord config you only have to set your gateway model. To configure the channels, calculating the radio center frequencies and for each channel the offset is no longer needed.

An EU868 configuration could look like:

# Concentratord configuration.
[concentratord]

# Log level.
#
# Valid options are:
#   * TRACE
#   * DEBUG
#   * INFO
#   * WARN
#   * ERROR
#   * OFF
log_level="INFO"

# Log to syslog.
#
# When set to true, log messages are being written to syslog instead of stdout.
log_to_syslog=false

# Statistics interval.
stats_interval="30s"

  # Configuration for the (ZeroMQ based) API.
  [concentratord.api]

  # Event PUB socket bind.
  event_bind="ipc:///tmp/concentratord_event"

  # Command REP socket bind.
  command_bind="ipc:///tmp/concentratord_command"


# LoRa gateway configuration.
[gateway]

# Antenna gain (dB).
antenna_gain=0

# Public LoRaWAN network.
lorawan_public=true

# Gateway vendor / model.
model="multitech_mtac_lora_h_868_eu868_ap1_gps"

# Gateway ID.
gateway_id="0202030405060708"

  # LoRa concentrator configuration.
  [gateway.concentrator]

  # Multi spreading-factor channels (LoRa).
  multi_sf_channels=[
    868100000,
    868300000,
    868500000,
    867100000,
    867300000,
    867500000,
    867700000,
    867900000,
  ]

  # LoRa std channel (single spreading-factor).
  [gateway.concentrator.lora_std]
  frequency=868300000
  bandwidth=250000
  spreading_factor=7

  # FSK channel.
  [gateway.concentrator.fsk]
  frequency=868800000
  bandwidth=125000
  datarate=50000


  # Beacon configuration.
  #
  # This requires a gateway with GPS / GNSS.
  #
  # Please note that the beacon settings are region dependent. The correct
  # settings can be found in the LoRaWAN Regional Parameters specification.
  [gateway.beacon]

  # Compulsory RFU size.
  compulsory_rfu_size=2

  # Beacon frequency / frequencies (Hz).
  frequencies=[
  	869525000,
  ]

  # Bandwidth (Hz).
  bandwidth=125000

  # Spreading factor.
  spreading_factor=9

  # TX power.
  tx_power=14

If you have a Raspberry Pi based gateway and would like to test the Concentratord, then download the latest ChirpStack Gateway OS image, which works with the Concentratord out-of-the-box! https://www.chirpstack.io/gateway-os/overview/. Gateway specific packages will be released soon.

If you would like to get involved, please let me know. One of the most important tasks is to extend the list of supported models and their calibration values and help is much appreciated :slight_smile:

Two final notes:

  • The ChirpStack Gateway Bridge will continue to support the Semtech UDP Packet Forwarder
  • The concept of the Concentratord is inspired by the Kerlink Lorad daemon

Looking forward to your feedback!

5 Likes

Dear brocaar,
I understand that Concentratord is a replacement for the Semtech UDP Packer Forwarder.

So the last version of Gateway OS does not use Semtech UDP Packet Forwarder anymore, so we cannot use the ChirpStack multiplexer to forward uplinks to our ChirpStack NS and TTN simultaneously.

am I right?

Kind regards from Madrid

A few new features that will be coming to the Concentratord (when used together with the ChirpStack Gateway Bridge):

Channel-plan reconfiguration

This makes it possible to re-configure the Concenatratord channel-plan over MQTT at any time. I’m planning to use this together with the Gateway Profile (with documentation which hopefully better explains what the Gateway Profile does). See also: Who is using the Gateway Profile / how are you using it?.

Metadata

In https://github.com/brocaar/chirpstack-concentratord/commit/6c7ce84a14c6df4e22b257f8bbd51cc6a68ccc1f I I implemented forwarding gateway metadata (like model, HAL version, …). This information will be visible under the gateway metadata in the web interface:

Support for different gateways

I have started to add calibration values for various vendors / gateway models. I have also started adding packaging scripts for creating gateway specific .ipk packages. Please refer to https://github.com/brocaar/chirpstack-concentratord for more information.

If one would like to get involved, adding new calibration values for gateways would be easy task :slight_smile: Also providing feedback would be really helpful!


@jfmb yes, that is (currently) correct. However, with the Concentratord it is possible to run multiple forwarders simultaneously. One would need to implement it, but there could be additional forwarders running to forward data as UDP.

1 Like

Are there any docs on the configuration for concentratord? I have managed to get the semtech/lora-net packet forwarder working with my RAK2245 board on an orangepi zero/armbian, but I want to see if concentratorD would run too. But for both implementations I can’t really find decent docs on the configuration parameters aside from some comments in the config files themselves.

A very specific question I have is what the “lorawan_public” parameter does.

Another question is how I can change the spidev settings. Depending on the gateway OS/board, the spidev device can change, and also the RESET GPIO pins. Is there a way I can change those? On my device it is for instance spidev1.0 not spidev0.0 and the GPIO pin is also not the standard RAK2245 pin (GPIO pin 17 on a raspberry pi, but GPIO pin 1 on my board).

This is quite a specific question, as most RAK2245 boards are combined with a Raspberry Pi. In this case you can use the ChirpStack Gateway OS already which comes pre-configured with the Concentratord.

However, I am planning to add more documentation about Concentratord. Currently I’m doing quite a bit of refactoring to support multi-downlink support (https://github.com/brocaar/chirpstack-network-server/commit/8ad3f71d6048b6ad6b5c6d73c4f071b3914f7653 + https://github.com/brocaar/chirpstack-gateway-bridge/commit/463423ef309cb731ffdabfaba57a6d7d03d2bfb6) which I also want to make part of Concentratord, before releasing it as “stable” + some other tidying up :slight_smile:

I am also planning to provide packages for various gateway brands and models.

Ok, cool. I will hold off on concentratord for now. I am using an orangepi zero, not a raspberry pi, so run armbian instead of raspbian. And I also want other software running on it, so I don’t like to use fully built images. I like to build my own. The debian repos you created is more than enough for me (and I expect many people, building a gateway is not a linux beginner activity). For me providing good config docs is more valuable than pre-built OS images.

Hi @brocaar, I too am looking forward to your refactoring and more configuration documentation as like @dolfandringa I too add more software to the gateway. I also created my own overlay file (/boot/overlay/….) to configure hardware at boot time. So for me, I would also have to build my own image and not use a pre-built OS image.

Thanks for the great work with the whole Chirpstack system.

1 Like