Any way to disable multiple LinkADRReq per downlink?

ChirpStack Network Server
1

Hello,

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!

Abe

2

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.

3

@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.