Data Rate Not Updating with ADR in MCCI LMIC Library on ChirpStack Server

We are currently experiencing an issue while implementing Adaptive Data Rate (ADR) functionality using the MCCI LoRaWAN LMIC library. After sending an uplink with the ADR flag enabled, the ChirpStack server responds as expected with commands to adjust the Data Rate (DR) (spreading factor). However, the Data Rate (DR) on the end device does not change as anticipated.

Problem Description

We integrated ADR into our LoRaWAN application using the MCCI LoRaWAN LMIC library (v4.1.1). While the ChirpStack server successfully processes ADR requests and sends downlink commands to adjust the DR, the device fails to apply these changes. The DR remains static on the end device, despite the server’s responses indicating an update.

so i need a help from cloud configurations ,to acknowledge about the setup from chirpstack

Request for Assistance

  1. Could this issue be related to the LMIC library implementation of ADR?
  2. Are there any specific ChirpStack configurations or debugging steps we should follow to ensure correct ADR functionality?
  3. Has anyone else encountered this issue with the MCCI LMIC library or similar setups?

We appreciate any guidance or insights on resolving this ADR issue. Thank you in advance!

setup details:
Hardware:

  • Microcontroller: SAM D21
  • LoRa Radio Module: RFM95 from www.hoerf.com

LoRaWAN Stack:

  • LoRaWAN Version: 1.0.3
  • Library: MCCI LoRaWAN LMIC library v4.1.1

Server:

  • LoRaWAN Server: ChirpStack (latest stable version)

This doesn’t seem to be a problem with Chirpstack, but rather a problem with LMIC… why not post on LMIC’s GitHub?

1 Like

Does the device actually acknowledge the ADR commands with LinkADRAns? Is it able to receive any downlinks, at all?

Failure to be able to receive downlinks, will mean it cannot possibly process MAC commands - which include the ADR MAC commands.

If the device can acknowledge the LinkADRReq (as seen under “LoRaWAN Frames”), then you should look at what it ACK’ed or NACK’ed within the response. Sometimes, ADR is rejected because the channel mask doesn’t fit - due to the device somehow ending up with not sharing the same knowledge of channels as the LNS.