ADR Not working for ABP

[TiSteen]

Hey there, love your work, it's a great project.

I am experiencing an issue though, I can't seemt to get the ADR to work. I've set all the paramaters to activate ADR, in the network, profile, and device. But with all my devices the SF stays at 12. I even tried to set it to a static SF, but even then it stayed at 12. Been stuck with this issue for a while and could really use your help.

Thanks in advance.

[gotthardp]

Hello. What is your Network and Profile config, please?

[TiSteen]

Thanks for the quick reply! Here are the settings you requested.

[gotthardp]

You have very weird channel setting. RX2 Freq of 125 MHz? Only one channel (set in network-channels)? I suspect the ADR command may be actually sent, but never delivered because the downlinks may not work at all in your setup.

[TiSteen]

I have set the RX2 Freq to 868.525 and am using 8 channels now. But even after 20 messages I see no change in the DR/SF. Here are the channel settings I used. I am using the RN2483 with the latest firmware.

[gotthardp]

The channels settings is an interval of indexes. To use 8 channels you should use 0-7 instead of 8.

[TiSteen]

Hey there, I have set the channels to 0-7. Waited the 20 uplinks, but the SF still doesn't change. I have also added an extra device, which does not use the RN2483, but with the same results. Do you have any ideas?

[gotthardp]

Not sure what is wrong. What does the debug.log say, please?

[TiSteen]

2018-02-14 12:15:06.715 [debug] <0.285.0>@lorawan_db_guard:trim_rxframes:74 Expired rxframes from [<<"0019834A">>,<<"0019BEEE">>,<<"001AB9E1">>,<<"001E27D6">>,<<"001E9E4D">>,<<"06000768">>,<<"06100BF0">>,<<"07000439">>,<<"57F9F68D">>]

2018-02-14 12:18:22.868 [debug] <0.10469.0>@lorawan_handler:uplink:138 ADRACKReq confirmed

2018-02-14 12:18:51.787 [debug] <0.10476.0>@lorawan_mac_commands:calculate_adr:291 DataRate 57F9F68D: average snr 8 -10.0 = 18, dr 0 -> step 6

2018-02-14 12:18:51.787 [debug] <0.10476.0>@lorawan_mac_commands:calculate_adr:301 Power 57F9F68D: average rssi -69, power 0 -> up by 7

2018-02-14 12:18:51.787 [debug] <0.10476.0>@lorawan_mac_commands:send_adr:325 LinkADRReq {7,5,[{0,2}]}

2018-02-14 12:18:51.788 [debug] <0.10476.0>@lorawan_mac_commands:build_fopts:73 57F9F68D <- [{link_adr_req,5,7,7,0,0}]

2018-02-14 12:22:03.949 [debug] <0.10563.0>@lorawan_mac_commands:handle_fopts:16 57F9F68D -> [{link_adr_ans,0,1,1}]

2018-02-14 12:22:03.950 [warning] <0.10563.0> node 57F9F68D {adr_req_failed,{0,1,1}}

2018-02-14 12:35:27.615 [debug] <0.10859.0>@lorawan_mac_commands:build_fopts:73 0019834A <- [dev_status_req]

2018-02-14 12:35:57.797 [debug] <0.10866.0>@lorawan_mac_commands:handle_fopts:16 0019834A -> [{dev_status_ans,255,9}]

2018-02-14 12:35:57.797 [debug] <0.10866.0>@lorawan_mac_commands:handle_status:218 DevStatus: battery 255, margin: 9 (max -15.0)

It started giving these messages. I haven't had these ADR messgages before, it just started suddenly, after about 300 uplinks. This is also the only device which is requesting a new Data Rate. All my other devices are still stuck at SF12.

Something seems to be wrong with my data rate and channel mask, but I can't figure out what. Do you have any ideas for this issue and for the other devices which wonn't request for a new data rate. Regards

Edit: I have just discovered that when I configure a device for ABP the ADR will not be active( no ADR requests in the log file whatsoever). But when the device is configured for OTAA I get the log as seen in this comment. It still took about 50 uplinks before ADR requests were made.

