# Issue with confirmed messages **URL:** \ **Category:** How to get started\ **Created:** [January 3, 2020, 5:25pm UTC](https://www.thethingsnetwork.org/forum/t/issue-with-confirmed-messages/33112 "2020-01-03T17:25:41Z")\ **Posts on this page:** 1\ **Showing post:** 20
**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:** [January 4, 2020, 12:19pm UTC](https://www.thethingsnetwork.org/forum/t/issue-with-confirmed-messages/33112/20 "2020-01-04T12:19:58Z")
Generic SF12 problems with some RN2483 firmware versions aside: **_every_ properly configured ABP device that uses ADR might run into the same issues for RX2, whenever just one ADR downlink has not been received?** A long read to explain what probably happened, and _might_ happen again: Your node has [ADR](https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate.html) enabled, so tells TTN that the network should control the device’s transmission settings (like channels, SF and power). As you were using SF12 (which is a _huge_ waste of air time), TTN will very soon have sent an ADR downlink, to command your device to use, say, SF8 instead. But somehow your device missed that ADR downlink and continued using the old settings. Now, [in EU868](https://github.com/TheThingsNetwork/ttn/issues/155), TTN uses specific settings for RX2: instead of the LoRaWAN default of SF12 (on 869.525 MHz), TTN uses SF9 (also on 869.525, but with a higher transmission power). When using OTAA in EU868, a device gets this network settings automatically in the Join Accept. But for ABP this needs to be programmed into the device, and some people forgot to make this change and kept wasting valuable shared airtime. To mitigate that, in September 2017 TTN added a fallback to use the default LoRaWAN RX2 settings (and enhance the ADR downlink to tell the node about the proper TTN RX2 settings) when it notices that a device has enabled ADR, but does not adjust its settings after an ADR downlink. This indeed [works for devices that are _not_ configured properly](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/25). However, for _properly_ configured ABP devices, TTN also (erroneously) assumes a device is using the LoRaWAN RX2 defaults when it somehow failed to receive an ADR downlink. And as of that point, TTN keeps using those defaults for all subsequent ADR downlinks, even though a _properly_ configured device will never receive RX2 on SF12. At this point the device is stuck at SF12 even though it has ADR enabled, while TTN keeps repeating the ADR downlinks on the wrong SF. Next, when manually switching the device to use SF7, TTN will switch from RX2 back to RX1, and all is fine again: the device will receive the pending ADR downlink, and TTN sees all is fine because the next uplink uses the expected settings. However, if the reception quality drops some time later (including when moving further away from the best gateway, or when a nearby gateway is taken offline), the device might notice that its uplinks are no longer received. (An ADR-enabled device expects to see some downlink activity [every now and then](https://www.thethingsnetwork.org/forum/t/adr-fair-use-and-lmic/10037/6).) This will make the node increase its SF, until it knows that its transmissions are received again. In bad conditions (including when the network is down for a long time), this means that at some point it _may_ end up at SF11 or SF12 again. If some time later the circumstances improve again, and TTN uses RX2 to send an ADR downlink to command the node to improve its settings, the whole problem _might_ start again. In October 2019, this [has been fixed for OTAA](https://github.com/TheThingsNetwork/ttn/issues/767), where TTN no longer assumes the LoRaWAN defaults **for devices that have joined after that fix**. But for ABP I think there’s always the risk that ADR will mess up? **In short: use OTAA.** If you really must use ABP, then disable ADR. (Note that using SF11 or SF12 [is not allowed then](https://www.thethingsnetwork.org/forum/t/can-i-register-an-abp-device-that-has-fixed-devaddr-nwkskey-and-appskey/3831/16).)   > [@kersing](#): > > When an uplink is SF12 TTN will **always** respond in RX2 (check the code if you don’t believe this). Even more so: browsing the latest v2.10.3 [test code](https://github.com/TheThingsNetwork/ttn/blob/v2.10.3/core/router/downlink_test.go#L469-L490), the [scoring code](https://github.com/TheThingsNetwork/ttn/blob/v2.10.3/core/router/downlink.go#L298-L321) (including the comment _“Impact on duty-cycle (in order to prefer RX2 for SF9BW125”_) and the [June 2016 commit title](https://github.com/TheThingsNetwork/ttn/commit/4f72564486dfccf70a65d69a44621e70abe89b8a) _“Prefer RX2 over RX1 for SF9+ [EU]”_ that introduced the changes that are still in the latest version today, I’m tempted to say that ever since June 2016 for EU868 TTN prefers RX2 for SF9 and up? I feel that doesn’t match the following from April 2017, unless the following statement assumes that in EU868 most uplinks use SF7-SF8 anyhow: > [@Gateway Latency](https://www.thethingsnetwork.org/forum/t/gateway-latency/6942/3): > > We try to avoid RX2 if possible. For RX1 we have 8 channels available, while RX2 is fixed on 1 channel and a very inefficient data rate. Maybe the test code fools me as the mock gateway has no other things to compare (such as how busy a channel is with receiving uplinks). I guess I need to do some real testing rather than browse the code… --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/issue-with-confirmed-messages/33112)._