Giter Site home page Giter Site logo

chirpstack / chirpstack-concentratord Goto Github PK

View Code? Open in Web Editor NEW
72.0 3.0 51.0 1020 KB

Concentrator HAL daemon for LoRa gateways.

Home Page: https://www.chirpstack.io/

License: MIT License

Makefile 1.25% Rust 98.57% C 0.10% Nix 0.08%
lorawan iot gateway chirpstack lora-packet-forwarders lora

chirpstack-concentratord's Introduction

ChirpStack Concentratord

Tests

ChirpStack Concentratord is an open-source LoRa(WAN) concentrator daemon, part of the ChirpStack project. It exposes a ZeroMQ based API that can be used by one or multiple applications to interact with gateway hardware. By implementing and abstracting the the hardware specifics in a separate daemon and exposing this over a ZeroMQ based API, the packet forwarding application can be completely decoupled from the gateway hardware. It also allows for running multiple packet forwarding applications simultaniously.

Documentation and binaries

Please refer to the ChirpStack website for documentation and pre-compiled binaries.

Building from source

Requirements

Building ChirpStack Concentratord requires:

Nix

Nix is used for setting up the development environment which is used for local development and for creating the binaries.

If you do not have Nix installed and do not wish to install it, you could install the packages listed in shell.nix by hand, using your package-manager of choice.

Docker

Docker is used by cross-rs for cross-compiling.

Starting the development shell

Run the following command to start the development shell:

nix-shell

Running tests

Execute the following command to run the tests:

make test

Building binaries

Execute the following commands to build the ChirpStack Concentratord binaries and packages:

# Only build binaries
make build

# Build binaries + distributable packages.
make dist

License

ChirpStack Concentratord is distributed under the MIT license. See LICENSE.

chirpstack-concentratord's People

Contributors

aurel32 avatar brocaar avatar dependabot[bot] avatar dougreese avatar felipeacp avatar frieger avatar jdeinum avatar lounecode avatar mattftw avatar papadkostas avatar sophiekovalevsky avatar trick-1 avatar xoseperez avatar yon2004 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

chirpstack-concentratord's Issues

wrapper.h:3:10: fatal error: 'libloragw-sx1302/loragw_com.h' file not found

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

cargo build return error

What did you expect?

build this project without any error

Steps to reproduce this issue

Steps:

  1. Install rust
  2. git clone https://github.com/brocaar/chirpstack-concentratord.git
  3. switch to v3.2.0 tag
  4. run cargo build command in the top folder

Could you share your log output?

Compiling humantime-serde v1.0.1
Compiling libloragw-sx1302 v1.0.0 (/home/sensedge/workspace/lora/chirpstack-concentratord/libloragw-sx1302)
Compiling libloragw-sx1301 v1.0.0 (/home/sensedge/workspace/lora/chirpstack-concentratord/libloragw-sx1301)
Compiling libloragw-2g4 v1.0.0 (/home/sensedge/workspace/lora/chirpstack-concentratord/libloragw-2g4)
Compiling chirpstack_api v3.9.7
error: failed to run custom build command for libloragw-sx1302 v1.0.0 (/home/sensedge/workspace/lora/chirpstack-concentratord/libloragw-sx1302)

Caused by:
process didn't exit successfully: /home/sensedge/workspace/lora/chirpstack-concentratord/target/debug/build/libloragw-sx1302-854eee157eb1870e/build-script-build (exit status: 101)
--- stdout
cargo:rustc-link-lib=loragw-sx1302
cargo:rustc-link-lib=tinymt32

--- stderr
wrapper.h:3:10: fatal error: 'libloragw-sx1302/loragw_com.h' file not found
wrapper.h:3:10: fatal error: 'libloragw-sx1302/loragw_com.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', libloragw-sx1302/build.rs:23:10
stack backtrace:
0: rust_begin_unwind
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
1: core::panicking::panic_fmt
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
2: core::result::unwrap_failed
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1355:5
3: core::result::Result<T,E>::expect
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:997:23
4: build_script_build::main
at ./build.rs:14:20
5: core::ops::function::FnOnce::call_once
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

Your Environment

Ubuntu 20.04 x86_64
cargo 1.54.0 (5ae8d74b3 2021-06-22)

Component Version
Concentratord v3.2.0

Crash when receiving configuration command?

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

chirpstack-concentratord-sx1302 crashes stops/crashes when it receives a 'Configuration' command.

What did you expect?

That it keeps running :)

Steps to reproduce this issue

I've installed the chirpstack-concentratord-sx1302 and the mqtt forwarder. I've linked these two together (config's below).
My docker deployed chirpstack is on another machine, so the mqtt forwarder connects to that.

It seems that on update from chirpstack, a configuration is passed along to the concentrator and then it crashes.

Could you share your log output?

mqtt.log
crash.log

Your Environment

forwarder.toml:

# Logging settings.
[logging]

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

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


# MQTT settings.
[mqtt]

  # Topic prefix.
  #
  # ChirpStack MQTT Forwarder publishes to the following topics:
  #
  #  * [Prefix/]gateway/[Gateway ID]/event/[Event]
  #  * [Prefix/]gateway/[Gateway ID]/state/[State]
  #
  # And subscribes to the following topic:
  #
  #  * [Prefix/]gateway/[Gateway ID]/command/[Command]
  #
  # The topic prefix can be used to define the region of the gateway.
  # Note, there is no need to add a trailing '/' to the prefix. The trailing
  # '/' is automatically added to the prefix if it is configured.
  topic_prefix="eu868"

  # Use JSON encoding instead of Protobuf (binary).
  #
  # Note, only use this for debugging purposes.
  json=false

  # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
  server="tcp://jubilee.lnd.prof-x.net:1883"

  # Connect with the given username (optional)
  username=""

  # Connect with the given password (optional)
  password=""

  # Quality of service level
  #
  # 0: at most once
  # 1: at least once
  # 2: exactly once
  #
  # Note: an increase of this value will decrease the performance.
  # For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
  qos=0

  # Clean session
  #
  # Set the "clean session" flag in the connect message when this client
  # connects to an MQTT broker. By setting this flag you are indicating
  # that no messages saved by the broker for this client should be delivered.
  clean_session=false

  # Client ID
  #
  # Set the client id to be used by this client when connecting to the MQTT
  # broker. A client id must be no longer than 23 characters. If left blank,
  # a random id will be generated by ChirpStack.
  client_id=""

  # CA certificate file (optional)
  #
  # Use this when setting up a secure connection (when server uses ssl://...)
  # but the certificate used by the server is not trusted by any CA certificate
  # on the server (e.g. when self generated).
  ca_cert=""

  # TLS certificate file (optional)
  tls_cert=""

  # TLS key file (optional)
  tls_key=""


# Backend configuration.
[backend]

  # Enabled backend.
  #
  # Set this to the backend that must be used by the ChirpStack MQTT Forwarder.
  # Valid options are:
  #   * concentratord
  #   * semtech_udp
  enabled="concentratord"

  # Filters.
  [backend.filters]

    # Forward CRC ok.
    forward_crc_ok=true

    # Forward CRC invalid.
    forward_crc_invalid=true

    # Forward CRC missing.
    forward_crc_missing=true

    # DevAddr prefix filters.
    #
    # Example configuration:
    # dev_addr_prefixes=["0000ff00/24"]
    #
    # The above filter means that the 24MSB of 0000ff00 will be used to
    # filter DevAddrs. Uplinks with DevAddrs that do not match any of the
    # configured filters will not be forwarded. Leaving this option empty
    # disables filtering on DevAddr.
    dev_addr_prefixes=[
    ]

    # JoinEUI prefix filters.
    #
    # Example configuration:
    # join_eui_prefixes=["0000ff0000000000/24"]
    #
    # The above filter means that the 24MSB of 0000ff0000000000 will be used
    # to filter JoinEUIs. Uplinks with JoinEUIs that do not match any of the
    # configured filters will not be forwarded. Leaving this option empty
    # disables filtering on JoinEUI.
    join_eui_prefixes=[
    ]


  # ChirpStack Concentratord backend configuration.
  [backend.concentratord]

    # Event API URL.
    event_url="ipc:///tmp/concentratord_event"

    # Command API URL.
    command_url="ipc:///tmp/concentratord_command"


  # Semtech UDP backend configuration.
  [backend.semtech_udp]

    # ip:port to bind the UDP listener to.
    #
    # Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
    # This is the listener to which the packet-forwarder forwards its data
    # so make sure the 'serv_port_up' and 'serv_port_down' from your
    # packet-forwarder matches this port.
    bind="0.0.0.0:1700"

    # Time fallback.
    #
    # In case the UDP packet-forwarder does not set the 'time' field, then the
    # server-time will be used as fallback if this option is enabled.
    time_fallback_enabled=false


# Gateway metadata configuration.
[metadata]

  # Static key / value metadata.
  [metadata.static]
      
    # Example:
    # serial_number="1234"


  # Commands returning metadata.
  [metadata.commands]

    # Example:
    # datetime=["date", "-R"]


# Executable commands.
[commands]

  # Example:
  # reboot=["/usr/bin/reboot"]

Concentrator.toml:

# Concentratord configuration.
[concentratord]
  # Log level.
  #
  # Valid options are:
  #   * TRACE
  #   * DEBUG
  #   * INFO
  #   * WARN
  #   * ERROR
  #   * OFF
  log_level="DEBUG"

  # 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"

  # Disable CRC status filter.
  #
  # By default, the Concentratord will ignore received frames which do not have
  # a valid CRC. This option makes it possible to disable this filter such that
  # received frames without (valid) CRC can be analyzed.
  disable_crc_filter=false

  # 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

  # Region.
  #
  # The region of the gateway. Options:
  #  EU868, US915, CN779, EU433, AU915, CN470, AS923, AS923_2, AS923_3, AS923_4,
  #  KR923, IN865, RU864
  #
  # Not not all the gateway models implement all regions.
  region="EU868"

  # Gateway vendor / model.
  #
  # This configures various vendor and model specific settings.
  model="rak_5146"

  # Gateway vendor / model flags.
  #
  # Flag can be used to configure additional vendor / model features. The
  # following flags can be used:
  #
  #   Global flags:
  #     GNSS - Enable GNSS / GPS support
  #     USB  - Use USB for concentrator communication (default is SPI)
  model_flags=[ "GNSS" ]

  # Time fallback.
  #
  # In case the gateway does not have a GNSS module or is unable to aquire a
  # GNSS fix, use the system-time for setting the 'time' field on RX.
  time_fallback_enabled=true


  # 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


  # Static gateway location.
  [gateway.location]

    # When set to non-zero values, the static gateway location will be reported
    # when the gateway does not have a GNSS module or when no GNSS location fix
    # is available.
    latitude=0.0
    longitude=0.0
    altitude=0

Versions

cyclops@octoprint:~/chirpstack-concentrator $ ./chirpstack-mqtt-forwarder  --version
chirpstack-mqtt-forwarder 4.1.2

cyclops@octoprint:~/chirpstack-concentrator $ ./chirpstack-concentratord-sx1302 --version
chirpstack-concentratord-sx1302 4.3.3

Chirpstack:

[17:32:36] cyclops@jubilee:~$ docker ps -a | grep chirp
9c3fa9351dee   chirpstack/chirpstack-rest-api:4.1.1          "/usr/bin/chirpstack…"   26 minutes ago   Up 26 minutes                                                                                                                                chirpstack_chirpstack-rest-api_1
53df63f34941   chirpstack/chirpstack-gateway-bridge:4.0.3    "/usr/bin/chirpstack…"   26 minutes ago   Up 26 minutes         0.0.0.0:1700->1700/udp                                                                                                 chirpstack_chirpstack-gateway-bridge-eu868_1
e227798d73fa   chirpstack/chirpstack:4.1.1                   "/usr/bin/chirpstack…"   26 minutes ago   Up 26 minutes         0.0.0.0:8088->8080/tcp                                                                                                 chirpstack_chirpstack_1
3524c80ae870   postgres:14-alpine                            "docker-entrypoint.s…"   26 minutes ago   Up 26 minutes         5432/tcp                                                                                                               chirpstack_postgres_1
89f774a33d19   eclipse-mosquitto:2                           "/docker-entrypoint.…"   26 minutes ago   Up 26 minutes         0.0.0.0:1883->1883/tcp                                                                                                 chirpstack_mosquitto_1
548e57d1c80e   redis:7-alpine                                "docker-entrypoint.s…"   26 minutes ago   Up 26 minutes         6379/tcp                                                                                                               chirpstack_redis_1

How i change reset pin in config?

I'm trying to use the Gateway-OS with raspberry-pi and a concentrator from a company in Brazil, the concentrator has the same configuration as RHF0M301, the only difference from the reset pin.
RHF0M301 reset pin 24
Radioenge concentrator = reset pin 26
I would like to know if I can change the settings to use pin 26.
this concentrator has gps:
GPS RXD - UART TX 8
GPS TXD - UART RX 10
and I'm trying to make it work with Gateway-OS.

Is GPS required

I have gateway OS base running on pi Zero WiFi and forwarding to separate Chirpstack network server. The networkserver/application server is receiving join requests and sending join accept but they never get to the node.

Feb 22 19:24:47 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399487.930063245s
Feb 22 19:24:48 raspberrypi0-wifi user.info chirpstack-concentratord-sx1301[12451]: Frame received, uplink_id: 7a0dea0d-9b27-42e2-ba9a-a55b44dc0775, count_us: 1022705652, freq: 903700000, bw: 125000, mod: LoRa, dr: SF10
Feb 22 19:24:48 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:48Z" level=info msg="backend/concentratord: uplink event received" uplink_id=7a0dea0d-9b27-42e2-ba9a-a55b44dc0775
Feb 22 19:24:48 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:48Z" level=info msg="integration/mqtt: publishing event" event=up qos=0 topic=gateway/be8c8506f284c309/event/up uplink_id=7a0dea0d-9b27-42e2-ba9a-a55b44dc0775
Feb 22 19:24:48 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399488.930631287s
Feb 22 19:24:48 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:48Z" level=info msg="integration/mqtt: downlink frame received" downlink_id=eba706b7-253b-4c9d-a11b-4b8aac47cdaf gateway_id=be8c8506f284c309
Feb 22 19:24:48 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:48Z" level=info msg="backend/concentratord: forwarding downlink command" downlink_id=eba706b7-253b-4c9d-a11b-4b8aac47cdaf
Feb 22 19:24:49 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399489.931189329s
Feb 22 19:24:50 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399490.931945369s
Feb 22 19:24:51 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399491.93268741s
Feb 22 19:24:52 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399492.93343445s
Feb 22 19:24:53 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399493.934175491s
Feb 22 19:24:54 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399494.934981531s
Feb 22 19:24:55 raspberrypi0-wifi user.info chirpstack-concentratord-sx1301[12451]: Frame received, uplink_id: ee6f6bfc-1fdf-4b27-aa4f-6fc83118bbc2, count_us: 1029331459, freq: 903000000, bw: 500000, mod: LoRa, dr: SF8
Feb 22 19:24:55 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:55Z" level=info msg="backend/concentratord: uplink event received" uplink_id=ee6f6bfc-1fdf-4b27-aa4f-6fc83118bbc2
Feb 22 19:24:55 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:55Z" level=info msg="integration/mqtt: publishing event" event=up qos=0 topic=gateway/be8c8506f284c309/event/up uplink_id=ee6f6bfc-1fdf-4b27-aa4f-6fc83118bbc2
Feb 22 19:24:55 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:55Z" level=info msg="integration/mqtt: downlink frame received" downlink_id=a20031f6-8ae9-4d7f-bb27-e3de24e0a43b gateway_id=be8c8506f284c309
Feb 22 19:24:55 raspberrypi0-wifi user.info chirpstack-gateway-bridge[7841]: time="2020-02-22T19:24:55Z" level=info msg="backend/concentratord: forwarding downlink command" downlink_id=a20031f6-8ae9-4d7f-bb27-e3de24e0a43b
Feb 22 19:24:55 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399495.935737571s
Feb 22 19:24:56 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399496.936311613s
Feb 22 19:24:57 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399497.937036653s
Feb 22 19:24:58 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399498.937775694s
Feb 22 19:24:59 raspberrypi0-wifi user.warn chirpstack-concentratord-sx1301[12451]: GPS time reference is not valid, age: 1582399499.938541734s

Node is running MCCI Cantenna compliance-otaa-halconfig.ino

19927578 (318841 ms): EV_JOIN_TXCOMPLETE, saveIrqFlags 0x80, nLateRx=0 ticks=0
20562056 (328992 ms): EV_TXSTART: ch=4 rps=0x04 (SF10 BW125 CR 4/5 Crc IH=0), datarate=0, opmode=88C, txend=20562669, avail=0
20562115 (328993 ms): +Tx LoRa, datum=0x17. opmode=88C
20585302 (329364 ms): radio_irq_handler_v2: LoRa, datum=0x8. opmode=88C
20897046 (334352 ms): EV_RXSTART: freq=925.7 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate=0, opmode=88C, txend=20585296, avail=0, rxtime=20897671, rxsyms=7
20897675 (334362 ms): +Rx LoRa Single, datum=0x0. opmode=88C
20898581 (334377 ms): radio_irq_handler_v2: LoRa, datum=0x80. opmode=88C
20959546 (335352 ms): EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate=0, opmode=88C, txend=20585296, avail=0, rxtime=20960171, rxsyms=7
20960175 (335362 ms): +Rx LoRa Single, datum=0x0. opmode=88C
20963770 (335420 ms): radio_irq_handler_v2: LoRa, datum=0x80. opmode=88C
20963777 (335420 ms): EV_JOIN_TXCOMPLETE, saveIrqFlags 0x80, nLateRx=0 ticks=0
21008384 (336134 ms): EV_TXSTART: ch=64 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate=4, opmode=88C, txend=21008997, avail=0
21008443 (336135 ms): +Tx LoRa, datum=0x17. opmode=88C
21010229 (336163 ms): radio_irq_handler_v2: LoRa, datum=0x8. opmode=88C
21321974 (341151 ms): EV_RXSTART: freq=923.3 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate=4, opmode=88C, txend=21010224, avail=0, rxtime=21322599, rxsyms=14
21322602 (341161 ms): +Rx LoRa Single, datum=0x0. opmode=88C
21322837 (341165 ms): radio_irq_handler_v2: LoRa, datum=0x80. opmode=88C
21384474 (342151 ms): EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate=4, opmode=88C, txend=21010224, avail=0, rxtime=21385099, rxsyms=7
21385102 (342161 ms): +Rx LoRa Single, datum=0x0. opmode=88C
21388697 (342219 ms): radio_irq_handler_v2: LoRa, datum=0x80. opmode=88C
21388704 (342219 ms): EV_JOIN_TXCOMPLETE, saveIrqFlags 0x80, nLateRx=0 ticks=0
21388709 (342219 ms): EV_JOIN_FAILED: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), opmode=C

