The ADR in the TTN is turned off, but the LinkADRReq is also sent to the end device

The ADR in the TTN is turned off, but the LinkADRReq is also sent to the end device.

9699e763bb29344327f462faa2dae6f

I printed a message on ProcessMacCommands showing that there are still LinkADRReq.
The ADR of the device is also turned off.

430e5abf984a3f39b36bea73dd50520

image

Please read the LoRaWAN specification regarding ADR. Quoting from the 1.0.4 specification (4.3.1.1):

If the ADR bit is unset, the Network Server SHALL accept that the end-device MAY not comply with any attempt to control the number of retransmissions, the data rate, or the TX power of the end- device regardless of the received signal quality. The Network MAY still send commands to inform the end-device of the recommended configuration using the LinkADRReq command. An end-device SHOULD accept the channel mask controls present in LinkADRReq, even when the ADR bit is not set. The end-device SHALL respond to all LinkADRReq commands with a LinkADRAns indicating which command elements were accepted and which were rejected. This behavior differs from when the uplink ADR bit is set, in which case the end-device accepts or rejects the entire command.

2 Likes

But the version I’m using is 1.0.3.

If the ADR bit is set, the network will control the data rate of the end-device through the appropriate MAC commands. If the ADR bit is not set, the network will not attempt to control the data rate of the end-device regardless of the received signal quality. The ADR bit MAY be set and unset by the end-device or the Network on demand. However, whenever possible, the ADR scheme should be enabled to increase the battery life of the end-device and maximize the network capacity.

On join the stack uses the ADR command to set the channels, there are other posts on this else where on the forum that will expand on the details.

However looking at the source code (please post text as text, not as a screen shot, so much easier to copy & paste), the most recent version that could possibly be is a variant of LoRaMAC-node v4.4.1 which only supported LoRaWAN v1.0.2.

So it may help if you use v1.0.2 with regional parameters of LoRaWAN Regional Parameters v1.0.2rB which 4.4.1 used but YMMV

What is the device model and where did the firmware come from?

1 Like

Thank you. I’ll keep that in mind. I have solved the problem.

Please tell us what you did to solve the issue so others can learn from it.

1 Like

In fact, there is no real solution, but it can meet the requirements of my project.