Edit 2: Fixed the issue, by changing the min and max power settings in the network tab to Max -2 and Max -10 I was able to get the ADR working. But only with OTAA devices, I still don't get any ADR messages when usig ABP, this is something I would really like to solve.

[romansoft]

I'm using RN2903. I observed ADR kicks in at frame count 50 (not 20), but it shows warning adr_req_failed {1,1,0}. The new DR takes effect though, despite the warning.

excerpt from /var/log/lorawan-server/debug.log : 2018-02-25 01:18:37.075 [info] <0.18894.0> device 0004A30B001A4394 {join,<<"26D2B5A0">>} 2018-02-25 01:18:37.076 [debug] <0.18894.0>@lorawan_mac:encode_accept:392 Join-Accept <<"26D2B5A0">>, netid <<0,0,1>>, cflist [], rx1droff 0, rx2dr 8, appkey <<"5D7F70D331650BCF3C290C513C3A5A2E">>, appnce <<"F191E8">> 2018-02-25 01:18:37.076 [debug] <0.18894.0>@lorawan_handler:join:107 Join-Accept in RX1: {rxq,903.7,<<"SF10BW125">>,<<"4/5">>,undefined,284293908,-45,12.2} 2018-02-25 01:18:40.283 [warning] <0.277.0> gateway 00800000A000156E {downlinks_lost,1} 2018-02-25 01:18:49.649 [debug] <0.18895.0>@lorawan_mac_commands:store_actual_adr:134 ADR indicator set to 1 2018-02-25 01:18:49.650 [debug] <0.18895.0>@lorawan_mac_commands:build_fopts:73 26D2B5A0 <- [dev_status_req] 2018-02-25 01:19:14.942 [debug] <0.18896.0>@lorawan_mac_commands:handle_fopts:16 26D2B5A0 -> [{dev_status_ans,255,7}] 2018-02-25 01:19:14.942 [debug] <0.18896.0>@lorawan_mac_commands:handle_status:218 DevStatus: battery 255, margin: 7 (max -15.0) 2018-02-25 01:31:53.112 [debug] <0.19567.0>@lorawan_mac_commands:calculate_adr:291 DataRate 26D2B5A0: average snr 9 -5.0 = 14, dr 0 -> step 4 2018-02-25 01:31:53.113 [debug] <0.19567.0>@lorawan_mac_commands:calculate_adr:301 Power 26D2B5A0: average rssi -48, power 5 -> up by 12 2018-02-25 01:31:53.113 [debug] <0.19567.0>@lorawan_mac_commands:send_adr:325 LinkADRReq {10,3,[{0,7}]} 2018-02-25 01:31:53.113 [debug] <0.19567.0>@lorawan_mac_commands:build_fopts:73 26D2B5A0 <- [{link_adr_req,3,10,0,7,0},{link_adr_req,3,10,255,0,0}] 2018-02-25 01:31:55.700 [debug] <0.19568.0>@lorawan_mac_commands:handle_fopts:16 26D2B5A0 -> [{link_adr_ans,1,1,0},{link_adr_ans,1,1,1}] 2018-02-25 01:31:55.700 [debug] <0.19568.0>@lorawan_mac_commands:store_actual_adr:138 DataRate 26D2B5A0 switched to dr 3 2018-02-25 01:31:55.700 [warning] <0.19568.0> node 26D2B5A0 {adr_req_failed,{1,1,0}} 2018-02-25 01:31:55.701 [debug] <0.19568.0>@lorawan_mac_commands:build_fopts:73 26D2B5A0 <- [dev_status_req] 2018-02-25 01:32:40.914 [debug] <0.19609.0>@lorawan_mac_commands:handle_fopts:16 26D2B5A0 -> [{dev_status_ans,255,7}] 2018-02-25 01:32:40.914 [debug] <0.19609.0>@lorawan_mac_commands:handle_status:218 DevStatus: battery 255, margin: 7 (max -7.5) 2018-02-25 01:40:29.528 [warning] <0.19881.0> node 26D2B5A0 {uplinks_missed,1}

[romansoft]

