Network Server Config, Devices transmitting on wrong channel after join

I’m trying to get Chirpstack working with our RAK7249 gateway. We have successfully configured basic station on the gateway and got the gateway communicating with the Chirpstack network server. So we have made it that far. So I added a Dragino LHT65 device under a new application and had it join. The issue is that it gets through a join and then after the first post-join downlink it seems to get stuck on US915 channel 65. First off, I don’t know why the gateway won’t receive under this channel, but second why is it always wanting to transmit on this channel. I believe we have the network server configured correctly in Chirpstack, but maybe we are missing something. This LHT65 joins TTN just fine.

Here is the behavior of the LHT65:

Gateway Bridge Config:

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

[backend]
type="basic_station"


[backend.basic_station]


bind=":3002"

stats_interval="30s"


ping_interval="1m0s"

# Read timeout.
#
# This interval must be greater than the configured ping interval.
read_timeout="1m5s"

# Write timeout.
write_timeout="1s"

# Region.
#
# Please refer to the LoRaWAN Regional Parameters specification
# for the complete list of common region names.
region="US915"

# Minimal frequency (Hz).
frequency_min=902000000

# Maximum frequency (Hz).
frequency_max=928000000

# Concentrator configuration.
#
# This section contains the configuration for the SX1301 concentrator chips.
# Example:
[[backend.basic_station.concentrators]]

# Multi-SF channel configuration.
[backend.basic_station.concentrators.multi_sf]

# Frequencies (Hz).
frequencies=[
  903900000,
  904100000,
  904300000,
  904500000,
  904700000,
  904900000,
  905100000,
  905300000
]

# LoRa STD channel.
[backend.basic_station.concentrators.lora_std]

# Frequency (Hz).
frequency=904600000

# Bandwidth (Hz).
bandwidth=500000

# Spreading factor.
spreading_factor=8

Network Server Config:

[general]
# Log level
#
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=4

[postgresql]
dsn="postgres://chirpstack_ns:chirpstack_ns@postgresql/chirpstack_ns?sslmode=disable"

[redis]
url="redis://redis:6379"

[network_server]
net_id="000000"
deduplication_delay="200ms"
device_session_ttl="744h0m0s"
get_downlink_data_delay="100ms"

[network_server.band]
name="US915"
uplink_dwell_time_400ms=false
downlink_dwell_time_400ms=false
uplink_max_eirp=-1
repeater_compatible=false

[network_server.network_settings]
enabled_uplink_channels=[8, 9, 10, 11, 12, 13, 14, 15, 65]
installation_margin=10
rx_window=0
rx1_delay=1
rx1_dr_offset=0
rx2_dr=-1
rx2_frequency=-1
rx2_prefer_on_rx1_dr_lt=0
rx2_prefer_on_link_budget=false
gateway_prefer_min_margin=10
ownlink_tx_power=-1
disable_mac_commands=false
disable_adr=false
max_mac_command_error_count=3

[network_server.network_settings.class_b]
ping_slot_dr=0
ping_slot_frequency=0

[network_server.network_settings.rejoin_request]
enabled=false
max_count_n=0
max_time_n=0

[network_server.scheduler]
scheduler_interval="1s"

[network_server.scheduler.class_c]
device_downlink_lock_duration="2s"
gateway_downlink_lock_duration="0s"
multicast_gateway_delay="2s"

[network_server.api]
bind="0.0.0.0:8000"

[network_server.gateway]
client_cert_lifetime="8760h0m0s"
force_gws_private=false
downlink_timeout="1s"

[network_server.gateway.backend]
type="mqtt"
multi_downlink_feature="hybrid"

[network_server.gateway.backend.mqtt]
server="tcp://mosquitto:1883"
max_reconnect_interval="1m0s"
qos=0
clean_session=true
client_id=""

[join_server]
 resolve_join_eui=false

[join_server.default]
server="http://chirpstack-application-server:8003"

Sorry, it won’t let me post more picture in my first post and I’m not sure how to fix all the formatting.

Here is the gateway concentrator config on the RAK7249:

So here is what we see in chirpstack:

Here is the info in the downlink. You can see chMask[1] get set to true. Which I think corresponds to the second US sub band. I’m not sure what is going on with the second chMask

So it turns out the RAK7249 does not work with 500kHz channels by my experience. My Multitech gateway sees the packets in the LoRa log, but the RAK will not. The LHT65 tries the 500kHz channel first and that is what is causing the problems. If I change the Chirpstack channel config to remove channel 65 everything works fine. I emailed RAK about it and they said they would report it. Of course I haven’t heard anything back on this…

I don’t have a RAK7249, but I just sent an SF8 BW500 uplink packet at a RAK833 card being operated by the upstream Semtech packet forwarder code, and it received it just fine. The only real difference between that and the RAK2247 cards is the slower SPI bus speed (which I use regardless) so I doubt it wouldn’t work if I swapped that in either.

This seems like it’s probably a software/configuration problem.

Do you have any indpendent confirmation that the node is properly accomplishing the transmission on the LoRa standard channel?

If you look at the lowest level logging on the RAK gateway, do you see any hints of it being received?

This is the config in the gateway. All I know is the Multitech gateway that is connected to the TTN was seeing the SF8 BW500 packets. The RAK log showed nothing when there was a SF8, 500kHz transmission, but would show the 125kHz. If I set the channel configuration in Chirpstack to just do the multi-spread factor 125khz channels, everything works perfect.