After migration of my 1st test device to V3 stack I had the impression, that ADR does not work reliably as in V2. So I debugged this further. Am I wrong or do we have a problem here?
In the example the transmission conditions are very good, TX and RX SNR are above 8.
After OTAA join I send a 1st confirmed message and receive an ADR request. That is new in V3, but fine:
link_adr_req: dataRate=5 txPower=15 chMask=00ff chMaskCntl=0 nbTrans=1
That is confirmed from my device in next uplink (after further ADR requests as well):
link_adr_ans: powerOK=true dataRateOK=true channelMaskOK=true
Then the device sends some unconfirmed frames with DR5/SF7, all is fine. Before frame 6 I set manually the rate to SF10. With the downlink I receive immediately an ADR req, but only to change the power:
link_adr_req: dataRate=15 txPower=4 chMask=00ff chMaskCntl=0 nbTrans=1
The device continues to send uplinks and receives with frame 7 an ADR request again:
link_adr_req: dataRate=15 txPower=7 chMask=00ff chMaskCntl=0 nbTrans=1
Of course that request is confirmed in frame 8:
link_adr_ans: powerOK=true dataRateOK=true channelMaskOK=true
The rate stays at SF10, when I increase to SF11 or SF12 the behaviour is the same. After more than 100 unconfirmed uplinks there was no rate adjustment.
When I read the ADR parameter via TTN-CLI I see:
“network_server_address”: “eu1.cloud.thethings.network”,
“mac_settings”: {
},
“mac_state”: {
“current_parameters”: {
“adr_data_rate_index”: 5
},
“desired_parameters”: {
“adr_data_rate_index”: 5
},
“last_adr_change_f_cnt_up”: 8
}
So it seems that the network assumes the wrong currently used parameters.
When I overwrite the current_settings with:
ttn-lw-cli dev set ... --mac-state.current-parameters.adr-data-rate-index 2
the networks sends an expected ADR request:
link_adr_req: dataRate=5 txPower=0 chMask=00ff chMaskCntl=0 nbTrans=1
In my opinion the network should always update the current data rate parameter for ADR calculations from last received frame. Or how ADR is expected to work?
Kind regards,
Frank