# ADR and gateway distance **URL:** \ **Category:** TTN Network and Services\ **Created:** [June 26, 2020, 2:02pm UTC](https://www.thethingsnetwork.org/forum/t/adr-and-gateway-distance/38112 "2020-06-26T14:02:55Z")\ **Posts on this page:** 1\ **Showing post:** 5
**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:** [June 27, 2020, 8:04am UTC](https://www.thethingsnetwork.org/forum/t/adr-and-gateway-distance/38112/5 "2020-06-27T08:04:07Z")
> [@LloydXmas](#): > > Do nodes using ADR _start_ with a high data rate and then send recurring packets with lower and lower data rates? You may see this for OTAA. Like [EU868 LMIC](https://github.com/mcci-catena/arduino-lmic/blob/v3.2.0/src/lmic/lmic_eu_like.c#L167) first tries the default channels at some initial data rate that is configured in the device. This may very well be the fastest data rate available (SF7BW125). When all default channels fail, LMIC will decrease the data rate one step, and try again. This is fine for an OTAA Join, as for such the node knows it should always receive a downlink for each uplink, so it knows when things failed. But for ADR, it may take as many as 96 uplinks to detect that no downlink was received. According to [the 1.0.2 specifications](https://lora-alliance.org/sites/default/files/2018-05/lorawan1_0_2-20161012_1398_1.pdf#page=16): > **4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)** > > […] > > If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR\_ACK\_CNT counter. After ADR\_ACK\_LIMIT uplinks (ADR\_ACK\_CNT \>= ADR\_ACK\_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (`ADRACKReq`). The network is required to respond with a downlink frame within the next ADR\_ACK\_DELAY frames, any received downlink frame following an uplink frame resets the ADR\_ACK\_CNT counter. In LoRaWAN 1.0.x, for most (if not all) regions, ADR\_ACK\_LIMIT is 64, and ADR\_ACK\_DELAY is 32. (In LoRaWAN 1.1, it’s a configuration.) When a device detects it has missed an expected downlink then at worst it already had 96 uplinks not being received, or at best simply only missed the ADR-triggered downlink. It may want an aggressive strategy to ensure it might actually still be in range, or change its settings to get in range again. But according the the same specifications it seems that a certified device should only decrease its data rate by one step and wait another 32 uplinks: > If no reply is received within the next ADR\_ACK\_DELAY uplinks (i.e., after a total of ADR\_ACK\_LIMIT + ADR\_ACK\_DELAY), the end-device may try to regain connectivity by switching to the next lower data rate that provides a longer radio range. The end-device will further lower its data rate step by step every time ADR\_ACK\_DELAY is reached. The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range. Aside: the above is also why ADR-enabled devices that have trouble receiving downlinks will eventually end up at DR0. --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/adr-and-gateway-distance/38112)._