Sorry, but where is the CN470 band?
There are loads in there and by copying the templates, you can make this yourself.
- Add it to here like so (removing the **'s):
"as923",
"as923_2",
"as923_3",
"as923_4",
"au915_0",
"cn779",
**"cn470",**
"eu433",
"eu868",
"in865",
"ism2400",
"kr920",
"ru864",
"us915_0",
"us915_1",
- Create the associated file (modifying possibly the CN779.toml one below) and save it as cn470.toml
# This file contains an example CN779 configuration.
[[regions]]
# Name is an user-defined identifier for this region.
name="cn779"
# Common-name refers to the common-name of this region as defined by
# the LoRa Alliance.
common_name="CN779"
# Gateway configuration.
[regions.gateway]
# Force gateways as private.
#
# If enabled, gateways can only be used by devices under the same tenant.
force_gws_private=false
# Gateway backend configuration.
[regions.gateway.backend]
# The enabled backend type.
enabled="mqtt"
# MQTT configuration.
[regions.gateway.backend.mqtt]
# Event topic template.
event_topic="cn779/gateway/+/event/+"
# Command topic template.
command_topic="cn779/gateway/{{ gateway_id }}/command/{{ command }}"
# MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
server="tcp://mosquitto: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=true
# 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. When left blank,
# a random id will be generated. This requires clean_session=true.
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=""
# Gateway channel configuration.
#
# Note: this configuration is only used in case the gateway is using the
# ChirpStack Concentratord daemon. In any other case, this configuration
# is ignored.
[[regions.gateway.channels]]
frequency=779500000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=779700000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=779900000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
# Region specific network configuration.
[regions.network]
# Installation margin (dB) used by the ADR engine.
#
# A higher number means that the network-server will keep more margin,
# resulting in a lower data-rate but decreasing the chance that the
# device gets disconnected because it is unable to reach one of the
# surrounded gateways.
installation_margin=10
# RX window (Class-A).
#
# Set this to:
# 0: RX1 / RX2
# 1: RX1 only
# 2: RX2 only
rx_window=0
# RX1 delay (1 - 15 seconds).
rx1_delay=1
# RX1 data-rate offset
rx1_dr_offset=0
# RX2 data-rate
rx2_dr=0
# RX2 frequency (Hz)
rx2_frequency=786000000
# Prefer RX2 on RX1 data-rate less than.
#
# Prefer RX2 over RX1 based on the RX1 data-rate. When the RX1 data-rate
# is smaller than the configured value, then the Network Server will
# first try to schedule the downlink for RX2, failing that (e.g. the gateway
# has already a payload scheduled at the RX2 timing) it will try RX1.
rx2_prefer_on_rx1_dr_lt=0
# Prefer RX2 on link budget.
#
# When the link-budget is better for RX2 than for RX1, the Network Server will first
# try to schedule the downlink in RX2, failing that it will try RX1.
rx2_prefer_on_link_budget=false
# Downlink TX Power (dBm)
#
# When set to -1, the downlink TX Power from the configured band will
# be used.
#
# Please consult the LoRaWAN Regional Parameters and local regulations
# for valid and legal options. Note that the configured TX Power must be
# supported by your gateway(s).
downlink_tx_power=-1
# ADR is disabled.
adr_disabled=false
# Minimum data-rate.
min_dr=0
# Maximum data-rate.
max_dr=5
# Rejoin-request configuration (LoRaWAN 1.1)
[regions.network.rejoin_request]
# Request devices to periodically send rejoin-requests.
enabled=false
# The device must send a rejoin-request type 0 at least every 2^(max_count_n + 4)
# uplink messages. Valid values are 0 to 15.
max_count_n=0
# The device must send a rejoin-request type 0 at least every 2^(max_time_n + 10)
# seconds. Valid values are 0 to 15.
#
# 0 = roughly 17 minutes
# 15 = about 1 year
max_time_n=0
# Class-B configuration.
[regions.network.class_b]
# Ping-slot data-rate.
ping_slot_dr=0
# Ping-slot frequency (Hz)
#
# set this to 0 to use the default frequency plan for the configured region
# (which could be frequency hopping).
ping_slot_frequency=0
1 Like
This is fantastic and a huge time/resource saver. Many thanks!
The example shows different event topics for the MQTT integration, i assume there would be a similar configuration if using Azure IoT Hub?
I have not yet integrated the Azure IoT Hub for ChirpStack v4 and the first ChirpStack v4 version will not support it (same with GCP Cloud IoT Core). As soon as the first ChirpStack v4 stable is out, this will be one of my first priorities to integrate.
1 Like
Thanks for your improvements on the v4, Chirpstack improves quickly.
What about the downlink frame logging to a persistent storage like postgresql ? I think its a good time to implement the device down event. The downlink frames should be in the loradatastore like the uplink frames. I develop my own downlink event in Chirpstack v3, our tenants need it. If you wont implement the downlink event, I will do it again in Chirpstack V4 with Rust. I think this is a point that should be reconsidered.
Again, I can help you on the development of this feature if you want.
1 Like
I tried the way you said, but it didn’t work. When I add a new locale file, it does not take effect - #3 by gluhar
Did you modify chirpstack-gateway-bridge.toml?
it should include this:
[integration.mqtt]
event_topic_template="cn470/gateway/{{ .GatewayID }}/event/{{ .EventType }}"
state_topic_template="cn470/gateway/{{ .GatewayID }}/state/{{ .StateType }}"
command_topic_template="cn470/gateway/{{ .GatewayID }}/command/#"
After I modified it like you said, it still doesn’t work. The configuration took effect. The CN470 model selection still hasn’t appeared
...
chirpstack_1 | Aug 26 10:25:37.022 INFO chirpstack::gateway::backend::mqtt: Connected to MQTT broker region_name=cn470
chirpstack_1 | Aug 26 10:25:37.022 INFO chirpstack::gateway::backend::mqtt: Subscribing to gateway event topic region_name=cn470 event_topic=cn470/gateway/+/event/+
...
I did another test, deleting the file ISm2400. toml and deleting ISm2400 in Chirpstack. toml. However, ISM2400 still exists in the region selection box of Add Device Profile. So, I guess they are not related, or I take a wrong way.
chirpstack.toml as follow
......
enabled_regions=[
"as923_2",
"as923_3",
"as923_4",
"au915_0",
"cn470",
"cn779",
"eu433",
"eu868",
"in865",
"kr920",
"ru864",
"us915_0",
"us915_1",
]
......
(I don’t know why I can’t upload pictures)
can you post contents of your chirpstack-gateway-bridge.toml file?
Also, I assume you are rebooting/restarting after the change?
I’m using docker-compose. I restart after every configuration.
If possible,you can visit my web.175.24.183.206:8080
# See https://www.chirpstack.io/gateway-bridge/install/config/ for a full
# configuration example and documentation.
[integration.mqtt.auth.generic]
servers=["tcp://mosquitto:1883"]
username=""
password=""
[integration.mqtt]
event_topic_template="cn470/gateway/{{ .GatewayID }}/event/{{ .EventType }}"
state_topic_template="cn470/gateway/{{ .GatewayID }}/state/{{ .StateType }}"
command_topic_template="cn470/gateway/{{ .GatewayID }}/command/#"
You have this at the bottom?
marshaler="protobuf"
also, add the gateway only after you have the right configuration not before
I don’t know why all regions are active in the web except CN470. After toml file of CN470 is added，you can see related logs shown when server is starting. It means CN470 was parsed，but just didn’t appear in the web.
So maybe there’s something wrong with typescript code of frontend.
Let me check on this, it might be that I forgot to add it or forgot to merge this into the master branch. Let me check…
Thank you for your attention and reply! Besides, I have confirmed that the versions of servers I use are the latest, which are listed below:
chirpstack:4.0.0-rc.3
chirpstack-gateway-bridge:4.0.0-rc.1
chirpstack-rest-api:4.0.0-rc.1
Looking forward to the improvement.
I just merged the CN470 configuration into the master branch (Add missing CN470 configuration. · chirpstack/chirpstack@0fa4071 · GitHub). This will be included in the next (RC) release.
Has anyone gotten V4 working with Semtech Basic Station?
I was able to easily use SBS with the older 3.1x installations, but I’m having trouble figuring out how to convert my V4 install over.
Seems like the V4 install uses the legacy Semtech forwarder by default.
Jim
Not much has changed with regards to the Basics Station support in v4. It is important however to confirm that your MQTT topic configuration matches. The default configuration uses a region prefix, to support multiple regions using the same MQTT broker.