# ADR - not what I expected

**URL:** <https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470>\
**Category:** LMIC\
**Created:** [November 6, 2017, 4:30pm UTC](https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470 "2017-11-06T16:30:27Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [November 6, 2017, 5:13pm UTC](https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470/2 "2017-11-06T17:13:25Z")

</div>

> [@cultsdotelecomatgmai](#):
>
> the IMST end-device is triggering the ADR by sending an uplink message with the FCtrl.ADRACKReq bit set to 1

What SF was it using when doing that, and did TTN tell this specific node to make changes too? (SF9 to SF7 like the others you mentioned?)

If no changes are needed, or if no downlinks were available on which TTN could piggy-back the ADR settings, then the node won’t know if its uplinks even reached a gateway. In that case it will set `ADRACKReq` after a while (after 64 messages for LoRaWAN 1.0). So, this might be as expected.

That said, even without sending such `ADRACKReq`, a node that is on SF12 should be told to increase its data rate (assuming the link quality indicates it _can_ do better): looking at the code I think TTN [should force a downlink then](https://www.thethingsnetwork.org/forum/t/adr-is-not-working-nucleo-raspberry-italy/10078/3). If you have access to a gateway: don’t you see any ADR downlinks in the gateway traffic (and the trace info such downlink) in TTN Console? Maybe the node is just not receiving the downlinks? And does it have the `ADR` bit set for _all_ uplinks?

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470)._
