Too many LinkADRReq MAC commands

ChirpStack Network Server
1

I have a (class A) device using the MCCI Arduino LMIC library, and a RAK2245 concentrator gateway using the lora_pktfwd packet forwarder and a chirpstack gateway-bridge, networks server (3.9.0) and application server (3.10.0). The device profile is using otaa and LoraWAN specification 1.0.3 (which is supported by the MCCI Arduino LMIC library). Everything works great, except that there are a lot of LinkADRReq MAC commands being sent from the network server to the device after a successful uplink message from the device. After many of the uplink messages, there is a succession of 3 LinkADRReq downlink messages being sent by the network server to the device. I am trying to conserve power on my device and put it asleep in between the 5 minute uplink send cycle. So 3 additional uplink MAC responses from the device after a regular uplink message significantly adds to the power consumption.

Each LinkADRReq contains the same content it seems, except that the first specifies txPower: 0, the second txPower: 5 and the third txPower: 10. Is this necessary/correct? Or do I have something badly configured/implemented? How can I reduce the number of LinkADRReq commands?

I posted the sequence of lorawan frames on pastebin: https://pastebin.com/XEZDscg6

2

It is the ADR algorithm tuning your device to the highest datarate and the lowest tx power :slight_smile:

1 Like
3

Ok, but should it really do it with 3 messages in a row, and do that with many uplink messages? It doesn’t just happen with the first uplink message. It keeps happening (not on every message but on a large % of them). Because of it the device is spending almost the double amount of time sending uplink messages, cutting drastically into the battery life of the device and the airtime. Should LoraWAN really be that chatty?

And also, the datarate doesn’t seem to change, it is 0 in every LinkADRReq message. So it doesn’t look it’s tuning that. Just the txpower changes from 0 to 5 to 10 in that order. And the devices are right next to each other on my desk.

4

Are you sure you have configured your Service Profile correctly? For US915 min DR would be: 0, max DR: 3.

ChirpStack does set the DR directly to the most optimized value, it does not for the TX Power value. The reason for this is that some devices do not accept all TX Power values (which I believe is against the specs). Therefore ChirpStack decreases the TX Power by one step at a time.

I am trying to conserve power on my device and put it asleep in between the 5 minute uplink send cycle. So 3 additional uplink MAC responses from the device after a regular uplink message significantly adds to the power consumption.

Note that the initial ADR tuning only should happen when the device joins. After that, ChirpStack might tune the data-rate and tx power but only when it can improve the data-rate or decrease the tx power.

1 Like
5

It looks like that was maybe partially the problem. I had the min and max DR in the service profile on the default values (0 and 0). I changed it now to 0 and 3. But still I am getting LinkADRReq messages at least once after every uplink message. See the attached messages. I am totally expecting that there is an issue on my configuration in either chirpstack or the device, but it is hard to find understandable documentation on this stuff.

https://pastebin.com/uhjuM2Yj

6

It looks like your issue is that the device reverts to a lower data-rate itself:

            "txInfo": {
                "frequency": 902700000,
                "modulation": "LORA",
                "loRaModulationInfo": {
                    "bandwidth": 125,
                    "spreadingFactor": 7,
                    "codeRate": "4/5",
                    "polarizationInversion": false
                }
            }

After that, the NS receives:

            "txInfo": {
                "frequency": 902300000,
                "modulation": "LORA",
                "loRaModulationInfo": {
                    "bandwidth": 125,
                    "spreadingFactor": 8,
                    "codeRate": "4/5",
                    "polarizationInversion": false
                }
            }

The NS never requested the device to change to spreadingFactor: 8, so it keeps repeating LinkADRReq loop.

1 Like
7

Cool, thanks. I will look at the device side and report back. Just an additional question, you said the max DR for US915 should be 3? That is SF7/125kHz right? Is there a reason why it can’t be DR4 (SF8/500kHz)? Is that restricted in the regional parameters? Or is that allowed as well? I am going to deal with devices that are pretty close, so a higher datarate might be good if it is allowed.

8

The difference between DR0-3 and DR4 is that the first ones can be used over multiple channels, while DR4 is single channel only (when you have a 8 channel gateway).

1 Like
9

Is this list correct: https://docs.exploratory.engineering/lora/dr_sf/
If it is (and I think I see CS indeed correspond to it), it looks like DR4 is much faster than DR0-3 because they are 125kHz and SF4 is 500kHz. Is that true? So won’t the airtime be much shorter on DR4?