MKR WAN 1310 + RAK2243 + ChirpStack 4.18: uplinks reach server, downlinks not reaching device (was working, now failing)

LPWAN Developer Gateways / Concentrators RAK2245 / RAK2243
1

I have a US915 LoRaWAN setup that was working a few days ago and has degraded. Looking for help diagnosing.

Setup:

  • Device: Arduino MKR WAN 1310 using MKRWAN library, US915, OTAA, MAC v1.0.3

  • Gateway: RAK2243 HAT on Raspberry Pi 4 (Debian 12 Bookworm), running RAK’s ttn-gateway packet forwarder from rak_common_for_gateway install. SX1301 concentrator.

  • Network Server: ChirpStack 4.18.0 on a separate Raspberry Pi (Debian 13 Trixie), with chirpstack-gateway-bridge and mosquitto on the same Pi.

  • Distance: Bench device about 40 ft from the gateway, indoor, with walls between.

  • Both ends configured for US915 sub-band 2 (channels 8-15). Device firmware uses explicit enableChannel(8..15) + disableChannel for the rest. Gateway global_conf.json shows the matching 8 multi-SF channels at 903.9-905.3 MHz on sub-band 2.

Was working a few days ago: clean joins, regular uplinks, downlinks delivered in ~60s. No firmware or gateway config changes since then.

Current symptom — directional asymmetry:

The gateway IS hearing the device’s uplinks (sometimes successfully, sometimes CRC_FAIL), but the device is NOT receiving downlinks from the gateway.

Specifically:

  • Device serial monitor: “Attempting OTAA join… Join FAILED. Retrying in 30s…” in a loop

  • Gateway journal: receives JoinRequest packets with strong signal (RSSI -55 to -65 dBm, SNR +9 dB) when they arrive

  • ChirpStack UI: shows JoinRequest received, generates JoinAccept downlink in the LoRaWAN Frames tab

  • Gateway journal: shows the JoinAccept being scheduled for downlink transmission (PULL_RESP received, txpk packet logged with correct frequency 923.9 MHz, SF7BW500, codr 4/5)

  • Device: never sees the JoinAccept, stays in retry loop

Reception rate at the gateway (uplink side):

Of the device’s once-per-minute transmissions, the gateway concentrator hears roughly 1-2 in 5. Of those it hears, about half have CRC_OK, the rest CRC_FAIL. When CRC_OK, RSSI is excellent (-55 to -65 dBm). When CRC_FAIL, RSSI is similar — strong signal, just decoded bits failing CRC.

What I have tried:

  • Verified antennas are physically tight, vertical, factory-supplied

  • Verified lorawan_public: true in gateway config (sync word 0x34)

  • Verified firmware’s enableChannel(8..15) config

  • Power-cycled the gateway Pi (hard unplug 10s, replug)

  • Tried delay(2000) before modem.begin(US915) in firmware setup (no change)

  • Reset the device multiple times

  • Verified ChirpStack frame-counter validation is disabled (so stale FCnt isn’t blocking)

  • Reset gateway service (systemctl restart ttn-gateway)

None of the above resolved it.

What I want to understand:

  1. Why downlinks aren’t reaching the device despite being scheduled correctly on the gateway side. RX window timing? Device receive path issue? Something specific about RAK2243 + MKR WAN 1310 + ChirpStack?

  2. Why CRC_FAIL on roughly half of received uplinks when RSSI is excellent. Local interference signature? Hardware degradation? Something else?

  3. Has anyone seen this specific pattern (working → degrading → uplinks-work-but-downlinks-fail) on a stable setup?

Logs available:

I can paste full gateway journal output, ChirpStack LoRaWAN Frames screenshots, and device serial monitor output if helpful. Will respond to anyone offering specific things to check.

Thanks for any insight. I am well out over my ski’s here!

2

Hi,

Could you please provide the following so we can troubleshoot the US915 downlink issue?

  1. Please confirm whether channel 65 is enabled on the end device. For US915 sub-band 2, the expected uplink channels are 8-15 + channel 65.
  2. Please provide the end device logs from the point where it starts the JoinRequest, so we can see when and how the communication starts failing (JoinRequest, JoinAccept, RX windows, data rate/channels, etc.).
  3. Please provide Syslog logs of the PacketForwarder, ChirpStack, ChirpStack gateway-bridge covering the same time period.
1 Like