Is my issue related to the missing GPS data?

AS923-3 on my Seeed WM1302 not working

I have installed Chirpstack Gateway OS and I have been having issues when I select AS923-3 as frequency plan on my Seeed WM1302

image

on the footer it shows "Gateway ID: could not read gateway id" becuase of this it wont connect to network server
however changing the frequency plan to like AS923 does make the gateway id show up and connect to the network server.

the frequncy plan in my country is AS923-3.

Uplink stops being processed correctly by chirpstack if concentratord is used along with mqtt-forwarder with json=true

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

As the title states, uplink stops being processed correctly by chirpstack if concentratord is used along with mqtt-forwarder with json=true.

At this point, the following error occurs for each received uplink (NOTE: gateway eui obfuscated):

ERROR chirpstack::gateway::backend::mqtt: Processing gateway event error: unknown field gwTime, expected one of gateway_id, gatewayId, uplink_id, uplinkId, time, time_since_gps_epoch, timeSinceGpsEpoch, fine_time_since_gps_epoch, fineTimeSinceGpsEpoch, rssi, snr, channel, rf_chain, rfChain, board, antenna, location, context, metadata, crc_status, crcStatus at line 1 column 237 topic="us915_0/gateway/00800000a000XXXX/event/up" qos=0

This issue does not occur in the following scenarios:

  • semtech_udp + mqtt_forwarder + json=true
  • semtech_udp + mqtt_forwarder + json=false
  • concentratord + mqtt_forwarder + json=false

What did you expect?

I'd expect no error on up event.

Steps to reproduce this issue

Steps:

  1. Configure mqtt-forwarder so it uses concentratord backend and set mqtt config block property json to TRUE
  2. Launch concentratord/mqtt_forwarder on gateway
  3. Wait until up event are received by chirpstack
  4. Notice the chirpstack::gateway::backend::mqtt error in the logs

Could you share your log output?

ERROR chirpstack::gateway::backend::mqtt: Processing gateway event error: unknown field gwTime, expected one of gateway_id, gatewayId, uplink_id, uplinkId, time, time_since_gps_epoch, timeSinceGpsEpoch, fine_time_since_gps_epoch, fineTimeSinceGpsEpoch, rssi, snr, channel, rf_chain, rfChain, board, antenna, location, context, metadata, crc_status, crcStatus at line 1 column 237 topic="us915_0/gateway/00800000a000XXXX/event/up" qos=0

Your Environment

Environment all uses latest version (v4) of chirpstack, chirpstack-concentratord and chirpstack-mqtt-forwarder. Gateway used is Multitech Conduit (MTCDT-0.1).

Duty cycle tracking causes downlink to be rejected for antenna gains < 2dBi

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

Thanks for adding duty-cycle tracking to chirpstack-concentratord v4.4.0. While the time part works fine, the power part does not work with the default power level in the EU868 region and an antenna gain below 2. Downlinks get rejected, even if duty cycle enforcement is not enabled.

What did you expect?

From the regulation a 16 dBm EIRP should be allowed for the M band and a 29 dBm EIRP should allowed for the P band.

Steps to reproduce this issue

Steps:

  1. Set the antenna gain to 0 or 1 dBi
  2. Schedule a downlink
  3. See it getting rejected

Could you share your log output?

MQTT logs:

chirpstack/eu868/gateway/xxxxxxxxxxxxxxxx/command/down {"downlinkId":691944082,"items":[{"phyPayload":"YMaLLQKgQwABLts0PT8=","txInfo":{"frequency":868100000,"power":16,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":7,"codeRate":"CR_4_5","polarizationInversion":true}},"timing":{"delay":{"delay":"1s"}},"context":"BIMWzQ=="}},{"phyPayload":"YMaLLQKgQwABLts0PT8=","txInfo":{"frequency":869525000,"power":29,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":12,"codeRate":"CR_4_5","polarizationInversion":true}},"timing":{"delay":{"delay":"2s"}},"context":"BIMWzQ=="}}],"gatewayId":"xxxxxxxxxxxxxxxx"}
chirpstack/eu868/gateway/xxxxxxxxxxxxxxxx/event/ack {"gatewayId":"xxxxxxxxxxxxxxxx","downlinkId":691944082,"items":[{"status":"DUTY_CYCLE_OVERFLOW"},{"status":"DUTY_CYCLE_OVERFLOW"}]}

Console logs (with an antenna gain of 1 dBi):

