Any way to disable multiple LinkADRReq per downlink?


I didn’t know if this fit in Network Server or Setup and Config better, and I wanted to avoid cross-posting. Please let me know if I should post this in another place to get better answers.

I am somewhat familiar with Chirpstack, but I am not an expert and I don’t thoroughly understand all the settings, so please provide GUI and/or .

I have a device that is using LoRaWAN v1.0.3A. Chirpstack is sending multiple LinkADRReq’s to the device in a single message, which the spec supports. However, the device is ignoring all but the first LinkADRReq. This is a problem, because Chirpstack sends a disabling LinkADRReq to turn off almost everything and set DR0/P0, then has a second one to turn on the intended settings…but instead the device stays at the almost all disabled DR0/P0 level.

The manufacturer’s technical support has confirmed this is a bug and the sensor is not compliant to the spec because of it.

Is there a way to force Chirpstack to send a maximum of one LinkADRReq per downlink? It would be great if I could do this on a device-profile level, but system-wide would also resolve the issue until the manufacturer issues a firmware update to address the bug.

Thank you!


No there isn’t or it would have to disable the channels in blocks of 16, and thus multiple downlinks are required and you potentially would experience packet-loss until the last LinkADRReq mac-command has been sent to the device. I would like to avoid adding workarounds in the codebase to compensate for device bugs.

@brocaar Thank you for your response!

This issue showed up after I installed a firmware patch. After working with the manufacturer, they released another firmware patch, but the issue remained.

This made me realize the error was my own: I had set data rate max to 5 even though I am operating in US 915, which has a data rate maximum of 4.

Before the original firmware patch, the sensor would accept the invalid datarate. However, the initial sensor patch fixed this - and now the sensor was ignoring the invalid datarate.

Changing the datarate maximum to 4 solved this issue.