I'm puzzled as to why this warning {adr_req_failed,{1,1,0}} is showing as power and data_rate ADR failures? The link_adr_ans from device is [{link_adr_ans,1,1,0},{link_adr_ans,1,1,1}]. According to LoRaWAN spec, the responses of Bit=1 indicate correct operation. Could it be the interpretation is incorrectly inverted in NS stack?

[gotthardp]

You are absolutely right: the failure flags were inverted. I just fixed in the 'master' branch.

This however does not explain the error. I admit the LinkAdrReq for US bands is not tested enough as I am based in Europe. Also, the specification is not very clear in some respects. I'd really appreciate if you can help me debugging this. You set channels {0,7}. This resulted into two LinkAdrReq commands: one with ChMask=0, ChMaskCntl=7 (all 125kHz OFF, 64-71 OFF) and another with ChMask=255, ChMaskCntl=0 (0-7 ON). But the first command was rejected.

Not sure why is that (debug logs in your device could explain that), but I think you might have set the channels wrong. By setting 0-7 only you disabled all downlink channels (which could be the reason why your device refuses that). Try 0-7,64 instead and let me know if it's any better.

[romansoft]

Thanks for quick reply. setting channels 0-7,64 would enable the first 128kHz uplink channels and the first 500kHz uplink channel (only one). I don't believe LinkAdrReq commands apply to downlink channels. Unfortunately, RN2903 firmware is a black box and there is little diagnostics exposed. But, I will try this setting later.

As to ChMask=0, ChMaskCntl=7 (all 125kHz OFF, 64-71 OFF) command, the spec is not very clear on the bit definition, but my interpretation is that since the meaning of ChMaskCntl=7 is channel OFF, the polarity of 1 for ChMask activates (or disables in this case) that feature. So, by this interpretation, ChMask would need to be 0xFFFF, not 0. Perhaps the device is rejecting a command that has no effect...?

[gotthardp]

The standard says "A bit in the ChMask field set to 1 means that the corresponding channel can be used for uplink transmissions if this channel allows the data rate currently used by the end-device. A bit set to 0 means the corresponding channels should be avoided." so it should be 0, I believe.

Also, for some other firmware in the US band we also had to set the downlink channel. It's at least worth trying, because this was my only idea on what could be wrong.

[romansoft]

After careful re-read of the spec, I agree with your interpretation of bit polarity. But, I think I know now why the device returns the error status. According to the spec, the status of 0 for Channel Mask ACK is returned for the following reasons: "The channel mask sent enables a yet undefined channel or the channel mask required all channels to be disabled. The command was discarded and the end device state was not changed." Setting ChMask=0, ChMaskCntl=7 does disable all channels: ChMaskCntl=7 disables all 128kHz channels (meaning 0-63) and ChMask=0 disables all 500kHz channels (64-71). This is exactly one of the two reasons for rejecting the command mandated by the spec.

I think the way to avoid this status error is to set at least one 500kHz channel when using ChMaskCntl=7. I tried the experiment you suggested to set channel 64, and it indeed cleared the error status. The log file shows that this results in ChMask=1, ChMaskCntl=7 which is what we want. So, the mystery solved!

I have some suggestions for improving ADR scheme, but I will describe it in the next post.

2018-02-25 23:04:31.214 [debug] <0.5266.1>@lorawan_mac_commands:calculate_adr:291 DataRate 26D2B5A0: average snr 9 -5.0 = 14, dr 0 -> step 4 2018-02-25 23:04:31.215 [debug] <0.5266.1>@lorawan_mac_commands:send_adr:325 LinkADRReq {5,3,[{0,7},{64,64}]} 2018-02-25 23:04:31.215 [debug] <0.5266.1>@lorawan_mac_commands:build_fopts:73 26D2B5A0 <- [{link_adr_req,3,5,1,7,0},{link_adr_req,3,5,255,0,0}] 2018-02-25 23:04:33.808 [debug] <0.5271.1>@lorawan_mac_commands:handle_fopts:16 26D2B5A0 -> [{link_adr_ans,1,1,1},{link_adr_ans,1,1,1}] 2018-02-25 23:04:33.808 [debug] <0.5271.1>@lorawan_mac_commands:store_actual_adr:138 DataRate 26D2B5A0 switched to dr 3 2018-02-25 23:04:33.808 [debug] <0.5271.1>@lorawan_mac_commands:handle_adr:153 LinkADRReq 26D2B5A0 succeeded (enforcement only)

