ADR Configuration

[t-huyeng]

Is there a way to speed up the data rate change?

I am investigating that sometimes it takes more than 30 minutes for the controller to switch to a higher data rate. I could not find a way to control this behaviour on the network server side. So maybe there is something in this project that can help me?

EDIT:
I just found this setting within chirpstack

Does anyone tried the lower two options?

[cyberman54]

You could disable ADR and set datarate in one combined rcommand. This will force the node to switch to the desired datarate immediately. Then, with a second rcommand, re-enable ADR. After a while the network will take over control of the datarate again, depending on RSSI.

[t-huyeng]

This is a good idea.
But when the nodes are moving, I do not always know when the last connection will occur. And I would like the nodes to change their DR quickly if the message does not go through. I may have to check how the general ARD method works for this.
So at the moment I sometimes have nodes that are sending at DR5 with RSSI -120, and if they move away from the gateway they take a really long time to update to DR 4 and so on. And this problem also doubles over time because if the node moves further away, even DR 4 is not enough and it takes even longer to finally send a successful message on DR1 or DR0.

Maybe I have to rethink the design of the application.

I was just hoping there was some hidden setting that could solve this directly ;). If you have another idea for moving nodes, let me know :)

Offtopic:
Do you know what MAXLORARETRY does? To me it sounds like it has something to do with the communication between the controller and the lora module, but other than the define in paxcounter.conf I cannot find it anywhere. Probably not helpful for my problem either.

[t-huyeng]

Well, I may have misunderstood ADR in the first place. Here (https://www.thethingsnetwork.org/forum/t/why-is-adr-only-relevant-for-nodes-at-fixed-positions/11742/4) it sounds like ADR should only be used for fixed nodes.

[cyberman54]

When it comes to roaming nodes, there a two aspects:

• How to join (pre ADR)
• While joined (ADR)

While joining, ADR is not relevant. The LMIC LoRaWAN implementation (used by paxcounter) is using an trial & error escalation mechanism to increase spread factor while joining is not successful.

Once joined, enabled ADR means the network remotely controls the SF of node, based on server side RSSI calculations. You can switch off ADR. For moving nodes this sounds reasonable, but may end up to nodes fixed on SF12, wasting battery power and airtime duty cycle.

Regarding LORAMAXRETRY in paxcounter: I am not yet sure, but this looks like a dead artifact of a former join control logic in a previous version of paxcounter. I'll verify this and then may delete it from code.

[t-huyeng]

As always thanks for your help!
I will try to set the default DR to 0 (SF12) and then activate ADR on the fly. I will have to check if this works for my use case, but it looks like a solution for now.