# OTAA Join fails most of the time (only on TTN) **URL:** \ **Category:** v2 Console\ **Created:** [November 9, 2020, 8:27am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197 "2020-11-09T08:27:16Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![montagny](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/montagny/32/35697_2.png) [@montagny](https://www.thethingsnetwork.org/forum/u/montagny)\ **Post date:** [November 9, 2020, 8:27am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/1 "2020-11-09T08:27:16Z")
Hi all, I’m using I-Nucleo-lrwan board from ST as a Device. I use AT\_Master application code also from ST. Everythings works fine with ABP. In OTAA, my Device is stuck waiting for the Join Accept. However, the Join Accept is sent by TTN and received by my GW. At some point, Join Accept is received and the activation process succeed. The problem occurs when the Join accept is sent with the 868,525 Mhz (see console below). ![InkedJOIN ACCEPT forum_LI](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/5/6/56b8773d6fa187919e69f57b5a6763821dd5d09c.jpeg) The process can take a long time (as long as TTL stop uses 868,525 Mhz) I made tests with ChirpStack and the Join Accept is accepted by my Device at the first Join Request. ChirpStack Join Accept were sent without using 868,525 Mhz which confirm the source of the problem. So my questions are : - Is there a way to prevent TTN from using this band? - Do you think the problem comes from my Device Stack configuration or from TTN ? Thanks a lot for your help. ---
**Author:** ![montagny](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/montagny/32/35697_2.png) [@montagny](https://www.thethingsnetwork.org/forum/u/montagny)\ **Post date:** [November 9, 2020, 9:51am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/2 "2020-11-09T09:51:30Z")
I set up a private TTN LoRaWAN Server (V3) [[https://thethingsstack.io/](https://thethingsstack.io/) ] to see the behavior with this server and everythings works because the Join Accept is sent without using 869,525 Mhz. From the log I then assume it uses RX1 : “rx1\_delay”: 5, “rx1\_frequency”: “868300000”, “rx2\_frequency”: “869525000”, “frequency\_plan\_id”: “EU\_863\_870\_TTN” The problems is therefore only with [thethingsnetwork.org](http://thethingsnetwork.org) but I really don’t see why… any hints ? Thanks ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [November 9, 2020, 11:18am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/3 "2020-11-09T11:18:14Z")
> [@montagny](#): > > The problems is therefore only with [thethingsnetwork.org](http://thethingsnetwork.org) but I really don’t see why… any hints ? A LoRaWAN compliant device for EU868 should accept a join reply in RX2 which uses 869.525 SF12 (for join accepts only in TTN). Does your device mistakenly assume RX2 should use SF9? ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [November 9, 2020, 4:43pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/4 "2020-11-09T16:43:54Z")
_temporarily_ modify you node code to generate serial debug output at each receive attempt so that you see the frequency and air settings it is trying to receive with. I say _temporarily_ as the act of generating debug output can in certain poorly implemented cases break the node’s ability to receive with proper timing. In that light, you should make sure that the lack of any response in the RX1 window isn’t generating debug output which prevents proper timing of the RX2 window. All of that said, the reported degree to which TTN seems to send join accepts in RX2 is a bit odd - it seems doubtful these are all cases of gateways being too busy to transmit in RX1. And while a well implemented node shouldn’t waste _much_ power on the unused RX1, it’s still suboptimal to be waiting for RX2, _especially_ where (unlike here) the join request was sent with a faster data rate, which would allow an RX1 to be sent faster as well. ---
**Author:** ![montagny](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/montagny/32/35697_2.png) [@montagny](https://www.thethingsnetwork.org/forum/u/montagny)\ **Post date:** [November 9, 2020, 9:51pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/5 "2020-11-09T21:51:24Z")
You got it !!! Thanks so much. I didn’t even have to dive in the Stack as I-Nucleo-Lrwan is a module and I could get these informations just by typing AT command. I unplugged the module to deal with bare AT command : - AT+RX2DR (data rate for RX2) returns 3 (SF9) on startup. Though the documentation says it should be SF12 … - AT+RX2DR=0 set the SF12 for RX2 and it now works. That point solved I went back to my “AT\_Master code” provided by ST and added Lora\_GetDataRateRxWind2(&DataRateRxWind2) during setup. I understand that you could assumed RX2 data Rate would be wrong. But how did you guessed it would be SF9 ? Thanks again. ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [November 9, 2020, 10:53pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/6 "2020-11-09T22:53:25Z")
> [@montagny](#): > > But how did you guessed it would be SF9 ? Because that is the setting required for downlinks when using ABP on TTN so it is often mistakenly set for OTAA as well. ---
**Author:** ![montagny](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/montagny/32/35697_2.png) [@montagny](https://www.thethingsnetwork.org/forum/u/montagny)\ **Post date:** [November 10, 2020, 9:39am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/7 "2020-11-10T09:39:38Z")
Perfectly clear, topic solved then. Thanks again. ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [November 10, 2020, 1:10pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/8 "2020-11-10T13:10:52Z")
> [@montagny](#): > > AT+RX2DR (data rate for RX2) returns 3 (SF9) on startup. That really shouldn’t govern joins, since join RX windows are different and fully independent of normal ones I’m not saying it doesn’t, but if it does, then the module firmware is sloppy and not really in keeping with the LoRaWAN specification. ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [November 10, 2020, 1:59pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/9 "2020-11-10T13:59:02Z")
> [@cslorabox](#): > > the module firmware is sloppy and not really in keeping with the LoRaWAN specification. Would you care to explain that one? I can’t recall seeing two sets of RX2 parameters for a device in the specification. I do know the specification allows the network to modify the parameters using MAC commands which is what TTN does for OTAA nodes in EU868. ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [November 11, 2020, 3:05pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/10 "2020-11-11T15:05:20Z")
> [@kersing](#): > > Would you care to explain that one? I can’t recall seeing two sets of RX2 parameters for a device in the specification. I do know the specification allows the network to modify the parameters using MAC commands which is what TTN does for OTAA nodes in EU868. Such modification would only apply to normal RX2, not join RX2. The whole point of a join is that it has to work without any knowledge of what you are joining - so it has to follow the standards. Customizations such as TTN-EU868’s SF9 RX2 apply only after joining - the whole issue here is that TTN properly sends join RX2 using the standard settings, while the module (at least in the way it is being used) is improperly applying customizations for normal RX2 to join RX2, when join RX2 must remain consistent with the standard and _not_ be customized. In practical terms, if someone is using TTN with OTAA then they shouldn’t be customizing RX2 via an AT command, because TTN itself will command the necessary customization. If someone were using ABP, then they might need to manually set it. Perhaps the issue comes from switching from ABP back to OTAA. But a _proper_ LoRaWAN stack would ignore customizations of normal RX2 when implementing join RX2, because the settings of join RX2 aren’t customizable since join needs to be network-agnostic. ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [November 11, 2020, 5:22pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/11 "2020-11-11T17:22:19Z")
> [@cslorabox](#): > > Such modification would only apply to normal RX2, not join RX2. Sorry but the standard does not specify such a thing as join RX2. I do agree the node stack and the backend stack should use the default regional parameters while joining, in fact I created the patch for V2 of the TTN stack to observe this behavior early 2016. ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [November 11, 2020, 5:23pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/12 "2020-11-11T17:23:49Z")
> [@kersing](#): > > Sorry but the standard does not specify such a thing as join RX2. In actuality the standard _does_ give the specifications for join RX2 - notice for example how unique and distinct time delays are stated. It allows allows for customizations of ordinary RX2, but these are obviously inapplicable to joins, both because there’s no language incorporating them, and for the more basic reason that **things simply wouldn’t work** if ordinary RX2 customizations applied to join RX2 - the _exact_ problem we’re seeing with a non-compliant firmware here. The very idea of OTAA joins only works if the air settings utilized for joining yet-unknown networks come _only_ from the applicable LoRaWAN regional parameters, _without_ any network-specific customizations. ---
**Author:** ![montagny](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/montagny/32/35697_2.png) [@montagny](https://www.thethingsnetwork.org/forum/u/montagny)\ **Post date:** [November 12, 2020, 8:32am UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/13 "2020-11-12T08:32:17Z")
I read the LoRaWAN specification. Here is the summury: APB : - No JOIN - Downlink :RX2 **must be** configured as the **Network Server** says in its documentation (ie : SF9BW125 for TTN ) OTAA : - JOIN : RX2 must be configured as the **LoRaWAN specification** says : SF12BW125 - Downlink : Then, during the OTAA procedure, information of the RX2 Data Rate is given by the Network Server, so there is no need to deal with that.(ie : TTN gives its SF9BW125 Data Rate for RX2). Whatever network you are using it should be properly configured. There are 2 different configurations for the delay RX2: one for JOIN and one for Downlink. There is only one configuration for the Data Rate RX2: common for JOIN and Downlink, but is changed (automatically) during OTAA process. > [@cslorabox](#): > > the module firmware is sloppy Yes, if we consider that the RX2 data Rate should be DR0 on startup as mention in LoRaWAN specification. It’s also specified on the documentation of my LoRaWAN module (I-Nucleo-LRWAN), but it’s apparently not the case. Hence my initial problem. ---
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [November 12, 2020, 5:19pm UTC](https://www.thethingsnetwork.org/forum/t/otaa-join-fails-most-of-the-time-only-on-ttn/41197/14 "2020-11-12T17:19:26Z")
> [@montagny](#): > > There is only one configuration for the Data Rate RX2: common for JOIN and Downlink, but is changed (automatically) during OTAA process. The really key question would be if the data rate setting for ordinary RX2 is changed by command from TTN _and not by AT command_ then if another join is done, is the correct Regional Parameter data rate for RX2 still utilized? If not, I’d argue that’s a bug. It might be tempting to think that one should globally reset the module to defaults before doing another join, but actually that would be a mistake, as a LoRaWAN device must remember used join nonces and not repeat them.