[gotthardp]

Thanks for trying it. The standard doesn't say (at least I didn't find it) what shall happen if one doesn't specify any mask. Shall the channels be enabled, disabled or unchanged? I thought that masks shall cover all channels to not leave any undefined, but perhaps I was wrong. Not sure.

[romansoft]

The channel mask covers different number of channels according to channel mask control value: For channel mask control equal to 6 and 7, channel mask covers channels 64-71. The other channels (0-63) are either all ON or OFF, respectively. For channel mask control 0 to 4, channel mask controls channels according to the respective bit fields.

[romansoft]

I also confirm ADR does not seem to work in ABP mode, as TiSteen reported.

[gotthardp]

So you are getting ADR failed for ABP devices? Could you share with me a log?

Re the table; But what setting do the channels 64-71 have when only mask 0-4 is used?

[romansoft]

ADR never activates in APB mode. Nothing shows up in the log.

For ChMaskCntl=7, if you set ChMask bit 0 to 1, it activates channel 64. If set to 0, it deactivates it. And, correspondingly for channels 65-71. You can't have undefined bits since you are writing the whole word. Not sure if this is what you are asking about.

[gotthardp]

If ADR does not activate, then it's insufficiently configured. The code is identical, so it cannot be not working for ABP and working for OTAA.

My issue is related to the situation when only ChMaskCntl=0 is used. What is the value of channges 65-71 in this case?

[romansoft]

Ah, I see. In ABP, ADR settings have to be explicitly set individually for each "Activated" device, and it's not inherited from the device profile.

When ChMaskCntl=0, only channels 0-15 can be programmed with ChMask. The rest of channels keep their existing value until changed through appropriate ChMaskCntl and ChMask combination.

[gotthardp]

The ADR is (shall be) still inherited from the Profile. However, the (Commissioned) Device settings are not used for ABP.

Yeah, that was my assumption too. In such case it's not possible to disable all channels 65-71, because setting the mask to 0 produces an error and not including the ChMaskCntl=7 will maintain the previous settings.

[TiSteen]

According to the device page my ADR is ON. And in my payload the ADR bit is active. But I still don't recieve ADR messages in my log file.

Were you able to solve the issue romansoft?

[gotthardp]

@TiSteen, your issue seems to be different. Your ADR is working, but failing in device. I reviewed your settings again and saw in your Network config "Min Power" set to "Max-20". Please note that in europe only "Max-14" is allowed. Could you change that, please and try again.

[romansoft]

@gotthardp, if the ADR settings from device profile are being used for both OTAA and ABP devices, then something is not correct with ADR over ABP. I'm using the same device profile for both OTAA and ABP devices (so the same ADR settings). The log file shows that ADR setting is recognized to be initialized on the device, but the ADR change never takes place (withing 75 or so tested frames), as it does with OTAA device. I'd like to add that the ABP device is the same physical device as OTAA device with the same firmware, just with ABP setting, instead of OTAA, and different credentials, so I don't believe there is anything wrong with the device itself.

2018-02-26 06:08:44.111 [debug] <0.10797.1>@lorawan_mac:ensure_rxwin:325 <<"1200610F">> RXWindow initialized 2018-02-26 06:08:44.111 [debug] <0.10797.1>@lorawan_mac:ensure_adr:315 <<"1200610F">> ADR initialized 2018-02-26 06:08:44.111 [error] <0.10797.1>@lorawan_handler:idle:85 Nothing to retransmit for <<18,0,97,15>> 2018-02-26 06:08:59.982 [debug] <0.10833.1>@lorawan_mac_commands:store_actual_adr:134 ADR indicator set to 1 2018-02-26 06:08:59.982 [debug] <0.10833.1>@lorawan_mac_commands:build_fopts:73 1200610F <- [dev_status_req] 2018-02-26 06:09:05.989 [debug] <0.10835.1>@lorawan_mac_commands:handle_fopts:16 1200610F -> [{dev_status_ans,255,6}] 2018-02-26 06:09:05.990 [debug] <0.10835.1>@lorawan_mac_commands:handle_status:218 DevStatus: battery 255, margin: 6 (max -15.0)

