THANKS @ernestopace now it’s clear. I’ll try it soon!
Hey Ernesto
thanks for these pointers! I’ve managed to activate the device via OTAA on my Arduino / Moteino - but am currently stuck at
Starting
Packet queued
181: EV_JOINING
I see that the device is activated, but the messages are not getting through. I’ve documented all here: https://github.com/lukastheiler/ttn_moteino#moteino-lmic-and-otaa-walkthrough-wip
do you have any idea why the messages are not getting through?
Thanks! Lukas
Hi Lukas,
My first thought was that your gateway might not handle messages TO your node correctly. However, I assume your RN2483 experiment uses the same gateway, and with that OTAA does seem to work.
Another possibility is that someone else has come up with DEEDDEEDDEED as DEVEUI. I think however this shouldn’t matter, because the DEVEUI should identify the node uniquely in combination with the APPEUI and/or the APPKEY. So this is probably not it.
I’m going to do some more testing with an Arduino and the RFM95W in the coming days.and see what I problems I run into then
Ernst
Hi Ernesto and @lukas,
I actually have the exact problem as Lukas. I registered the RFM95W + arudino pro mini succesfully via OTAA but it doesn’t send any messages (stuck at EV_JOINING). Furthermore the same setup does work if I use ABP. In addition I also have a working setup with OTAA and the RN2483. I am unsure what the problem is.
I just discovered that messages are actually being send, only after a (yet) inexpiable long time (approximately 15 min).
Starting
Packet queued
405: EV_JOINING
38257442: EV_JOINED
42179989: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
44133708: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
46215066: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
325: EV_JOINING
55224904: EV_JOINED
60192041: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
64292173: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
1 Like
Hi Kibet,
The successfull access through OTAA with LMIC was on a RaspBerryPi.
I have now done some testing with an Arduino and the LMIC software from @matthijs (https://github.com/matthijskooijman/arduino-lmic).
This works with the original AES implementation. I do see very varying JOIN times, in the order of 1-3 minutes, which I find very slow.
(BTW I also tested OTAA with the alternative AES implementations @matthijs presented; With those AES versions OTAA does not seem to work at all. I’m still looking at that.)
Ernst
1 Like
Any idea if your nodes have a good connection? The duty cycle for join requests is less than 0.1% (at least for EU). So I guess retries, and falling back to lower data rates, will indeed imply a lot of waiting.
Awesome, I’ve just tested it, and patience is the key 
Thanks a lot everyone!!
Yeah the node is 30 meters away from the gateway. With ABP it has always been a good connection, even at a distance of 1.5 km. Same goes for the RN2483 with OTAA, which instantly joins. Thus something different happens when I try the RFM95W with OTAA and this library. It could be that it fails to join and retries at a lower datarate, however this shouldn’t be necessary as the connection is good.
In the LoRaWAN 1.0 specification the duty cycle for joins in EU is indeed 0.1%. So if the initial joins fails for whatever reason, it will take a long time before it sends another attempt.
The LoRaWAN 1.0.1 update has relaxed this limitation to 1% join duty cycle in the first hour.
The reason for missing some join (accepts) is probably because the TTN backend can respond in the RX2 window and then uses data rate SF9. This is not compliant, and I just opened an issue for it. Before the join, the backend should respond with the LoRaWAN default values (=SF12 for RX2), and then it can change from the defaults by setting the new configuration parameters in the join accept message. After the join accept, it can then use the TTN values (=SF9 for RX2).
Also note that LMiC based end-node could miss a join accept because of incorrect RX slot timing, if your code does other stuff than just LMiC.
2 Likes
I guess you know, so just to be sure/for future readers: with ABP no join request is sent at all. Instead, all keys needed for the communication are already programmed into the node, hence no need for any join sequence.
1 Like
You are right, that was a poor choice of words. I changed it.
@Thomas
think you are (partially) right. When I changed the duty cycle form 0.1% to 1% the joining process was faster. However as expected, it still isn’t instantaneously. If the node retries to join at a lower data rate, is there anyway to see at which datarate it is trying or at which is successfully joined?
Furthemore changing RX2 window to SF9 or leaving it at SF12 (default) didn’t seem to make a difference.
LMIC.dn2Dr = SF9;
btw my code doesn’t do anything else then sending, it is pretty much the default example code.
I (partially) figured out why a node with the LMIC library, e.g. the RFM95W doesn’t join instantly when using OTAA. The standard code will first try to join the network at SF7 at certain frequency. However for some reason this will fail. After a failed attempt the node will try another frequency with the same datarate (SF7), this will fail again. Now the node will decrease the datarate to SF8 and again do two attempts which both will fail. Consequently the node decreases the datarate to SF9. This time the node will succeed at joining at the first attempt with this datarate.
After reading this comment of @kersing it seems explainable why SF7 and SF8 are not working (for me).
SF7 and SF8 should have a join reply in RX1 using the parameters of the request. SF9 + response is in RX2 at SF12
Based on this, reporting of others who also can’t join instantly with LMIC OTAA, and on tests with the Microchip RN2483, I conclude that the LMIC library doesn’t parse the received data in RX1 (correctly), please correct me if I am wrong, @matthijs @Thomas? As I will be on holidays for a while I can’t dig deeper into the code so I hope this information will help.
.
p.s. If you want a dirty fix for the instant join you can adjust the LMIC library to start with at SF9 by editing the following at line 686 in the LMIC library:
setDrJoin(DRCHG_SET, DR_SF7);
Change to:
setDrJoin(DRCHG_SET, DR_SF9);
1 Like
Keep in mind TTN does reply to join requests in RX2 at SF12, not SF9 as it previously did (that issue was fixed some time ago)
That is correct, that is also how my configuration is setup. However as I can’t join with SF7 and SF8, I suspect TTN does not send a reply join request in RX2 at SF12 but a reply in RX1 at SF7 and SF8 when using SF7 or SF8. Is this correct?
Correct, TTN sends join reply in RX1 if the gateway has available airtime and the request was SF7 or SF8.
I think I already joined a network on RX1@SF8 but I just tried and I am not able to reproduce it 
Maybe a timing issue, I will search it too
I am not sure if I understand : it means that TTN only answers in RX1 for SF7 and SF8, and only RX2 for SF9 to SF12 ? If so, why this limitation ? Save airtime ?
1 Like
Thanks!
A life saver, but still pretty unstable, 50/50 it works, but when it does it always connects in max 20 seconds.
I just found a bug in the LMIC library, where it uses an invalid channel for sending join requests 50% of the time (because the list of join channels was reduced from 6 to the 3 in the LoRaWAN standard, but two places didn’t get updated properly). This means that in 50% of the cases, the first (and possibly second and third) join request would not be transmitted correctly. Once the channel wraps around from 5 to 0, it would be valid again and joining could again work. I’m committing a fix now, I expect to push it to my git repo today.
Note that this problem is not related to the SF used, so this does not explain what @Kibet is reporting (but perhaps this was the problem he was seeing and the channel selection just accidentally lined up with the SF selection). I haven’t been able to test joining at SF7 yet, since I’m too far away from my gateway for that to work now.
3 Likes
Also, there was another bug where, if joining was started automatically and the join request needed retransmission, the queued data packet would also be retransmitted a number of times (until an ack is received, but no ack was actually requested). This could cause the first EV_TXCOMPLETE after an EV_JOINED to be delayed for quite some time (up to 8 attempts with increasing SF’s). I’ll also have this fixed today.
3 Likes