WARN  [libconcentratord::jitqueue] No duty-cycle band found for packet, downlink_id: 691944082, freq: 868100000, tx_power: 15
WARN  [libconcentratord::jitqueue] No duty-cycle band found for packet, downlink_id: 691944082, freq: 869525000, tx_power: 28

(Notice how the antenna gain has been subtracted at that level)

Your Environment

Component Version
Network Server v4.7.0
MQTT Forwarder v4.3.0
Concentratord v4.4.0

Analysis

The transmitted TX power is configured the following way:

  • Chirpstack sends the downlink command to chirpstack-concentratord with EIRP TX power
  • The antenna gain (in dBi) is subtracted from this TX power
  • The transmitter is configured with the resulting TX power
    Up to there that looks all fine, with a high gain antenna (relative to isotropic) the transmitter is configured to use less power, with a bad antenna (or a very long and bad cable) having a negative gain, the transmitter is configured to use more power. At the end the radiated power is the same.

Now comes the ETSI EN 300 220 regulation. The etsi_en_300_220.rs lists for each band maximum allowed duty cycle and the maximum TX power. In that file, the TX powers are actually ERP TX powers, so 2.15 dB lower (rounded to 2 dB) than the EIRP TX powers. In practice chirpstack-concentratord:

  • Gets the EIRP TX power from the downlink packet
  • Subtracts the antenna gain
  • Tries to match it to the ERP power from ETSI EN 300 220

In short it tries to match the transmitter power to the regulation, while the regulation applies to the radiated power by the antenna. Therefore I think the regulation matching should be done by converting the EIRP to ERP (or vice versa) and before subtracting the antenna gain.

Feature Request for IN865 channel-plan concentratord region for Shield Model Waveshare - SX1302 LoRaWAN gateway HAT

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Installed Chirpstack Gateway OS (Full) on Raspberry pi and it prompted below error when installed Waveshare - SX1302 LoRaWAN gateway HAT and selected channel plan as IN865 standard channels.

Waveshare_SX1302_Error

What is the use-case?

Add support for channel plan IN865 standard channels for Waveshare - SX1302 LoRaWAN gateway HAT.

Add support for the IMST iC280A

Currently the ChirpStack Concentratord only supports the Semtech 2.4 GHz reference design (SX1280) as option to setup the LoRa concentrator shield. In addition to the already supported iC880A and iC980A, the newest IMST iC280A could be a nice addition to the supported concentrator modules.

Concentratord overrides static/dynamic metadata defined in mqtt-forwarder configuration file

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