[gotthardp]

Could you please share your Profile settings with me?

[romansoft]

[TiSteen]

I already changed my power settings, that's how I managed to get the OTAA to work. I have the same situation as romansoft. I use the same Profile, which works on OTAA but not on ABP. I have also tested with different devices, all with the same result.

[gotthardp]

Oops. You were right, I was wrong. There was a bug, which I just fixed. It really prevented ADR to be executed for ABP devices.

[romansoft]

Thanks Petr!

As I play with ADR, I realized the ADR settings scope works differently than I originally assumed. Perhaps this is how it should be, but I'll bring this up in case it's not, and to get your feedback on my understanding of the behavior.

There are three places in the dashboard where ADR can be configured: 1) Networks, 2) Profiles, 3) Activated. My initial assumption was that the precedence of scope is that 3) has the highest precedence and 1) has the lowest. My rationale is that Network defines the overall ADR boundaries for all connected devices, while Profiles determines ADR boundaries for a particular device's capabilities. Once the device connects it inherits settings from Profile and creates set point accordingly. So the setting values for 3) should be a subset of 2) which should be a subset of 1).

From experimentation, I can see that such precedence is not the case. When I set up 1) differently from 2), 1) took precedence over 2) in affecting LinkADRReq command (unexpected behavior). However, when I later manually changed ADR settings in 3), this one affected LinkADRReq command (expected behavior). With such precedence between 1) and 2), how would you set different ADR settings between devices with different capabilities (eg. with different number of channels)?

Could you please clarify the precedence of ADR settings?

[gotthardp]

It's not really a precedence. 1) Network defines the implicit settings-- what is effective after reset/join without any ADR commands. 2) Profile defines the group config-- what any of the devices shall use. If the actual (implicit) Node setting doesn't correspond to the requested, an ADR is sent. 3) Node defines the actual requested settings, i.e. what the user or the algorithm requested to set.

Some description is also here: https://github.com/gotthardp/lorawan-server/blob/master/doc/Devices.md#adaptive-data-rate-adr

The documentation is not perfect and bugs are possible, but this is the overall concept.

[Neuromystix]

Hi Petr,

Simple question related to this. I'm running version 0.5.2 in RPI and checked that the server only send LinkADRReq after 50 uplinks, as stated here. I'm testing OTAA and at least the DR change, not tested power. Do you changed that value it in 0.5.3? I think it could be a nice feature to configure that value also.

Best regard Nelson Pinto

[gotthardp]

Hello, @Neuromystix. The manual changes can be done anytime and in this case the LinkADRReq is sent immediately, But in case of the auto-ajust ADR it still takes 50 frames to make a change. This value has been used all the time. Would it be OK to have it configurable in the server.config file, or you really need a web-configurable value? The more config parameters the more confusing it will be.

[Neuromystix]

Hi @gotthardp. The main purpose of it is to test how ADR is working on some microcontrollers. That's why 50 frames are a loooong time. So it could be in server.config file, don´t need nothing web configurable - as you said, there are already too many thing to config ;)

Here, we are using Pycom LoPy platform, which are great devices and have a good support. However, ADR was a thing that we can't get working fine and we suppose that's something firmware related.

Best regards Nelson Pinto

[gotthardp]

@Neuromystix, I just made a "hidden" config parameter for you: {frames_before_adr, 50}. Add this line to your .config file and change the number to whatever number you need.

[Neuromystix]

@gotthardp Thanks =) That's great and can be very useful for whoever is working with microcontrollers ;)

Best regards Nelson Pinto

[gotthardp]

I believe the issue was resolved, so I am closing this. If it keeps failing, feel free to open a new issue.