Handling ADR from the node app side


I’m using my devices with ADR. It happens that the servers istructs the node device to increase the DR. The device steps up the DR, but then the subsequent packets aren’t received by the server.

From what I can see I think the SNR goes below the limit after changing the DR. Is there a way to enable some logs to see what is going on under the hood on the server?

How is the situation meant to be handled in general if e.g my device is on DR4 and no more packets are received? Should I request an ACK every N packets sent and if there is no ACK I should lower the DR?

Thanks in advance for your answers. Marko

According to the LoRaWAN spec , if a device using ADR does not receive any downlink for ADR_ACK_LIMIT + ADR_ACK_DELAY consecutive uplinks , it will decrease its data rate to regain connectivity. The default value of those constants is 32, this means the device will initially wait for 64 uplinks without downlinks, then decrease its datarate one step, then again after an additionnal 32 uplinks without any repsonse, etc, …
You may be able to tune those constants on your device.
You should not try to do this at the application layer , as this will probably mess up with the ADR management policy of the NS.
Something else is probbaly wrong in your situation because in my experience if your packet loss rate was ok (<20%) using DRn , goind to DR(n+1) should not break the link, you should still be receiving at least 30% of the frames.

1 Like

exact mechanism is described at in LoRaWAN1.0.3 specification