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!