MQTT forwarder metadata defined gets overriden by concentratord (either static or dynamic metadata). NOTE: commands are not affected by this issue (one can execute custom commands as defined in mqtt-forwarder, whether used backend is concentratord or semtech_udp

What did you expect?

I would expect that the static/dynamic metadata defined in mqtt-forwarder appears along with concentratord self-defined metadata in Chirpstack Gateways -> Configuration -> Metadata page.

Steps to reproduce this issue

Steps:

  1. Define some metadata (either static and/or dynamic) in mqtt-forwarder and configure it so it uses concentratord backend
  2. Run mqtt-forwarder along with concentratord on the gateway
  3. In Chirpstack, access the gateway configuration / metadata page. The custom defined metadata does not appear, only concentratord-related metadata
  4. Now modify mqtt-forwarder so it uses semtech_udp backend.
  5. Restart mqtt-forwarder & semtech packet forwarder
  6. In Chirpstack, access the gateway configuration / metadata page. The custom defined metadata will appear as expected.

Could you share your log output?

No log file involved.

Your Environment

Environment all uses latest version (v4) of chirpstack, chirpstack-concentratord and chirpstack-mqtt-forwarder

Provide an option to forward packets with bad/missing CRC

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Add an option, in the configuration file, to forward packets with bad/missing CRC. The same way the Semtech UDP Packet Forwarder does.

What is the use-case?

In case of device development, testing, debugging and diagnostic those packets can be useful on the server side.

Implementation description

At the check if CRC is ok, add a check on the options to see if the packet must be dropped.

Also, it seems that there is a little "bug" actually. If the CRC is missing, the log will report that there was a packet with bad crc:

WARNING: the UDP forwarder connecting to the concentratord expects the CRC to be OK at this time and does override status. This means there must first be an adaptation of this software.

Can you implement this by yourself and make a pull request?

Yes possibly.

LoRa server with RAK5146 (using mini PCI to USB) and Raspberry Pi3

  • [ X ] The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

chirpstack-concentrator not initialized

What did you expect?

Create a local server to send and receive information to an end node.

Steps to reproduce this issue

Steps:

  1. installed ChirpStack Gateway OS full version
  2. I used a RAK5146 hub with a mini PCI adapter and a Raspberry Pi3.

Could you share your log output?

MicrosoftTeams-image (1)

Uploading MicrosoftTeams-image.png…

I've tried everything and it doesn't work at all :/

MTCAP3: wrong gateway_id reported by concentratord to mqtt-forwarder

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

Using MTCAP3 gateway and the latest concentratord/mqtt-forwarder chirpstack pre-compiled packages, the gateway_id reported by the concentratord (or read by the mqtt-forwarder) does not match the configured gateway_id inside concentratord.toml configuration file:

gateway_id="0000000000000000"

After starting concentratord/mqtt-forward processes, the following can be seen in the logs:

2023-12-13T13:41:21.293871+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Starting the concentrator
2023-12-13T13:41:23.807940+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Gateway ID retrieved, gateway_id: "0016c001f1388eb8"
2023-12-13T13:44:49.899489+00:00 mtcap3 chirpstack-mqtt-forwarder[1793]: Reading gateway id
2023-12-13T13:44:49.913138+00:00 mtcap3 chirpstack-mqtt-forwarder[1793]: Received gateway id, gateway_id: 0016c001f1388eb8
2023-12-13T13:44:49.914460+00:00 mtcap3 chirpstack-mqtt-forwarder[1793]: Received Gateway ID from backend, gateway_id: 0016c001f1388eb8

This does not occur on a MTCDT gateway.

What did you expect?

I would expect the reported gateway id by concentratord/mqtt-forwarder to matches the gateway id as defined in the concentratord.toml configuration file on the MTCAP3 gateway.

Steps to reproduce this issue

Steps:

  1. On the MTCAP3, setup a mqtt-forwarder + concentratord.
  2. Set the gateway_id parameter to whatever value in concentratord.toml configuration file
  3. Restart the mqtt-forwarder / concentratord processes.
  4. Inspect the logs, gateway id reported by concentratord / mqtt-forwarder will not match the one defined in concentratord.toml configuration file

Could you share your log output?

2023-12-13T13:41:54.072747+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Stopping the concentrator
2023-12-13T13:41:54.079098+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Updating concentrator configuration
2023-12-13T13:41:54.080469+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Starting Concentratord SX1302 (version: 4.3.4, docs: https://www.chirpstack.io/docs/chirpstack-concentratord/)
2023-12-13T13:41:54.081765+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Executing reset command, command: mts-io-sysfs, args: ["store", "lora/reset", "0"]
2023-12-13T13:41:54.219920+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Executing reset command, command: mts-io-sysfs, args: ["store", "lora/reset", "1"]
2023-12-13T13:41:54.361003+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Setting i2c device path, path: /dev/i2c-1
2023-12-13T13:41:54.361362+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Setting board configuration, lorawan_public: true, clock_source: 0, com_type: Spi, com_path: /dev/spidev1.0
2023-12-13T13:41:54.361648+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Setting up fine timestamp, enable: false
2023-12-13T13:41:54.361892+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Setting up concentrator channels
2023-12-13T13:41:54.362205+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring radio, radio: 0, enabled: true, center_freq: 902700000, type: SX1250
2023-12-13T13:41:54.362472+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring radio, radio: 1, enabled: true, center_freq: 903700000, type: SX1250
2023-12-13T13:41:54.362691+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Setting up concentrator channels
2023-12-13T13:41:54.362993+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 0, enabled: true, freq: 902300000, rf_chain: 0, if_freq: -400000
2023-12-13T13:41:54.363272+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 1, enabled: true, freq: 902500000, rf_chain: 0, if_freq: -200000
2023-12-13T13:41:54.363541+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 2, enabled: true, freq: 902700000, rf_chain: 0, if_freq: 0
2023-12-13T13:41:54.363795+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 3, enabled: true, freq: 902900000, rf_chain: 0, if_freq: 200000
2023-12-13T13:41:54.368515+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 4, enabled: true, freq: 903100000, rf_chain: 0, if_freq: 400000
2023-12-13T13:41:54.369768+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 5, enabled: true, freq: 903300000, rf_chain: 1, if_freq: -400000
2023-12-13T13:41:54.371004+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 6, enabled: true, freq: 903500000, rf_chain: 1, if_freq: -200000
2023-12-13T13:41:54.372219+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring multi-SF LoRa channel, channel: 7, enabled: true, freq: 903700000, rf_chain: 1, if_freq: 0
2023-12-13T13:41:54.373417+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring Std LoRa channel, enabled: true, freq: 903000000, rf_chain: 0, if_freq: 300000
2023-12-13T13:41:54.374594+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Configuring FSK channel, enabled: false, freq: 0, rf_chain: 0, if_freq: 0
2023-12-13T13:41:54.376791+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Starting the concentrator
2023-12-13T13:41:56.882896+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Gateway ID retrieved, gateway_id: "0016c001f1388eb8"
2023-12-13T13:41:56.884252+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Initializing JIT queue, capacity: 32
2023-12-13T13:41:56.885795+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Creating socket for publishing events, bind: ipc:///tmp/concentratord_event
2023-12-13T13:41:56.892755+00:00 mtcap3 chirpstack-concentratord-sx1302[1521]: Creating socket for receiving commands, bind: ipc:///tmp/concentratord_command
2023-12-13T13:44:29.661536+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Starting ChirpStack MQTT Forwarder (version: 4.1.3, docs: https://www.chirpstack.io/)
2023-12-13T13:44:29.662329+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Setting up ChirpStack Concentratord backend
2023-12-13T13:44:29.663187+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Setting up ChirpStack Concentratord backend
2023-12-13T13:44:29.665181+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Connecting to Concentratord event API, event_url: ipc:///tmp/concentratord_event
2023-12-13T13:44:29.667677+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Connecting to Concentratord command API, command_url: ipc:///tmp/concentratord_command
2023-12-13T13:44:29.668930+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Reading gateway id
2023-12-13T13:44:29.676716+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Received gateway id, gateway_id: 0016c001f1388eb8
2023-12-13T13:44:29.677987+00:00 mtcap3 chirpstack-mqtt-forwarder[1744]: Received Gateway ID from backend, gateway_id: 0016c001f1388eb8

Your Environment

Component Version
MQTT Forwarder 4.1.3
Concentratord 4.3.4

Hardware configuration file

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

My SX1302 has a pinout which is different from any of the ones you have configured, and when I went to try and fix it I noticed that the configurations are defined in several separate files, and I would need to find all of the parameters and recompile if I wanted to add my hardware. I'm not very familiar with rust, and there is likely a technical reason this was done, but if the program can parse the config.toml file and substitute the values into the code, why couldn't it parse a hardware config file so I could define them in a central place?

Again, I'm not the most familiar with rust, but it makes sense that those values maybe need to be compiled in for efficiency reasons, but could the hardware config file be parsed at compile time?

What is the use-case?

Users who don't have a device which is supported by the program directly could use concentratord by defining the parameters and recompiling.

Implementation description

A "custom" keyword added to the list of hardware configurations in the toml, which signals the program to confirm that another "hardware configuration path" is defined in the toml.
The parameters that you already define in the other vendor configurations could be templated into its own toml file, and parsed by the program/compiler when the values are needed; whether at compile time or runtime.

Can you implement this by yourself and make a pull request?

No, I would just add the one vendor hardware configuration if I could, but I can't find where to put the values.

Support for RAK2287

If knew how to go about it would try to add myself but not so confident from looking at other examples..

Chirpstack-consertratord-sx1302 backend - Fine Timestamp is missing from uplink event?

  • [ x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary

I have investigated the consentratord backend code and found that the Fine timestamp information basis on PPS signal missing from current implementation?

Consertratord-sx1302 implementation has been build on Semtechs's HAL library (libloragw). Sx1302_hal library includes code for Fine timestamp implementation (for hardware with PPS signal). It seems that the Fine Timestamp solution can be added to consertratord-sx1302 backend quite easily.

Similar cases can be found from following issues:

 

What is the use-case?

A Fine Timestamp is used to get the TDoA geolocation of the transmitter (sensor).

Implementation description - Solution proposal

Add Fine Timestamp information to the up-event of the concentratord-sx1302 backend.

 

1) consertratord.toml

consertratord.toml file found in the same folder where chirpstack-concentratord-sx1302 executable is. Following lines to be added into consertratord.toml configuration file for enabling Fine Timestamp functionality:

  • model_flags=["USB","GNSS"]
  • [gateway.fine_timestamp]
  • enable=true
  • mode="ALL_SF"

 

# LoRa gateway configuration.
[gateway]

  # Antenna gain (dB).
  antenna_gain=0

  # Public LoRaWAN network.
  lorawan_public=true

  # Gateway vendor / model.
  #
  # This configures various vendor and model specific settings like the min / max
  # frequency and TX gain table.
  #model="rak_2287_eu868"
  model="semtech_sx1302css868gw1_eu868"

  # Gateway vendor / model flags.
  #
  # Flag can be used to configure additional vendor / model features. The
  # following flags can be used:
  #
  #   Global flags:
  #     GNSS - Enable GNSS / GPS support
  #     USB  - Use USB for concentrator communication (default is SPI)
  model_flags=["USB","GNSS"]

  # Time fallback.
  #
  # In case the gateway does not have a GNSS module or is unable to aquire a
  # GNSS fix, use the system-time for setting the 'time' field on RX.
  time_fallback_enabled=true

  #Fine Timestamp
  #mode: HIGH_CAPACITY or ALL_SF
  [gateway.fine_timestamp]
    enable=true
    mode="ALL_SF"

 

2) chirpstack-concentratord-sx1302/src/handler/uplink.rs

Added frame.ftime and frame.ftime_received fields and needed formating to info!() macro.

                    info!(
                        "Frame received, uplink_id: {}, count_us: {}, freq: {}, bw: {}, mod: {:?}, dr: {:?} fts: {:0>9}, fts_recv: {} ",
                        rx_info.uplink_id,
                        frame.count_us,
                        frame.freq_hz,
                        frame.bandwidth,
                        frame.modulation,
                        frame.datarate,
                        frame.ftime,
                        frame.ftime_received
                    );

Now consertratord-sx1302 log shows Fine Timestamp information "...fts: 143869299, fts_recv: true". The Fts field is a nano secons since last trailing edge of the PPS signal of the GPS module. This nano second information is need for aproximation of the geolocation.

2023-06-11T19:13:54.123Z INFO  [libconcentratord::events] Publishing stats event, rx_received: 3, rx_received_ok: 1, tx_received: 0, tx_emitted: 0
2023-06-11T19:14:13.171Z INFO  [chirpstack_concentratord_sx1302::handler::uplink] Frame received, uplink_id: 1604220501, count_us: 3057298334, freq: 867300000, bw: 125000, mod: LoRa, dr: SF7 fts: 108051544, fts_recv: true
2023-06-11T19:14:24.124Z INFO  [libconcentratord::events] Publishing stats event, rx_received: 3, rx_received_ok: 1, tx_received: 0, tx_emitted: 0
2023-06-11T19:14:43.209Z INFO  [chirpstack_concentratord_sx1302::handler::uplink] Frame received, uplink_id: 2494718995, count_us: 3087334149, freq: 868100000, bw: 125000, mod: LoRa, dr: SF7 fts: 143869299, fts_recv: true
2023-06-11T19:14:54.130Z INFO  [libconcentratord::events] Publishing stats event, rx_received: 1, rx_received_ok: 1, tx_received: 0, tx_emitted: 0
2

 

3) chirpstack-concentratord-sx1302/src/wrapper/mod.rs

pub fn uplink_to_proto() returns Resultgw::UplinkFrame. fine_time_since_gps_epoch structe is added to gw::UplinkFrame. packet.ftime field holds precise receiving time information if Fine Timestamp property is enabled on consertratord-sx1302.

            fine_time_since_gps_epoch: match packet.ftime_received {
                true => Some(prost_types::Duration {
                            seconds: 0i64,
                            nanos: packet.ftime as i32
                        }),
                false => None
            },

And here is whole changed uplink_to_proto() function.


pub fn uplink_to_proto(
    gateway_id: &[u8],
    packet: &hal::RxPacket,
    time_fallback: bool,
) -> Result<gw::UplinkFrame> {
    let mut rng = rand::thread_rng();
    let uplink_id: u32 = rng.gen();

    Ok(gw::UplinkFrame {
        phy_payload: packet.payload[..packet.size as usize].to_vec(),
        tx_info: Some(gw::UplinkTxInfo {
            frequency: packet.freq_hz,
            modulation: Some(gw::Modulation {
                parameters: match packet.modulation {
                    hal::Modulation::LoRa => {
                        Some(gw::modulation::Parameters::Lora(gw::LoraModulationInfo {
                            bandwidth: packet.bandwidth,
                            spreading_factor: match packet.datarate {
                                hal::DataRate::SF5 => 5,
                                hal::DataRate::SF6 => 6,
                                hal::DataRate::SF7 => 7,
                                hal::DataRate::SF8 => 8,
                                hal::DataRate::SF9 => 9,
                                hal::DataRate::SF10 => 10,
                                hal::DataRate::SF11 => 11,
                                hal::DataRate::SF12 => 12,
                                _ => return Err(anyhow!("unexpected spreading-factor")),
                            },
                            code_rate: match packet.coderate {
                                hal::CodeRate::LoRa4_5 => gw::CodeRate::Cr45,
                                hal::CodeRate::LoRa4_6 => gw::CodeRate::Cr46,
                                hal::CodeRate::LoRa4_7 => gw::CodeRate::Cr47,
                                hal::CodeRate::LoRa4_8 => gw::CodeRate::Cr48,
                                hal::CodeRate::Undefined => gw::CodeRate::CrUndefined,
                            }
                            .into(),
                            ..Default::default()
                        }))
                    }
                    hal::Modulation::FSK => {
                        Some(gw::modulation::Parameters::Fsk(gw::FskModulationInfo {
                            datarate: match packet.datarate {
                                hal::DataRate::FSK(v) => v * 1000,
                                _ => return Err(anyhow!("unexpected datarate")),
                            },
                            ..Default::default()
                        }))
                    }
                    hal::Modulation::Undefined => None,
                },
            }),
        }),
        rx_info: Some(gw::UplinkRxInfo {
            uplink_id,
            context: packet.count_us.to_be_bytes().to_vec(),
            gateway_id: hex::encode(gateway_id),
            rssi: packet.rssis as i32,
            snr: packet.snr,
            channel: packet.if_chain as u32,
            rf_chain: packet.rf_chain as u32,
            time: match gps::cnt2time(packet.count_us) {
                Ok(v) => {
                    let v = v.duration_since(UNIX_EPOCH).unwrap();
                    Some(prost_types::Timestamp {
                        seconds: v.as_secs() as i64,
                        nanos: v.subsec_nanos() as i32,
                    })
                }
                Err(err) => {
                    debug!(
                        "Could not get GPS time, uplink_id: {}, error: {}",
                        uplink_id, err
                    );

                    if time_fallback {
                        Some(prost_types::Timestamp::from(SystemTime::now()))
                    } else {
                        None
                    }
                }
            },
            time_since_gps_epoch: match gps::cnt2epoch(packet.count_us) {
                Ok(v) => Some(prost_types::Duration {
                    seconds: v.as_secs() as i64,
                    nanos: v.subsec_nanos() as i32,
                }),
                Err(err) => {
                    debug!(
                        "Could not get GPS epoch, uplink_id: {}, error: {}",
                        uplink_id, err
                    );
                    None
                }
            },           
            fine_time_since_gps_epoch: match packet.ftime_received {
                true => Some(prost_types::Duration {
                            seconds: 0i64,
                            nanos: packet.ftime as i32
                        }),
                false => None
            },
            crc_status: match packet.status {
                hal::CRC::CRCOk => gw::CrcStatus::CrcOk,
                hal::CRC::BadCRC => gw::CrcStatus::BadCrc,
                hal::CRC::NoCRC | hal::CRC::Undefined => gw::CrcStatus::NoCrc,
            }
            .into(),
            ..Default::default()
        }),
        ..Default::default()
    })
}

 

I wrote a simple Rust zeromq client program for printing up-events of the consertratord-sx1302 backend. Now Fine Timestamp information found in fine_time_since_gps_epoch: Some(Duration { seconds: 0, nanos: 48290698 }) Structure as follows. In this example second part is allway zere. Only nano second part matters for the geolocation calculations.


Topic: up
phy_payload: [64, 97, 158, 199, 1, 128, 245, 148, 3, 132, 29, 75, 233, 12, 129, 60, 199, 85, 34, 198, 216, 151, 189]
phy_payload: UplinkRxInfo { gateway_id: "0016c001ff1f11ddd", uplink_id: 1836980030, time: Some(Timestamp { seconds: 1686508758, nanos: 116930490 }), time_since_gps_epoch: None, fine_time_since_gps_epoch: Some(Duration { seconds: 0, nanos: 48290698 }), rssi: -99, snr: 12.25, channel: 3, rf_chain: 0, board: 0, antenna: 0, location: None, context: [57, 90, 153, 82], metadata: {}, crc_status: CrcOk }
Topic: up
phy_payload: [64, 97, 158, 199, 1, 128, 246, 148, 3, 86, 239, 135, 219, 156, 240, 225, 92, 184, 205, 19, 254, 61, 94]
phy_payload: UplinkRxInfo { gateway_id: "0016c001ff1f1ddd", uplink_id: 2518488021, time: Some(Timestamp { seconds: 1686508788, nanos: 161273198 }), time_since_gps_epoch: None, fine_time_since_gps_epoch: Some(Duration { seconds: 0, nanos: 91829739 }), rssi: -42, snr: 11.25, channel: 1, rf_chain: 1, board: 0, antenna: 0, location: None, context: [59, 37, 6, 226], metadata: {}, crc_status: CrcOk }
Topic: up
phy_payload: [64, 97, 158, 199, 1, 128, 247, 148, 3, 167, 7, 251, 70, 240, 160, 220, 53, 167, 110, 184, 203, 240, 19]
phy_payload: UplinkRxInfo { gateway_id: "0016c001ff1f1ddd", uplink_id: 1110056337, time: Some(Timestamp { seconds: 1686508818, nanos: 194757382 }), time_since_gps_epoch: None, fine_time_since_gps_epoch: Some(Duration { seconds: 0, nanos: 134425134 }), rssi: -42, snr: 9.5, channel: 2, rf_chain: 1, board: 0, antenna: 0, location: None, context: [60, 239, 112, 194], metadata: {}, crc_status: CrcOk }

Can you implement this by yourself and make a pull request?

Yes ! can. I have a smoke tested this solution proposal and it seems to work . But first let's wait for the review and comments of the idea....

For SPI's dev device address and resetting GPIO errors

Dear author, hello.
I am using Raspberry Pi 4 product. I want to implement the lorawan function.
Currently, it is running using lora_pkt_fwd
I have noticed your subroutine, but I have identified a small issue
It defaults to using the spi dev address of/dev/spidev0.0, and the reset address is 7
But my/dev/spidev0.0 and gpio 7 have already been occupied.
How can it be customized and changed in the toml configuration file?

error log info


./chirpstack-concentratord-sx1302 -c chirpstack-concentratord-sx1302.toml 
2024-04-24T17:09:28.682Z INFO  [libconcentratord::reset] Configuring reset pin, dev: /dev/gpiochip0, pin: 17
2024-04-24T17:09:28.682Z INFO  [chirpstack_concentratord_sx1302::cmd::root] Starting Concentratord SX1302 (version: 4.3.5, docs: https://www.chirpstack.io/docs/chirpstack-concentratord/)
2024-04-24T17:09:28.683Z INFO  [libconcentratord::reset] Triggering sx1302 reset
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting i2c device path, path: /dev/i2c-1
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting board configuration, lorawan_public: true, clock_source: 0, com_type: Spi, com_path: /dev/spidev0.0
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up fine timestamp, enable: false
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up concentrator channels
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring radio, radio: 0, enabled: true, center_freq: 867500000, type: SX1250
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring radio, radio: 1, enabled: true, center_freq: 868500000, type: SX1250
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up concentrator channels
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 0, enabled: true, freq: 868100000, rf_chain: 1, if_freq: -400000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 1, enabled: true, freq: 868300000, rf_chain: 1, if_freq: -200000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 2, enabled: true, freq: 868500000, rf_chain: 1, if_freq: 0
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 3, enabled: true, freq: 867100000, rf_chain: 0, if_freq: -400000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 4, enabled: true, freq: 867300000, rf_chain: 0, if_freq: -200000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 5, enabled: true, freq: 867500000, rf_chain: 0, if_freq: 0
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 6, enabled: true, freq: 867700000, rf_chain: 0, if_freq: 200000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 7, enabled: true, freq: 867900000, rf_chain: 0, if_freq: 400000
2024-04-24T17:09:28.883Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring Std LoRa channel, enabled: true, freq: 868300000, rf_chain: 1, if_freq: -200000
2024-04-24T17:09:28.884Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring FSK channel, enabled: true, freq: 868800000, rf_chain: 1, if_freq: 300000
2024-04-24T17:09:28.884Z INFO  [chirpstack_concentratord_sx1302::concentrator] Starting the concentrator
Opening SPI communication interface
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
thread 'main' panicked at chirpstack-concentratord-sx1302/src/main.rs:117:80:
called `Result::unwrap()` on an `Err` value: lgw_start failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Perhaps there may be configuration fields present

model_flags=[SPI]
spidev_path="/dev/spidev1.0"
RESET_PIN=22

Add SX1302 LoraWAN Gateway HAT for ChirpStack OS Gateway and Raspberry PI 4B

I have a project to manage water metering sensors based on LoraWAN technology for my residence in France.
I would like to create a LoraWAN Gateway 868 MHz based on ChirpStack OS Gateway, Raspberry PI 4B board and SX1302 LoRaWAN Gateway hat (www.waveshare.com).
I have searched the issues of this repository and believe that this is not a duplicate.
It could be a new hardware managed by the ChirpStack OS Gateway and easily integrated in the software
https://www.waveshare.com/wiki/SX1302_LoRaWAN_Gateway_HAT

I don't know how to implement and introduce the new board by myself. I need help.

Add option to allow reset pin numbers on different chip sets

Summary

Request to add a configuration option to allow reset pin numbers outside gpio chipset 0 ("/dev/gpiochip0")

What is the use-case?

Some custom boards have set the LoRa reset pin to different chipset, a current example is the SeeedStudio LoRaWAN Gateway this has the reset pin set to gpiochip1 pin 17 (pin 49)

Implementation description

add a optional parameter to the setup_pins function in rest.rs and default it to 0

Can you implement this by yourself and make a pull request?

I'm not a rust programmer but I can google just as well as the next programmer, maybe a option would be to check for the existence of chipset_number in the configuration file and set to that value else set to None.

i.e. in main change

// configure concentrator reset pin
if config.gateway.model_config.reset_pin.is_some() {
    reset::setup_pins(config.gateway.model_config.reset_pin.unwrap(), None)
        .expect("setup reset pin error");
}

to some thing like

// configure concentrator pins
let reset_pin = if config.gateway.model_config.reset_pin.is_some() {config.gateway.model_config.reset_pin.unwrap()} else {None};
let chipset_number = if config.gateway.model_config.chipset_number.is_some() {config.gateway.model_config.chipset_number.unwrap()} else {0};
let power_pin = if config.gateway.model_config.power_pin.is_some() {config.gateway.model_config.power_pin.unwrap()} else {None};

reset::setup_pins(reset_pin, chipset_number, power_pin)
    .expect("setup reset pin error");

Add fake RX time option

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Add an option to set the RX time to the system time if there is no time set from the GPS.

What is the use-case?

This option exists in the Gateway Bridge's Semtech UDP backend. Adding this feature to the concentratord would make the Concentratord + CSGB a replacement for Semtech UDP Packet Forwarder + CSGB when this feature is needed.

Implementation description

Technically speaking it could be implemented in the CSGB instead, but I think this is more hardware related and therefore belong to the concentratord.

Can you implement this by yourself and make a pull request?

I don't know where it belongs and the implication of the implementation of this for the different HAL implementations.

Seeed WM1302 downlink message issue

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

When GPS is in use and after 1-2 hours, the devices stop getting ACKs from the gateway and they start sending Join messages. However, they cannot Join after that. According to the Chirpstack UI, ACKs and Join Accepts are sent but the devices are not satisfied.

What did you expect?

With GPS in use, the devices continue sending messages and receive ACKs from the gateway.

Steps to reproduce this issue

Steps:

  1. Use Seeed WM1302 card on Pi Hat with Raspberry PI and install the latest Chirpstack OS on it.
  2. Connect LoRaWAN antenna on WM1302 card AND GPS module/antenna on the Pi Hat.
  3. Configure WM1302 card in use with gateway-config via LoRa concentrator shield.
  4. Have LoRaWAN devices in your network with uplink acknowledge policy set on.
  5. Wait ~2 hours with 3 minutes message interval on the LoRaWAN devices.

On the other hand, if I remove the GPS antenna from Pi Hat connector and go through the previously mentioned steps, I don't see this issue. Instead I get the following warning every second (example):

Aug 04 09:27:43 raspberrypi4 user.warn chirpstack-concentratord-sx1302[538]: GPS time reference is not valid, age: 1691141263.592160279s

Could you share your log output?

I don't see any change in the log messages between working and non-working (ACKs not received) state. When GPS is connected, I do see this message every two minutes:

Aug 03 21:02:34 raspberrypi4 user.warn chirpstack-concentratord-sx1302[537]: Enqueue beacon failed, error: TooEarly

Let me know if other logs are required.

Your Environment

Component Version
Chirpstack OS v4.3.0
Concentratord v4.1.1 and v4.2.0

Default metadata configurability

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Concentratord does add metadata to the stats report. The concentratord should provide a mecanism to disable those metadata.

What is the use-case?

These metadata may not be needed and users may want to remove them to save bandwidth (e.g. mobile data plan).

Implementation description

I suggest adding a [metadata] section to the configuration file with a concentratord property that would default to concentrator_temp,concentratord_version,config_version,hal_version,model (array of string of enabled metadata).

[metadata]

concentratord="concentrator_temp,concentratord_version,config_version,hal_version,model"

Redefining this property to empty would allow the user to remove those metadata. The default behavior is retro-compatible.

Can you implement this by yourself and make a pull request?

Possibly.

Workaround

I could not find a workaround to remove the metadata. Any idea is welcome.

Chripstack-concentratord-sx1302 v4.3.0 crashed with Segmentation fault

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

Chripstack-concentratord-sx1302 v4.3.0 crashed with segmentation fault when using fine timestamping.

Test environment

  • Test environment: Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-79-generic x86_64)
  • Dev environment and code build as described on this repository.
  • Cross build target: x86_64-unknown-linux-musl
  • Module: Chirpstack-consertratord-sx1302
  • Lora HW: Semtech sx1303css868gw with a PPS signal

The Chripstack-concentratord-sx1302 module is compiled according to the instructions in this repository.

Concentratord crashed randomly ...

Consentratord crashed randomly with SIGSEGV signal Segmentation fault. It seems that segmentation fault occurs (only?) if the Fine Stamping is enabled.

Fine timestamping is enabled in a concentratord configuration file as follows In the test case:

sx1303.toml
...

  # Fine_timestamp
  # enable
  #   true
  #   false
  # mode
  #   "ALL_SF"
  #   "HIGH_CAPACITY"
[gateway.fine_timestamp]
  enable=true
  mode="ALL_SF"
...

Concentratord start command: ./chirpstack-concentratord-sx1302 -c sx1303.toml

Concentratord runs for a random amount of the time and crashes with a segmentation fault error. The log does not show the reason or any information about the crash. Only hint is that segmentation fault has been raised. Not good.

I've investigated and debugged chirpstack-consentratord-sx1302 code and found that the problem lies behind the Rust FFI in the customized c code of sx1302_hal layer.

After a long run I got a full back trace log with the gdb debugger.

#0  0x00007ffff772224a in compare_pkt_tmst ()
No symbol table info available.
#1  0x00007ffff7c01d0f in sift () at ../src_musl/src/stdlib/qsort.c:103
No locals.
#2  0x00007ffff7c01eb1 in trinkle () at ../src_musl/src/stdlib/qsort.c:154
No locals.
#3  0x00007ffff7c02082 in __qsort_r () at ../src_musl/src/stdlib/qsort.c:200
No locals.
#4  0x00007ffff7723d2a in lgw_receive ()
No symbol table info available.
#5  0x00007ffff771c5e7 in libloragw_sx1302::hal::receive () at libloragw-sx1302/src/hal.rs:932
        _guard = std::sync::mutex::MutexGuard<()> {lock: 0x7ffff7ff8c88 <<libloragw_sx1302::mutex::CONCENTATOR as core::ops::deref::Deref>::deref::__stability::LAZY+4>, poison: std::sync::poison::Guard {panicking: false}}
        packets = [
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 868500000, freq_offset: 854, if_chain: 2, status: 16, count_us: 254499580, rf_chain: 1, modem_id: 9, modulation: 16, bandwidth: 4, datarate: 7, coderate: 1, rssic: -40.3999939, rssis: -41.3999939, snr: 9.5, snr_min: 0, snr_max: 0, crc: 57943, size: 23, payload: [64, 38, 51, 248, 0, 128, 148, 143, 3, 200, 183, 189, 141, 158, 16, 176, 97, 176, 164, 99, 92, 183, 23, 0 <repeats 233 times>], ftime_received: true, ftime: 877986163},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 868100000, freq_offset: -24138, if_chain: 0, status: 17, count_us: 254499587, rf_chain: 1, modem_id: 11, modulation: 16, bandwidth: 4, datarate: 7, coderate: 1, rssic: -96.3999939, rssis: -100.399994, snr: -7.25, snr_min: 0, snr_max: 0, crc: 57951, size: 23, payload: [112, 38, 55, 232, 2, 12, 148, 143, 195, 240, 183, 190, 193, 158, 17, 118, 97, 128, 164, 163, 124, 183, 177, 0 <repeats 233 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 868100000, freq_offset: -24138, if_chain: 0, status: 17, count_us: 254499588, rf_chain: 1, modem_id: 10, modulation: 16, bandwidth: 4, datarate: 7, coderate: 1, rssic: -96.3999939, rssis: -100.399994, snr: -7.5, snr_min: 0, snr_max: 0, crc: 57942, size: 23, payload: [112, 68, 183, 248, 3, 8, 144, 143, 195, 112, 183, 238, 4, 158, 19, 118, 97, 128, 164, 163, 92, 183, 129, 0 <repeats 233 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 868500000, freq_offset: 854, if_chain: 2, status: 16, count_us: 254499580, rf_chain: 1, modem_id: 8, modulation: 16, bandwidth: 4, datarate: 7, coderate: 1, rssic: -40.3999939, rssis: -41.3999939, snr: 11.5, snr_min: 0, snr_max: 0, crc: 57943, size: 23, payload: [64, 38, 51, 248, 0, 128, 148, 143, 3, 200, 183, 189, 141, 158, 16, 176, 97, 176, 164, 99, 92, 183, 23, 0 <repeats 233 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 0, freq_offset: 0, if_chain: 0, status: 0, count_us: 0, rf_chain: 0, modem_id: 0, modulation: 0, bandwidth: 0, datarate: 0, coderate: 0, rssic: 0, rssis: 0, snr: 0, snr_min: 0, snr_max: 0, crc: 0, size: 0, payload: [
              0 <repeats 256 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 0, freq_offset: 0, if_chain: 0, status: 0, count_us: 0, rf_chain: 0, modem_id: 0, modulation: 0, bandwidth: 0, datarate: 0, coderate: 0, rssic: 0, rssis: 0, snr: 0, snr_min: 0, snr_max: 0, crc: 0, size: 0, payload: [
              0 <repeats 256 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 0, freq_offset: 0, if_chain: 0, status: 0, count_us: 0, rf_chain: 0, modem_id: 0, modulation: 0, bandwidth: 0, datarate: 0, coderate: 0, rssic: 0, rssis: 0, snr: 0, snr_min: 0, snr_max: 0, crc: 0, size: 0, payload: [
              0 <repeats 256 times>], ftime_received: false, ftime: 0},
          libloragw_sx1302::wrapper::lgw_pkt_rx_s {freq_hz: 0, freq_offset: 0, if_chain: 0, status: 0, count_us: 0, rf_chain: 0, modem_id: 0, modulation: 0, bandwidth: 0, datarate: 0, coderate: 0, rssic: 0, rssis: 0, snr: 0, snr_min: 0, snr_max: 0, crc: 0, size: 0, payload: [
              0 <repeats 256 times>], ftime_received: false, ftime: 0}]
#6  0x00007ffff75c3e45 in chirpstack_concentratord_sx1302::handler::uplink::handle_loop (gateway_id=..., stop_receive=..., disable_crc_filter=false, time_fallback=false) at chirpstack-concentratord-sx1302/src/handler/uplink.rs:25
No locals.
#7  0x00007ffff760e091 in chirpstack_concentratord_sx1302::cmd::root::run::{closure#0} () at chirpstack-concentratord-sx1302/src/cmd/root.rs:76
        gateway_id = <optimized out>
        stop_receive = <optimized out>
        disable_crc_filter = <optimized out>
        time_fallback = <optimized out>
#8  0x00007ffff75bb6c9 in std::sys_common::backtrace::__rust_begin_short_backtrace<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()> (f=...) at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:135
No locals.
#9  0x00007ffff75ac151 in std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()> () at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/mod.rs:529
        f = <optimized out>
#10 0x00007ffff75a3251 in core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>> (self=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/panic/unwind_safe.rs:271
        _args = ()
#11 0x00007ffff760bdfa in std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>>, ()> (data=0x7ffff72a17c0)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500
        f = core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>> (std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()> {f: chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0} {gateway_id: [0, 22, 192, 1, 255, 31, 15,
                27], stop_receive: std::sync::mpsc::Receiver<libconcentratord::signals::Signal> {inner: std::sync::mpmc::Receiver<libconcentratord::signals::Signal> {flavor: std::sync::mpmc::ReceiverFlavor<libconcentratord::signals::Signal>::List(std::sync::mpmc::counter::Receiver<std::sync::mpmc::list::Channel<libconcentratord::signals::Signal>> {counter: 0x7ffff7e61080})}}, disable_crc_filter: false, time_fallback: false}})
        data = 0x7ffff72a17c0
        data = 0x7ffff72a17c0
#12 0x00007ffff760c43b in __rust_try ()
No symbol table info available.
#13 0x00007ffff760bc41 in std::panicking::try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>>> (f=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464
        data_ptr = 0x7ffff72a17c0
        data = std::panicking::try::Data<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>>, ()> {f: core::mem::manually_drop::ManuallyDrop<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>>> {value: core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>> (std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()> {f: chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0} {gateway_id: [0, 22, 192, 1, 255, 31, 15,
                    27], stop_receive: std::sync::mpsc::Receiver<libconcentratord::signals::Signal> {inner: std::sync::mpmc::Receiver<libconcentratord::signals::Signal> {flavor: std::sync::mpmc::ReceiverFlavor<libconcentratord::signals::Signal>::List(std::sync::mpmc::counter::Receiver<std::sync::mpmc::list::Channel<libconcentratord::signals::Signal>> {counter: 0x7ffff7e61080})}}, disable_crc_filter: false, time_fallback: false}})}, r: core::mem::manually_drop::ManuallyDrop<()> {value: ()}, p: core::mem::manually_drop::ManuallyDrop<alloc::boxed::Box<(dyn core::any::Any + core::marker::Send), alloc::alloc::Global>> {value: alloc::boxed::Box<(dyn core::any::Any + core::marker::Send), alloc::alloc::Global> {pointer: 0x1, vtable: 0x7ffff7e61080}}}
#14 0x00007ffff75aa78a in std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>>, ()> (f=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142
No locals.
--Type <RET> for more, q to quit, c to continue without paging--
#15 std::thread::{impl#0}::spawn_unchecked_::{closure#1}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()> () at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/mod.rs:528
        f = chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0} {gateway_id: [0, 22, 192, 1, 255, 31, 15,
            27], stop_receive: std::sync::mpsc::Receiver<libconcentratord::signals::Signal> {inner: std::sync::mpmc::Receiver<libconcentratord::signals::Signal> {flavor: std::sync::mpmc::ReceiverFlavor<libconcentratord::signals::Signal>::List(std::sync::mpmc::counter::Receiver<std::sync::mpmc::list::Channel<libconcentratord::signals::Signal>> {counter: 0x7ffff7e61080})}}, disable_crc_filter: false, time_fallback: false}
        their_packet = alloc::sync::Arc<std::thread::Packet<()>> {ptr: core::ptr::non_null::NonNull<alloc::sync::ArcInner<std::thread::Packet<()>>> {pointer: 0x7ffff7e62a20}, phantom: core::marker::PhantomData<alloc::sync::ArcInner<std::thread::Packet<()>>>}
        f = std::thread::{impl#0}::spawn_unchecked_::MaybeDangling<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}> (core::mem::maybe_uninit::MaybeUninit<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}> {uninit: (), value: core::mem::manually_drop::ManuallyDrop<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}> {value: chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0} {gateway_id: [0, 22, 192, 1, 255, 31, 15,
                  27], stop_receive: std::sync::mpsc::Receiver<libconcentratord::signals::Signal> {inner: std::sync::mpmc::Receiver<libconcentratord::signals::Signal> {flavor: std::sync::mpmc::ReceiverFlavor<libconcentratord::signals::Signal>::List(std::sync::mpmc::counter::Receiver<std::sync::mpmc::list::Channel<libconcentratord::signals::Signal>> {counter: 0x7ffff7e61080})}}, disable_crc_filter: false, time_fallback: false}}})
        output_capture = core::option::Option<alloc::sync::Arc<std::sync::mutex::Mutex<alloc::vec::Vec<u8, alloc::alloc::Global>>>>::None
        their_thread = std::thread::Thread {inner: core::pin::Pin<alloc::sync::Arc<std::thread::Inner>> {pointer: alloc::sync::Arc<std::thread::Inner> {ptr: core::ptr::non_null::NonNull<alloc::sync::ArcInner<std::thread::Inner>> {pointer: 0x7ffff7ec13b0}, phantom: core::marker::PhantomData<alloc::sync::ArcInner<std::thread::Inner>>}}}
