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 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, 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.
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.) 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, 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.)
Even more so: browsing the latest v2.10.3 test code, the scoring code (including the comment “Impact on duty-cycle (in order to prefer RX2 for SF9BW125”) and the June 2016 commit title “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:
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…