# ADR - not what I expected **URL:** \ **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:** 4
**Author:** ![cultsdotelecomatgmai](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cultsdotelecomatgmai/32/35697_2.png) [@cultsdotelecomatgmai](https://www.thethingsnetwork.org/forum/u/cultsdotelecomatgmai)\ **Post date:** [November 6, 2017, 5:44pm UTC](https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470/4 "2017-11-06T17:44:29Z")
Thankyou @arjanvanb for your fast response. I think you have identified the problem. I have just re-read the LoRaWAN specification section 4.3.1.1 - Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl). I have watched a lot of traffic between TTN and the RisingHF. The RisingHF has never set the ADRACKReq bit. It appears that the RisingHF is not implementing the ADR\_ACK\_CNT and ADR\_ACK\_LIMIT mechanism. It appears that TTN is relying on receiving ADRACKReq on uplink to trigger the ADR system and is not forcing ADR. Typical interoperability issue! Thanks! Any suggestions to fix are welcome. --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/adr-not-what-i-expected/10470)._