Does not perform JoinAcept

1

I installed chirpstack via Docker on a virtual machine with Ubuntu Server.
In my country Brazil, the pradão is au915, I changed the chirpstack settings to this default.
I added a device, but it only does JoinRequest, it’s not doing joinAcept.

When I direct my gateway to a company that has chirpstack it works normally, but when I direct it to mine it doesn’t work.

I have two questions:
Because I changed to the au915 standard, do I need to do any configuration for JoinAcept?
Do I need to release a specific port on the firewall for JoinAcept?

2

You show Events and LoRaWAN of the device to see any MIC error?

Are you using MQTT forwarder or UDP forwarder.

3

Have you configured your MQTT topic prefixes? The issue of “join-looping” typically happens when there is band-mismatch somewhere between device → gateway → server.

1 Like
4

I think it could be the bandwidth incompatibility between device → gateway → server.

I configured my gateway to work in subband 1 of the au915_0 region and did not change the chirpstack settings.

Here is my gateway configuration:
{
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 1, /* radio_1 provides clock to concentrator /
“antenna_gain”: 0, / antenna gain, in dBi /
“radio_0”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 915600000,
“rssi_offset”: -166.0,
“tx_enable”: true,
“tx_freq_min”: 915000000,
“tx_freq_max”: 928000000
},
“radio_1”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 916300000,
“rssi_offset”: -166.0,
“tx_enable”: false
},
“chan_multiSF_0”: {
/ Lora MAC channel, 125kHz, all SF, 916.8 MHz /
“enable”: true,
“radio”: 0,
“if”: -400000
},
“chan_multiSF_1”: {
/ Lora MAC channel, 125kHz, all SF, 917.0 MHz /
“enable”: true,
“radio”: 0,
“if”: -200000
},
“chan_multiSF_2”: {
/ Lora MAC channel, 125kHz, all SF, 917.2 MHz /
“enable”: true,
“radio”: 0,
“if”: 0
},
“chan_multiSF_3”: {
/ Lora MAC channel, 125kHz, all SF, 917.4 MHz /
“enable”: true,
“radio”: 0,
“if”: 200000
},
“chan_multiSF_4”: {
/ Lora MAC channel, 125kHz, all SF, 917.6 MHz /
“enable”: true,
“radio”: 1,
“if”: -300000
},
“chan_multiSF_5”: {
/ Lora MAC channel, 125kHz, all SF, 917.8 MHz /
“enable”: true,
“radio”: 1,
“if”: -100000
},
“chan_multiSF_6”: {
/ Lora MAC channel, 125kHz, all SF, 918.0 MHz /
“enable”: true,
“radio”: 1,
“if”: 100000
},
“chan_multiSF_7”: {
/ Lora MAC channel, 125kHz, all SF, 918.2 MHz /
“enable”: true,
“radio”: 1,
“if”: 300000
},
“chan_Lora_std”: {
/ Lora MAC channel, 500kHz, SF8, 917.5 MHz /
“enable”: true,
“radio”: 0,
“if”: 300000,
“bandwidth”: 500000,
“spread_factor”: 8
},
“chan_FSK”: {
/ FSK 100kbps channel, 903.0 MHz /
“enable”: false,
“radio”: 0,
“if”: 300000,
“bandwidth”: 250000,
“datarate”: 100000
},
“tx_lut_0”: {
/ TX gain table, index 0 /
“pa_gain”: 0,
“mix_gain”: 8,
“rf_power”: -6,
“dig_gain”: 0
},
“tx_lut_1”: {
/ TX gain table, index 1 /
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: -3,
“dig_gain”: 0
},
“tx_lut_2”: {
/ TX gain table, index 2 /
“pa_gain”: 0,
“mix_gain”: 12,
“rf_power”: 0,
“dig_gain”: 0
},
“tx_lut_3”: {
/ TX gain table, index 3 /
“pa_gain”: 1,
“mix_gain”: 8,
“rf_power”: 3,
“dig_gain”: 0
},
“tx_lut_4”: {
/ TX gain table, index 4 /
“pa_gain”: 1,
“mix_gain”: 10,
“rf_power”: 6,
“dig_gain”: 0
},
“tx_lut_5”: {
/ TX gain table, index 5 /
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 10,
“dig_gain”: 0
},
“tx_lut_6”: {
/ TX gain table, index 6 /
“pa_gain”: 1,
“mix_gain”: 13,
“rf_power”: 11,
“dig_gain”: 0
},
“tx_lut_7”: {
/ TX gain table, index 7 /
“pa_gain”: 2,
“mix_gain”: 9,
“rf_power”: 12,
“dig_gain”: 0
},
“tx_lut_8”: {
/ TX gain table, index 8 /
“pa_gain”: 1,
“mix_gain”: 15,
“rf_power”: 13,
“dig_gain”: 0
},
“tx_lut_9”: {
/ TX gain table, index 9 /
“pa_gain”: 2,
“mix_gain”: 10,
“rf_power”: 14,
“dig_gain”: 0
},
“tx_lut_10”: {
/ TX gain table, index 10 /
“pa_gain”: 2,
“mix_gain”: 11,
“rf_power”: 16,
“dig_gain”: 0
},
“tx_lut_11”: {
/ TX gain table, index 11 /
“pa_gain”: 3,
“mix_gain”: 9,
“rf_power”: 20,
“dig_gain”: 0
},
“tx_lut_12”: {
/ TX gain table, index 12 /
“pa_gain”: 3,
“mix_gain”: 10,
“rf_power”: 23,
“dig_gain”: 0
},
“tx_lut_13”: {
/ TX gain table, index 13 /
“pa_gain”: 3,
“mix_gain”: 11,
“rf_power”: 25,
“dig_gain”: 0
},
“tx_lut_14”: {
/ TX gain table, index 14 /
“pa_gain”: 3,
“mix_gain”: 12,
“rf_power”: 26,
“dig_gain”: 0
},
“tx_lut_15”: {
/ TX gain table, index 15 */
“pa_gain”: 3,
“mix_gain”: 14,
“rf_power”: 27,
“dig_gain”: 0
}

},

