Hi all,
I have a self-hosted ChirpStack v4.16.2 setup (Docker), EU868 region, with 4 Dragino LHT65-E3 sensors (OTAA, MAC version LoRaWAN 1.0.4, Regional parameters revision RP002-1.0.3). Device profile has "Default ADR algorithm (LoRa only)" assigned.
Symptom: all 4 devices have been stuck at DR0 (SF12) for months, despite:
- Uplinks carrying adr=true
- Comfortable SNR margin (observed SNR consistently between +6 and +12 dB across all 4 devices, well above what SF7-SF9 would require)
- ADR algorithm correctly assigned in the device profile
What I've checked so far:
- Device profile "ADR algorithm" field is set to "Default ADR algorithm (LoRa only)" (not disabled).
- Raised log level to "debug" in chirpstack.toml and restarted the container.
- Captured multiple full uplink/downlink cycles in the logs, including one where a downlink was actually sent (carrying a DevStatusReq MAC command). In every case, I see uplink processing, metrics being saved, and (when applicable) the DevStatusReq downlink — but never any log line referencing ADR or LinkADRReq, at any log level.
- Devices do occasionally rejoin (OTAA), roughly every 1-2 weeks based on the "Errors" panel in the UI, but even between rejoins there are many days (and thousands of uplinks) of continuous operation without any DR change.
Given the SNR margin, I'd expect the default ADR algorithm to compute several possible steps up (per the (link_budget - installation_margin)/3 formula I found referenced in the docs/forum), yet nothing seems to happen at all - not even a decision not to act that gets logged.
Questions:
- Is there a known minimum number of consecutive/qualifying uplinks (with no gaps in fCnt) required before the default ADR algorithm acts? Does a rejoin reset that history?
- Is "installation margin" configurable anywhere in v4 (I don't see it in the Device Profile UI), or is it a fixed internal constant?
- Is there a way to get more verbose (debug-level) logging specifically for the ADR decision process? The "debug" log level in chirpstack.toml didn't seem to add any ADR-related output.
- Any known issues in v4.16.2 that would prevent LinkADRReq from ever being queued even when the algorithm should trigger it?
Happy to share full log excerpts, device profile config, or Redis key dumps if useful. Thanks in advance!