# V3 ADR always resets to SF7 **URL:** \ **Category:** TTN V2 to V3 Upgrade\ **Created:** [April 2, 2021, 3:53pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302 "2021-04-02T15:53:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nichtvongestern](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/nichtvongestern/32/35697_2.png) [@nichtvongestern](https://www.thethingsnetwork.org/forum/u/nichtvongestern)\ **Post date:** [April 2, 2021, 3:53pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/1 "2021-04-02T15:53:59Z")
Dear TTN Community, I have started to migrate my devices to the v3 stack. There were no problems at first and everything works as expected. About my nodes, I use the IMST IM881A for LoRaWAN. (MAC 1.0.2) However, I have problems with the nodes that have a high distance to the gateways.The SF factor is slowly increased by the node. With v2, some stayed at SF9. Others at SF10-12. Now the SF factor is increased again normally. But whenever the first packets arrive with e.g. SF10, it is reduced again to SF7 by ADR command. And then I get huge data gaps. Every time something arrives again, but the ADR command resets the DR to 5. Why does the v3 stack do that? The Network Server must see on the counter that the last 100 packets or more have not arrived. Why does it always set to SF7 again? Does anyone have an idea what the problem is and how I can change it? ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [April 2, 2021, 4:27pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/2 "2021-04-02T16:27:27Z")
> [@nichtvongestern](#): > > The Network Server must see on the counter that the last 100 packets or more have not arrived. It doesn’t look at any loss of uplinks, it just works off the RSSI & SNR. Can you give us some figures on the signal whilst I look for the link to the code used. ---
**Author:** ![wolfp](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/wolfp/32/45304_2.png) [@wolfp](https://www.thethingsnetwork.org/forum/u/wolfp)\ **Post date:** [April 2, 2021, 4:41pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/3 "2021-04-02T16:41:26Z")
How many packets do you send per hour and do you use confirmed uplinks ? ---
**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\ **Post date:** [April 2, 2021, 4:47pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/4 "2021-04-02T16:47:26Z")
Here’s how it’s calculated: > ---
**Author:** ![wolfp](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/wolfp/32/45304_2.png) [@wolfp](https://www.thethingsnetwork.org/forum/u/wolfp)\ **Post date:** [April 2, 2021, 5:04pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/5 "2021-04-02T17:04:43Z")
The value in line 63 of the code doesn’t seem to be plausible. But imho this is not the reason for the reduction to SF7. ---
**Author:** ![nichtvongestern](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/nichtvongestern/32/35697_2.png) [@nichtvongestern](https://www.thethingsnetwork.org/forum/u/nichtvongestern)\ **Post date:** [April 3, 2021, 2:28pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/6 "2021-04-03T14:28:00Z")
I use unconfirmed uplinks. 5-10 per hour. I can’t say for sure if this case was really reduced to SF7, because I didn’t record the console. But I have seen it before, although the receiving values were not so good. The ADR from the v3-stack is unfortunately bad in my experience and should be adjusted.I measure meteorological data and these should be more or less complete. Found another case where it is the same. > [@ADR standard activated in V3 applications?](https://www.thethingsnetwork.org/forum/t/adr-standard-activated-in-v3-applications/44698/3): > > Whenever I change DR to 2 (SF10) an “Link ADR request” is enqueued afterwards and SF changes to SF 7 after 1-2 datasets with SF10. This “Link ADR request” has “name”: “ns.mac.link\_adr.request”, “data”: { “[type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq](http://type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq)”, “data\_rate\_index”: 5, “tx\_power\_index”: 5,… This is how it looks then, on 03/28 I turned off my TTIG. Then I waited, but ADR comes to no satisfactory settings. Almost everything is lost ```auto datetime , id ,f_cnt, gateway, RSSI, SNR, SF, (2021, 4, 1, 3, 9, 54), 13831, 671, 'packetbroker', -117.0, -15.2, 10, (2021, 3, 30, 23, 21, 44), 13831, 501, 'packetbroker', -118.0, -13.2, 11, (2021, 3, 30, 23, 14, 44), 13831, 500, 'ifm-imst', -120.0, -12.75, 11, (2021, 3, 30, 23, 7, 44), 13831, 499, 'ifm-imst', -121.0, -13.5, 11, (2021, 3, 30, 22, 53, 43), 13831, 497, 'ifm-imst', -119.0, -13.75, 10, (2021, 3, 30, 22, 39, 43), 13831, 495, 'ifm-imst', -120.0, -14.25, 10, (2021, 3, 30, 22, 32, 44), 13831, 494, 'ifm-imst', -121.0, -14.0, 10, (2021, 3, 30, 22, 25, 43), 13831, 493, 'packetbroker', -117.0, -14.5, 10, (2021, 3, 30, 21, 30, 43), 13831, 485, 'packetbroker', -118.0, -12.0, 10, (2021, 3, 30, 21, 3, 23), 13831, 481, 'ifm-imst', -120.0, -16.0, 10, (2021, 3, 30, 20, 49, 43), 13831, 479, 'packetbroker', -117.0, -14.8, 10, (2021, 3, 30, 20, 29, 23), 13831, 476, 'ifm-imst', -118.0, -14.0, 10, (2021, 3, 30, 19, 42, 43), 13831, 469, 'packetbroker', -117.0, -11.5, 10, (2021, 3, 30, 19, 28, 43), 13831, 467, 'packetbroker', -118.0, -12.0, 10, (2021, 3, 29, 18, 2, 43), 13831, 306, 'packetbroker', -111.0, -12.2, 9, (2021, 3, 29, 17, 47, 23), 13831, 304, 'packetbroker', -111.0, -13.5, 9, (2021, 3, 29, 17, 41, 23), 13831, 303, 'packetbroker' -116.0, -11.0, 9, (2021, 3, 28, 20, 15, 13), 13831, 174, 'packetbroker', -72.0, 7.75, 7, (2021, 3, 28, 20, 4, 33), 13831, 173, 'packetbroker', -75.0, 9.5, 7, ``` This was not the case with TTN-v2. ADR adapted more slowly, but actually about 50% of the packets arrived after successful adaptation. Can I use ttn-lw-cli to add my own values? ```auto ttn-lw-cli end-devices set --mac-state.desired-parameters.adr-data-rate-index ttn-lw-cli end-devices set --mac-state.desired-parameters.adr-tx-power-index ttn-lw-cli end-devices set --mac-state.desired-parameters.adr-nb-trans ``` ---
**Author:** ![E\_T](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/e_t/32/35697_2.png) [@E\_T](https://www.thethingsnetwork.org/forum/u/E_T)\ **Post date:** [May 26, 2021, 3:16pm UTC](https://www.thethingsnetwork.org/forum/t/v3-adr-always-resets-to-sf7/46302/7 "2021-05-26T15:16:14Z")
I can confirm the problem! In my case the Sensor had no connection to a gateway, after ADR\_ACK\_LIMIT= 64 + ADR\_ACK\_DEIAY = 32 attempts (EU868) the Cubecell changing the broadcasting scheme from SF7 to SF8. Then three packets are received! SNR 10.8, 10.5, 10.8 RSSI -130, -132, -130, After that, no more packets are received! So what happend there? Going back to SF7? E\_T Update: After ca. 130 (possible) packets two packets arrived with SF9 SNR -11.8, -13.5 RSSI -132, -134 Update 2 Her the new values: Now we are on SF 11 but the signal performance deteriorates (weather-related?) | Nr | Name | Date/Time | SF | SNR | RSSI | Date/Time | | --- | --- | --- | --- | --- | --- | --- | | 835 | mk-cc19-hdc1080 | 2021-05-23T08:39:31.507900Z | 7 | -6,5 | -126 | 23.5.21 8:38 | | 836 | mk-cc19-hdc1080 | 2021-05-23T08:39:42.789093Z | 7 | -6,2 | -125 | 23.5.21 8:38 | | 843 | mk-cc19-hdc1080 | 2021-05-23T08:49:43.612780Z | 7 | -6,5 | -126 | 23.5.21 8:49 | | 850 | mk-cc19-hdc1080 | 2021-05-23T08:59:44.892476Z | 7 | -4,5 | -124 | 23.5.21 8:59 | | 874 | mk-cc19-hdc1080 | 2021-05-23T09:39:47.142414Z | 7 | -9 | -129 | 23.5.21 9:39 | | 886 | mk-cc19-hdc1080 | 2021-05-23T10:09:49.530985Z | 7 | -6,8 | -128 | 23.5.21 10:09 | | 1281 | mk-cc19-hdc1080 | 2021-05-24T01:30:32.330426Z | 8 | -10,5 | -130 | 24.5.21 1:29 | | 1312 | mk-cc19-hdc1080 | 2021-05-24T02:30:40.984603Z | 8 | -12 | -132 | 24.5.21 2:29 | | 1327 | mk-cc19-hdc1080 | 2021-05-24T03:00:45.013562Z | 8 | -11,5 | -132 | 24.5.21 3:00 | | 1432 | mk-cc19-hdc1080 | 2021-05-24T06:41:12.477539Z | 9 | -12 | -133 | 24.5.21 6:40 | | 2044 | mk-cc19-hdc1080 | 2021-05-25T01:32:16.505670Z | 8 | -12 | -131 | 25.5.21 1:31 | | 2158 | mk-cc19-hdc1080 | 2021-05-25T04:31:38.337588Z | 9 | -12,5 | -134 | 25.5.21 4:31 | | 2176 | mk-cc19-hdc1080 | 2021-05-25T05:01:42.483625Z | 9 | -12,2 | -132 | 25.5.21 5:01 | | 2852 | mk-cc19-hdc1080 | 2021-05-25T21:12:35.833133Z | 8 | -10,8 | -130 | 25.5.21 21:12 | | 2862 | mk-cc19-hdc1080 | 2021-05-25T21:22:37.370869Z | 8 | -10,5 | -132 | 25.5.21 21:22 | | 2872 | mk-cc19-hdc1080 | 2021-05-25T21:32:38.274668Z | 8 | -10,8 | -130 | 25.5.21 21:32 | | 3708 | mk-cc19-hdc1080 | 2021-05-26T19:04:17.008659Z | 9 | -11,8 | -132 | 26.5.21 19:03 | | 3715 | mk-cc19-hdc1080 | 2021-05-26T19:14:17.384513Z | 9 | -13,5 | -134 | 26.5.21 19:13 | | 3819 | mk-cc19-hdc1080 | 2021-05-26T22:04:35.778340Z | 9 | -13,2 | -133 | 26.5.21 22:03 | | 3842 | mk-cc19-hdc1080 | 2021-05-26T22:34:40.840229Z | 9 | -13,2 | -133 | 26.5.21 22:34 | | 3880 | mk-cc19-hdc1080 | 2021-05-26T23:34:45.760106Z | 9 | -13 | -131 | 26.5.21 23:34 | | 3912 | mk-cc19-hdc1080 | 2021-05-27T00:24:51.674120Z | 10 | -14,2 | -134 | 27.5.21 0:24 | | 3921 | mk-cc19-hdc1080 | 2021-05-27T00:34:53.802190Z | 11 | -15,8 | -135 | 27.5.21 0:34 |