# Trouble getting stable OTAA on SF12 with a RN2483 module

**URL:** <https://www.thethingsnetwork.org/forum/t/trouble-getting-stable-otaa-on-sf12-with-a-rn2483-module/20330>\
**Category:** End Devices (Nodes)\
**Created:** [December 2, 2018, 10:19pm UTC](https://www.thethingsnetwork.org/forum/t/trouble-getting-stable-otaa-on-sf12-with-a-rn2483-module/20330 "2018-12-02T22:19:06Z")\
**Posts on this page:** 1\
**Showing post:** 4

<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:** [December 3, 2018, 7:40pm UTC](https://www.thethingsnetwork.org/forum/t/trouble-getting-stable-otaa-on-sf12-with-a-rn2483-module/20330/4 "2018-12-03T19:40:23Z")

</div>

For the other networks, you’re probably seeing RX1 for SF11 and SF12 then? Selecting RX1 or RX2 is up to the provider.

Thinking about it, I wonder why TTN prefers RX2 for an OTAA Join Request in SF11 and 12.

(It’s understandable for regular downlinks that are responses to uplinks using a high SF, as then, for RX2, TTN uses SF9 [with a higher output power](https://www.thethingsnetwork.org/forum/t/why-is-rx-slot-1-not-used/2656/3), where the lower SF9 limits the valuable airtime, and limits the time that the half-duplex gateways are “deaf” while transmitting a downlink. But for a Join Response, [it needs to use the LoRaWAN defaults anyhow](https://github.com/TheThingsNetwork/ttn/issues/155), for which RX2 does not seem to have much advantage over RX1, at least not for EU868? Or maybe the duty cycle is better for RX2?)

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/trouble-getting-stable-otaa-on-sf12-with-a-rn2483-module/20330)._