#16 0x00007ffff75bd54e in core::ops::function::FnOnce::call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<chirpstack_concentratord_sx1302::cmd::root::run::{closure_env#0}, ()>, ()> ()
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250
No locals.
#17 0x00007ffff7bc3bb5 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1993
No locals.
#18 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1993
No locals.
#19 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
No locals.
#20 0x00007ffff7bf99bd in start () at ../src_musl/src/thread/pthread_create.c:203
No locals.
#21 0x00007ffff7bfb127 in __clone () at ../src_musl/src/thread/x86_64/clone.s:22
No locals.
Backtrace stopped: frame did not save the PC

Here is a simplified call stack and now we can see where the problem lies.

libloragw-sx1302/src/hal.rs:932
  -> libloragw/src/loragw_hal.c lgw_receive()      
    -> libloragw/src/loragw_hal.c merge_packets()
      -> libloragw/src/loragw_hal.c qsort()
        -> libloragw/src/loragw_hal.c compare_pkt_tmst() -> Thread 9 "chirpstack-conc" received signal SIGSEGV, Segmentation fault.

Concentratord Segmentation fault caused by compare_pkt_tmst() c code function in customized sx1302_hal module. This module was changed last in 9aef4ac commit which updates qsort() functionality in merge_packets() function (libloragw/src/loragw_hal.c).