"gateway_conf": {
"gateway_ID": "AAAAAAAAAAAAAAAA",//  não altere! é utilizado o valor do arquivo local_conf.json
    /* change with default server address/ports, or overwrite in local_conf.json */
"server_address": "xxx.xxx.xxx.xxx",// alterar para a URL do servidor que será utilizado
    "serv_port_up": 1700,
    "serv_port_down": 1700,
    /* adjust the following parameters for your network */
    "keepalive_interval": 10,
    "stat_interval": 30,
    "push_timeout_ms": 1000,
    /* forward only valid packets */
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": false,
/* GPS configuration */
    "gps_tty_path": "/dev/ttyAMA0",
    /* GPS reference coordinates */
    "ref_latitude": 0.0,
    "ref_longitude": 0.0,
    "ref_altitude": 0

}

}

5

Here is the configuration of the region_au915_0 file:

This file contains an example AU915 example (channels 0-7 + 64).

[[regions]]

ID is an use-defined identifier for this region.

id=“au915_0”

Description is a short description for this region.

description=“AU915 (channels 0-7 + 64)”

Common-name refers to the common-name of this region as defined by

the LoRa Alliance.

common_name=“AU915”

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]

    # Topic prefix.
    #
    # 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="au915_0"

    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    server="tcp://$MQTT_BROKER_HOST: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=""

    # Keep alive interval.
    #
    # This defines the maximum time that that should pass without communication
    # between the client and server.
    keep_alive_interval="30s"

    # 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=915200000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=915400000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=915600000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=915800000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=916000000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=916200000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=916400000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=916600000
  bandwidth=125000
  modulation="LORA"
  spreading_factors=[7, 8, 9, 10, 11, 12]

[[regions.gateway.channels]]
  frequency=915900000
  bandwidth=500000
  modulation="LORA"
  spreading_factors=[8]

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=8

# RX2 frequency (Hz)
rx2_frequency=923300000

# 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

# Enabled uplink channels.
#
# Use this when ony a sub-set of the by default enabled channels are being
# used. For example when only using the first 8 channels of the US band.
# Note: when left blank / empty array, all channels will be enabled.
enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7, 64]


# 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=8

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

Here is the configuration of the chirpstack-gateway-bridge-basicstation-au915_0:

See Configuration - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server for a full

configuration example and documentation.

[integration.mqtt.auth.generic]
servers=[“tcp://mosquitto:1883”]
username=“”
password=“”

[integration.mqtt]
event_topic_template=“au915_0/gateway/{{ .GatewayID }}/event/{{ .EventType }}”
state_topic_template=“au915_0/gateway/{{ .GatewayID }}/state/{{ .StateType }}”
command_topic_template=“au915_0/gateway/{{ .GatewayID }}/command/#”

[backend]
type=“basic_station”

[backend.basic_station]
bind=“:3001”
tls_cert=“”
tls_key=“”
ca_cert=“”

region=“AU915”
frequency_min=915000000
frequency_max=928000000

[[backend.basic_station.concentrators]]

[backend.basic_station.concentrators.multi_sf]
frequencies=[
  915200000,
  915400000,
  915600000,
  915800000,
  916000000,
  916200000,
  916400000,
  916600000,
]

[backend.basic_station.concentrators.lora_std]
frequency=915900000
bandwidth=500000  
spreading_factor=8
7

I’m not digging into all that but ChatGPT says that your channels all align fine. Except:

chan_multiSF_4 has an IF of -300000, and it’s associated with radio_1 on frequency 916300000. The result is a frequency of 916000000, which is correct. However, the chan_Lora_std is set to an IF of 300000 on radio_0, which results in a central frequency of 917800000 instead of the expected 917500000. This discrepancy should be checked.

But that doesn’t seem like the issue to me.

The only unanswered piece here is the device. What device are you using? Are you sure that is configured for the correct channels? Also sharing a photo of the device events might help, along with the frequency of the join-request and corresponding join-accept.

1 Like