ADR min/max DR value

We have currently a small LoRaWAN EU868 deployment of about 25 devices in field and some of them have very variable signal values (devices are static). We have ADR (default algorithm) enabled and It works correctly, but in my opinion the changes are very agressive: the devices starts with DR0 and after the first few messages the server changes to DR5 only on one step.

We have no problem with most of the devices, but some of them lost connection after several hours of DR change. We would like to adjust the max DR on those devices and the only way we see is using service profiles. The service profiles are asigned to applications but currently we have all our devices in one application and we don’t know how to move devices from one application to other.

On the other way we have installed a testing Chirpstack v4 server and the service profile section is no longer available, so we don’t know how is supposed to be done the DR interval adjustment in the future. Would it be a good idea to move de max-min DR values to device profiles?

Also just as an appreciation it would be nice to have a “less agressive” ADR algorithm, for example changing one DR at a time every X messages.

Best regards,

Several Questions in here, i’ll try to answer them in order of appearance.

  1. Moving devices from one app to another: currently not possible and doing it over postgresql is error prone and might leave your devices connected, but not usable. The recommended way would be to remove the device, add it to the new app and let it (re-)join.
  2. Can’t comment on the development of v4. Maybe open an Issue there directly.
  3. You could implement that as a custom algorithm. The issue with moving slowly up: it will eat the Duty cycle rather quick.
    Understanding ADR | DEVELOPER PORTAL
    LoRa best practices device management joining and rejoining | DEVELOPER PORTAL
    3.1 If possible, deploy a gateway near the devices.

Hi, you could increase the installation margin in the network server configuration file.

1 Like

Increasing the installation margin could be a possibility but I am not sure how much and how it will affect other devices. Currently the installation margin value is 10 (default one), what value would you recommend?

Here I attach the SNR and RSSI graphs of one of those problematic devices. As you can see the SNR value varies a lot, the device is a water meter and is located underground (not very deep).

Best regards,

@HofIoT good point!

Increasing the margin might move other devices to a lower DR, decreasing it might get more devices in the same situation where some lose “connectivity” under variable conditions.

Increasing is a rather safe.

Sorry to revive an old thread, but just wondering if you ever sorted this out? We’re having a similar issue with devices being brought up too to a much higher data rate rather aggressively (straight from DR0 to DR4 - US915) and then losing connectivity as a result. I suspect that increasing the installation margin this, but i’m not sure what value to put in there. 15? 20? Have you guys experimented with this at all?

I have now set my service profile with a max of DR0, and they’re starting to step down to the lowest spread factor, and once that’s done i’m going to try tweaking the install margin and increasing the max to DR3 and see what happens.

Unfortunately the end devices are in a location that i dont have easy access to, so if they do completely drop out, i have to wait for them to heal before i can try again so hoping for some input here.

Thanks!

You likely want to go from DR0 to 3 on US915. DR4 is something different (check the spec) and not a continuation.

Sorry, yes your’e correct, i meant DR3 (SF7), not DR4 (SF8BW500). Regardless, i was finding the ADR a little too aggressive and it would up it to SF7 where it would begin to drop out. I set my install margin to 20 and it seems to be much more tame now, but i wonder if that’s a little too high… curious what other people are using, and/or if there’s a science to getting the correct number.

Thanks!

I finally enabled confirmation mode on problematic devices, they were only a few of them. This has solved the problem for the moment.