I think that after 9aef4ac commit the comparator function compare_pkt_tmst() of qsort not work as it should be and cause the segmentation fault (at least in this case). Error can due to wrong argument list in comparator function compare_pkt_tmst().

Segmentation fault happens when LoRa radio receives many packets in a same time. In code, the information of received packets are sorted and duplicate packets are removed.

Issue can be fixed changing code of loragw_hal.c:

Before fix:


int compare_pkt_tmst(const void *a, const void *b, void *arg)
{
    struct lgw_pkt_rx_s *p = (struct lgw_pkt_rx_s *)a;
    struct lgw_pkt_rx_s *q = (struct lgw_pkt_rx_s *)b;
    int *counter = (int *)arg;
    int p_count, q_count;

    p_count = p->count_us;
    q_count = q->count_us;

    if (p_count > q_count) {
        *counter = *counter + 1;
    }

    return (p_count - q_count);
}

/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */

After fix:

/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */

int compare_pkt_tmst(const void *a, const void *b)
{
    int p_count, q_count;

    p_count = ((struct lgw_pkt_rx_s *)a)->count_us;
    q_count = ((struct lgw_pkt_rx_s *)b)->count_us;

    return (p_count - q_count);
}

/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */


 
 
 

Let's do IoT better

Set reset pin for concentratord : IMST ic880A

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Allow “generic” configuration for IMST ic880A for setting the reset pin:
chirpstack-concentratord/chirpstack-concentratord-sx1301/src/config/vendor/imst/ic880a_eu868.rs

Currently the reset pin is fixed to pin 5 and this does not work as I need to set it to GPIO 25.

What is the use-case?

To reset the pin on the concentrator board on a raspberry pi powered gateway

Implementation description

Maybe change :
reset_pin: Some(5) -> reset_pin: Some(conf.gateway.reset_pin)

Can you implement this by yourself and make a pull request?

No

Model seeed_wm1302 doesn't work

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

I used UDP packet forwarder to communicate with lora gateway model seeed_wm1302 and it works fine. I used this fork: https://github.com/peterpanstechland/sx1302_hal.git

Now I'm trying to use Chirpstack concentratord and it failed to start, this is the log:

2024-07-24T08:33:45.439Z INFO  [libconcentratord::reset] Configuring sx1302 power enable pin, dev: /dev/gpiochip0, pin: 18
2024-07-24T08:33:45.439Z INFO  [libconcentratord::reset] Configuring sx1261 reset pin, dev: /dev/gpiochip0, pin: 5
2024-07-24T08:33:45.440Z INFO  [chirpstack_concentratord_sx1302::cmd::root] Starting Concentratord SX1302 (version: 4.4.1, docs: https://www.chirpstack.io/docs/chirpstack-concentratord/)
2024-07-24T08:33:45.440Z INFO  [libconcentratord::reset] Enabling concentrator power
2024-07-24T08:33:45.540Z INFO  [libconcentratord::reset] Triggering sx130x reset
2024-07-24T08:33:45.740Z INFO  [libconcentratord::reset] Triggering sx1261 reset
2024-07-24T08:33:45.941Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting i2c device path, path: /dev/i2c-1
2024-07-24T08:33:45.941Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting i2c temperature sensor address, address: 57
2024-07-24T08:33:45.941Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting board configuration, lorawan_public: true, clock_source: 0, com_type: Spi, com_path: /dev/spidev0.0
2024-07-24T08:33:45.942Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up fine timestamp, enable: false
2024-07-24T08:33:45.942Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 12, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 15
2024-07-24T08:33:45.942Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 13, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 16
2024-07-24T08:33:45.942Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 14, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 17
2024-07-24T08:33:45.943Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 15, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 19
2024-07-24T08:33:45.943Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 16, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 20
2024-07-24T08:33:45.943Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 17, dig_gain: 0, pa_gain: 0, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 22
2024-07-24T08:33:45.944Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 18, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 1
2024-07-24T08:33:45.944Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 19, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 2
2024-07-24T08:33:45.944Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 20, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 3
2024-07-24T08:33:45.944Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 21, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 4
2024-07-24T08:33:45.945Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 22, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 5
2024-07-24T08:33:45.945Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 23, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 6
2024-07-24T08:33:45.945Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 24, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 7
2024-07-24T08:33:45.946Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 25, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 9
2024-07-24T08:33:45.946Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 26, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 11
2024-07-24T08:33:45.946Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Configuration TX gain for radio, radio: 0, rf_power: 27, dig_gain: 0, pa_gain: 1, dac_gain: 0, mix_gain: 5, offset_i: 0, offset_q: 0, pwr_idx: 14
2024-07-24T08:33:45.947Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up concentrator channels
2024-07-24T08:33:45.947Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring radio, radio: 0, enabled: true, center_freq: 867500000, type: SX1250
2024-07-24T08:33:45.947Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring radio, radio: 1, enabled: true, center_freq: 868500000, type: SX1250
2024-07-24T08:33:45.947Z INFO  [chirpstack_concentratord_sx1302::concentrator] Setting up concentrator channels
2024-07-24T08:33:45.947Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 0, enabled: true, freq: 868100000, rf_chain: 1, if_freq: -400000
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 1, enabled: true, freq: 868300000, rf_chain: 1, if_freq: -200000
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 2, enabled: true, freq: 868500000, rf_chain: 1, if_freq: 0
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 3, enabled: true, freq: 867100000, rf_chain: 0, if_freq: -400000
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 4, enabled: true, freq: 867300000, rf_chain: 0, if_freq: -200000
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 5, enabled: true, freq: 867500000, rf_chain: 0, if_freq: 0
2024-07-24T08:33:45.948Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 6, enabled: true, freq: 867700000, rf_chain: 0, if_freq: 200000
2024-07-24T08:33:45.949Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring multi-SF LoRa channel, channel: 7, enabled: true, freq: 867900000, rf_chain: 0, if_freq: 400000
2024-07-24T08:33:45.949Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring Std LoRa channel, enabled: true, freq: 868300000, rf_chain: 1, if_freq: -200000
2024-07-24T08:33:45.949Z INFO  [chirpstack_concentratord_sx1302::concentrator] Configuring FSK channel, enabled: true, freq: 868800000, rf_chain: 1, if_freq: 300000
2024-07-24T08:33:45.949Z INFO  [chirpstack_concentratord_sx1302::concentrator] Starting the concentrator
Opening SPI communication interface
thread 'main' panicked at chirpstack-concentratord-sx1302/src/main.rs:117:80:
called `Result::unwrap()` on an `Err` value: lgw_start failed

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
stack backtrace:
   0:           0x65e958 - <unknown>
   1:           0x6a56b4 - <unknown>
   2:           0x65b924 - <unknown>
   3:           0x65e764 - <unknown>
   4:           0x65fe34 - <unknown>
   5:           0x65fad4 - <unknown>
   6:           0x660350 - <unknown>
   7:           0x6600f0 - <unknown>
   8:           0x65ee1c - <unknown>
   9:           0x65fe88 - <unknown>
  10:           0x40d1ac - <unknown>
  11:           0x40d4ec - <unknown>
  12:           0x45f6a8 - <unknown>
  13:           0x46edfc - <unknown>
  14:           0x459af0 - <unknown>
  15:           0x65573c - <unknown>
  16:           0x460524 - <unknown>
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0

What did you expect?

I expect that concentratord starts and read messages received on lora gateway.

Steps to reproduce this issue

Steps:

  1. Download last chirpstack concentratord from github
  2. decompress package
  3. create concentratord.toml config file:
[concentratord]
  # Log level.
  #
  # Valid options are:
  #   * TRACE
  #   * DEBUG
  #   * INFO
  #   * WARN
  #   * ERROR
  #   * OFF
  #log_level="INFO"
  log_level="TRACE"

  # 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"

  # Disable CRC status filter.
  #
  # By default, the Concentratord will ignore received frames which do not have
  # a valid CRC. This option makes it possible to disable this filter such that
  # received frames without (valid) CRC can be analyzed.
  disable_crc_filter=false

  # 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

  # Region.
  #
  # The region of the gateway. Options:
  #  EU868, US915, CN779, EU433, AU915, CN470, AS923, AS923_2, AS923_3, AS923_4,
  #  KR923, IN865, RU864
  #
  # Not not all the gateway models implement all regions.
  region="EU868"

  # Gateway vendor / model.
  #
  # This configures various vendor and model specific settings.
  model="seeed_wm1302"

  # Gateway vendor / model flags.
  #
  # Flag can be used to configure additional vendor / model features. The
  # following flags can be used:
  #
  #   Global flags:
  #     GNSS - Enable GNSS / GPS support
  #     USB  - Use USB for concentrator communication (default is SPI)
  model_flags=[]

  # Time fallback.
  #
  # In case the gateway does not have a GNSS module or is unable to aquire a
  # GNSS fix, use the system-time for setting the 'time' field on RX.
  time_fallback_enabled=true


  # 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


  # Static gateway location.
  [gateway.location]

    # When set to non-zero values, the static gateway location will be reported
    # when the gateway does not have a GNSS module or when no GNSS location fix
    # is available.
    latitude=0.0
    longitude=0.0
    altitude=0
  1. start concentratord via cli:
    RUST_BACKTRACE=full ./chirpstack-concentratord-sx1302 -c concentratord.toml

Could you share your log output?

already shared

Your Environment

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

lora gateway: WM1302
region: EU868

I attach UDP packet forwarder sx1302_hal working config files (udp_packet_forwarder_configs.zip)
udp_packet_forwarder_configs.zip

Request AS923 channel-plan region for Shield Model Seeed WM1302 / Seeed WM1303

We already installed v4.2.0-test.1 ChirpStack Gateway OS image on Raspberry Pi 4 with Seeed WM1303 LoRaWAN,
but it seems AS923-2 channel plan region still not implemented by Concentratord for this shield.
It will be helpful if this channel plan region can be implemented, since our country, Indonesia use this
channel plan.

ChirpStack channel region

Set reset pin for concentratord : IMST ic880A

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Allow “generic” configuration for IMST ic880A for setting the reset pin:
chirpstack-concentratord/chirpstack-concentratord-sx1301/src/config/vendor/imst/ic880a_eu868.rs

Currently the reset pin is fixed to pin 5 and this does not work as I need to set it to GPIO 25.

Maybe change :
reset_pin: Some(5) -> reset_pin: Some(conf.gateway.reset_pin)

Poly packet forward feature

  • [X ] I have searched the issues of this repository and believe that this is not a duplicate.

Summary

A new feature should be the poly packet forward in order to forward node messages to/from different network servers (chirpstack network server , TTN network server, etc...).

What is the use-case?

This feature will enable TTN nodes and ChirpStack nodes to use the same gateway.

Implementation description

I think the chirpstack-packet-multiplexer could be a guide for this or The Things Network Multi Protocol Packet Forwarder (https://github.com/kersing/packet_forwarder). This last one provides TTN packet forwarder and semtech packet forward (UDP). So, it can be used to provide packet forward to TTN and ChirpStack (semtech packet forward) at the same time. It will forward the messages to both network servers, but each one will process only messages from its node messages from its nodes, ignoring the other messages.

Can you implement this by yourself and make a pull request?

Unfortunatly no...

chirpstack-concentratord-sx1302 fails to start with RAK2287 USB GPS EU868

I am unable to start concentratord for RAK2287 USB GPS EU868 on RPi armv7hf

sudo ./chirpstack-concentratord-sx1302 -c concentratord.toml
...
WARNING: MCU version mismatch (expected:01.00.00, got:V00.02.06)
INFO: Concentrator MCU version is V00.02.06
INFO: MCU status: sys_time:40524090 temperature:-0.0oC
ERROR: received wrong ACK type (0xFF)
ERROR: failed to read REQ_MULTIPLE_SPI ack
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "lgw_start failed"', chirpstack-concentratord-sx1302/src/main.rs:111:15

Configuration used from https://www.chirpstack.io/concentratord/install/config/ for sx1302 with those modifications:

[gateway]
  antenna_gain=0
  lorawan_public=false
  model="rak_2287_eu868"
  model_flags=["GNSS","USB"]
  gateway_id="fc7c47f60740c21f"

sudo ./chirpstack-concentratord-sx1302 --version
chirpstack-concentratord-sx1302 3.2.0

Sources from release tag v3.3.0 (Latest)

Process panicks upon start (Multitech Conduit, mPower 6.3.0)

  • The issue is present in the latest release.
  • I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

Attempted to start chirpstack-concentratord 4.4.1 on a Multitech Conduit (LoRa Card MTAC-LORA-H-915) with mPower 6.3.0 version. The process crashes and does not start.

What did you expect?

I did expect the concentratord to start as it should.

Steps to reproduce this issue

Steps:

  1. Install mPower 6.3.0 on a Multitech Conduit gateway (model used is MTCDT-L4N1)
  2. Install chirpstack-concentratord, following the instructions as indicated in documentation (https://www.chirpstack.io/docs/chirpstack-concentratord/installation/multitech.html)
  3. Attempt to start chirpstack-concentratord and notice it does not fork in the background (process exits)
  4. See the logs / command output

Could you share your log output?

root@mtcdt:/var/config/chirpstack-concentratord-sx1301/ap2# /opt/chirpstack-concentratord-sx1301/chirpstack-concentratord-sx1301 -c concentratord.toml -c channels.toml -c region.toml
thread 'main' panicked at chirpstack-concentratord-sx1301/src/main.rs:111:80:
called `Result::unwrap()` on an `Err` value: lgw_start failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
root@mtcdt:/var/config/chirpstack-concentratord-sx1301/ap2# RUST_BACKTRACE=1 /opt/chirpstack-concentratord-sx1301/chirpstack-concentratord-sx1301 -c concentratord.toml -c channels.toml -c region.toml
thread 'main' panicked at chirpstack-concentratord-sx1301/src/main.rs:111:80:
called `Result::unwrap()` on an `Err` value: lgw_start failed

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
root@mtcdt:/var/config/chirpstack-concentratord-sx1301/ap2# RUST_BACKTRACE=full /opt/chirpstack-concentratord-sx1301/chirpstack-concentratord-sx1301 -c concentratord.toml -c channels.toml -c region.toml
thread 'main' panicked at chirpstack-concentratord-sx1301/src/main.rs:111:80:
called `Result::unwrap()` on an `Err` value: lgw_start failed

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
stack backtrace:
   0:   0x29200c - <unknown>
   1:   0x2dced8 - <unknown>
   2:   0x28ea40 - <unknown>
   3:   0x291e40 - <unknown>
   4:   0x29366c - <unknown>
   5:   0x2932bc - <unknown>
   6:   0x293ba0 - <unknown>
   7:   0x2939fc - <unknown>
   8:   0x292554 - <unknown>
   9:   0x2937c4 - <unknown>
  10:    0x1e8b8 - <unknown>
  11:    0x1ed04 - <unknown>
  12:    0x554f0 - <unknown>
  13:    0x73e18 - <unknown>
  14:    0x81770 - <unknown>
  15:   0x2887b8 - <unknown>
  16:    0x561d4 - <unknown>
root@mtcdt:/var/config/chirpstack-concentratord-sx1301/ap2#

2024-06-24T16:49:22.323623+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Starting Concentratord SX1301 (version: 4.4.1, docs: https://www.chirpstack.io/docs/chirpstack-concentratord/)
2024-06-24T16:49:22.329014+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Setting spi device path, spidev_path: /dev/spidev32765.2
2024-06-24T16:49:22.334618+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Setting board configuration, lorawan_public: true, clock_source: 0
2024-06-24T16:49:22.341344+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Setting up concentrator radios
2024-06-24T16:49:22.345681+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring radio, radio: 0, enabled: true, center_freq: 902700000, type: SX1257
2024-06-24T16:49:22.347451+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring radio, radio: 1, enabled: true, center_freq: 903700000, type: SX1257
2024-06-24T16:49:22.349203+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Setting up concentrator channels
2024-06-24T16:49:22.351008+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 0, enabled: true, freq: 902300000, rf_chain: 0, if_freq: -400000
2024-06-24T16:49:22.353912+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 1, enabled: true, freq: 902500000, rf_chain: 0, if_freq: -200000
2024-06-24T16:49:22.355835+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 2, enabled: true, freq: 902700000, rf_chain: 0, if_freq: 0
2024-06-24T16:49:22.357630+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 3, enabled: true, freq: 902900000, rf_chain: 0, if_freq: 200000
2024-06-24T16:49:22.359434+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 4, enabled: true, freq: 903100000, rf_chain: 0, if_freq: 400000
2024-06-24T16:49:22.361229+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 5, enabled: true, freq: 903300000, rf_chain: 1, if_freq: -400000
2024-06-24T16:49:22.363027+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 6, enabled: true, freq: 903500000, rf_chain: 1, if_freq: -200000
2024-06-24T16:49:22.365055+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring multi-SF LoRa channel, channel: 7, enabled: true, freq: 903700000, rf_chain: 1, if_freq: 0
2024-06-24T16:49:22.366720+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring Std LoRa channel, enabled: true, freq: 903000000, rf_chain: 0, if_freq: 300000
2024-06-24T16:49:22.368524+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Configuring FSK channel, enabled: false, freq: 0, rf_chain: 0, if_freq: 0
2024-06-24T16:49:22.370096+00:00 mtcdt chirpstack-concentratord-sx1301[3828]: Starting the concentrator

spidev_path: /dev/spidev32765.2 looks odd to me.

Your Environment

Component Version
Concentratord 4.4.1

add Semtech SX1302 CoreCell CN490 to chirpstack-concentratord

sx1302c490gw1_cn490.zip

China occupies more than 50% of the LoRa market, and more and more developers are making gateways based on sx1302. It is strange that there is no CN490 option in ChirpStack Concentratord.

For this, I have added the sx1302c490gw1_cn490.rs file(this attach file), hoping that the next version of ChirpStack Concentratord will add the CN490 band. Let more Chinese users use ChirpStack, enrich the community, and exert greater influence.

Add config options for Reset/Power Chip/Line

Preface

I really hope that its fine to open an issue for this. Otherwise I am happy to move this to the forum.

Possible Duplicate

This is similar to #15 , but I don't think the RAK 5146 has these changes yet based on commit d3b039f.

Feature

I am using a RAK 5146 on a custom built board running Debian 11, and am looking to migrate to concentratord. The only thing stopping me right now is that it seems like gpiochip0 is hard coded in the config for the RAK 5146 located in chirpstack-concentratord-sx1302/src/config/vendor/rak/rak5146.rs:

sx1302_reset_pin: Some((
    "/dev/gpiochip0".to_string(), // <----------------------------- gpiochip0 hardcoded here
    conf.gateway.sx1302_reset_pin.unwrap_or(17),
)),
sx1302_power_en_pin: conf
    .gateway
    .sx1302_power_en_pin
    .map(|v| ("/dev/gpiochip0".to_string(), v)), // <----------------------------- and here
..Default::default()

It would be great for flexibility to provide a gpiochip number and a gpio line for each possible pin in the config, but at minimum it would be nice just to specify a GPIO chip.

Can I do this myself

Probably yes, although I do want to know whether you want all of them to be consistent or whether I can just change the 5146. I haven't looked super in depth at the code but I imagine that changes will need to occur in:

1. The config as above

File: chirpstack-concentratord-sx1302/src/config/vendor/rak/rak5146.rs

sx1302_reset_pin: Some((
    conf
    .gateway
    .sx1302_reset_chip
    .clone()
    .unwrap_or("/dev/gpiochip0".to_string()),

    conf
    .gateway
    .sx1302_reset_line
    .unwrap_or(17),
)),

It would have to be changed for each vendor/model combo if we want to be consistent.

2. The config itself

File: chirpstack-concentratord-sx1302/src/config/mod.rs

Instead of just having a single pin for each utility, we'll specify both chip and line:

pub sx1302_reset_chip: Option<u32>,
pub sx1302_reset_line: Option<u32>,
pub sx1302_power_en_chip: Option<u32>,
pub sx1302_power_en_line: Option<u32>,
pub sx1261_reset_chip: Option<u32>,
pub sx1261_reset_line: Option<u32>,

Others

I am not fully sure how the toml is parsed in the project, so there might need to be changes to field names / macros somewhere else. I am also anticipating that I'll need to modify some tests. It's been a bit since I've worked with rust, so it'll take me some time to figure out what needs to change.


If you give me an idea of whether I am on the right track / missing anything, I'd be happy to write the code and make a PR. Thank you for all of the work you put into the stack!

Fixed Longitude and Latitude as in Semtech Packet_forwarder

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

By default, when a concentrator shield is not equipped with a GPS/GNSS receiver, the gateway will always report a 0,0 GPS coordinates. However, using the default Semtech Packet Forwarder, there is an option in the config file that allows the user to set some "fixed" coordinates, including altitude by the way, in order to show the gateway on the map in the Application Server "Gateway" sub menu.
It would be nice to be able to do the same by adding this feature in the concentratord config file.

What is the use-case?

The physical concentrator shield is not equipped with a GPS/GNSS receiver and the gateway is probably assumed not to move a lot ;-)

Implementation description

add three possible options in the global.toml file such as:

ref_latitude=xx.xxxxxxxx
ref_longitude=yyy.yyyyyyyy
ref_altitude=aaaa

These values would overwrite the default 0, 0 values sent so far

Can you implement this by yourself and make a pull request?

Unfortunately not.

Request AS923 and US915 support for Seeed WM1302 module

Currently there are only EU868 preset for Seeed WM1302 on Concentratord. I Already tried to changed channel plan and test on Dragino LDDS75 sensors but doesn't work.

I'm using on SenseCAP M1, It would be nice for running dual mode Helium network and Chirpstack.

photo_2023-01-18_23-08-25

photo_2023-01-18_23-08-25 (2)

Add GPS support for Waveshare SX1302 hat.

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Please add support for the GPS on the Waveshare LORA shield.

What is the use-case?

To have location and time sync

Implementation description

The GPS on the Waveshare board seems to be an L76K GPS that has been reprogrammed to output Ublox binary and NMEA data. The only issue is that the RMC message contains an extra field at the end, before the CRC. This breaks the default SX1302_hal driver, for which I have created the following request/bug: Lora-net/sx1302_hal#90

I can't figure out of this repo pulls in that sx1302_hal repo. Should the RMC issue be fixed in sx1302_hal before the GPS can be used in chirpstack, or can the issue be fixed in this repo?

Can you implement this by yourself and make a pull request?

Not yet. No documentation, that I can find, about building this repo.

GPS time reference is not valid (Multitech)

  • [x ] The issue is present in the latest release.
  • [x ] I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

Build and installed concentratord for Multitech. Messages are being sent okay, GPS is not working thou. I checked the system time and date gives an accurate date. Gateway has a clear sky view and used to send a fix while running with the pkt-fwd.

What did you expect?

GPS to work.

Steps to reproduce this issue

Steps:

  1. Install https://static.iot.wolfsburg.digital/chirpstack/chirpstack-concentratord_3.0.2-1-gfee1bed-r1_arm926ejste.ipk
  2. Start concentratord
  3. Check /var/log/messages

Could you share your log output?

PRODWOBMTCDT09:/home/mtadm# /etc/init.d/chirpstack-concentratord-ap1 restart
stopping chirpstack-concentratord
Found MTAC-LORA-H-868 with MTAC-LORA-1.5 hardware at ap1
Starting chirpstack-concentratord
PRODWOBMTCDT09:/home/mtadm# tail /var/log/messages -f                       
Oct 19 09:41:20 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Starting the concentrator
Oct 19 09:41:23 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Creating socket for publishing events, bind: ipc:///tmp/concentratord_event
Oct 19 09:41:23 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Creating socket for receiving commands, bind: ipc:///tmp/concentratord_command
Oct 19 09:41:23 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Initializing JIT queue, capacity: 32
Oct 19 09:41:23 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Starting GPS validation loop
Oct 19 09:41:23 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: GPS TTY port opened for GPS synchronization, gps_tty_path: /dev/ttyXRUSB2
Oct 19 09:41:24 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093284.954873654s
Oct 19 09:41:25 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093285.955473528s
Oct 19 09:41:26 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093286.95601952s
Oct 19 09:41:27 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093287.956599773s
Oct 19 09:41:28 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093288.957125485s
Oct 19 09:41:29 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093289.957631936s
Oct 19 09:41:30 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093290.958167487s
Oct 19 09:41:31 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093291.958702257s
Oct 19 09:41:32 PRODWOBMTCDT09 user.warn chirpstack-concentratord-sx1301[29766]: GPS time reference is not valid, age: 1603093292.959222687s
Oct 19 09:41:33 PRODWOBMTCDT09 user.info chirpstack-concentratord-sx1301[29766]: Frame received, uplink_id: a5d90fd3-d464-47f0-bcd4-fc19ac7778e6, count_us: 11925628, freq: 868300000, bw: 125000, mod: LoRa, dr: SF12

Your Environment

Component Version
Application Server v3.12.2
Network Server
Gateway Bridge
Chirpstack API
Geolocation
Concentratord 3.0.2-1-gfee1bed-r1

Allow the use of USB connected GPS

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Allow the use of USB connected GPSes. If the SX1302 HAL is used as-is, then it only enables UBlox binary messages on the UART port of the GPS. Even if the binary messages is enabled manually and saved to GPS flash, at startup the HAL disables binary messages on all ports except UART.

What is the use-case?

Adding a USB GPS to systems that doesn't ship with an integrated GPS, or that ships with a non Ublox GPS.

Implementation description

Fork the SX1302 HAL so that modifications can be made. The maintainers for the HAL cater for a very ideal world use case, and anything that diverge from that ideal case is ignored.

Once forked, during GPS init, enable ublox messages on all GPS ports, not just UART1

Can you implement this by yourself and make a pull request?

No, as the HAL needs to be forked.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.