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.)
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.
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.
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.
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:
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?
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 ?
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.
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.
Thanks for those bug corrections, did you pushed them already ?
Also I saw your comments on the license change, does it means that IBM will maintain LMIC or “just” allow a more permissive use of the stack ?
And I am not good in licenses, but does it also helps with the AES libraries you have tested ?
@Kibet, I just pushed quite some fixes to the lmic master branch, could you see if your join at SF7/SF8 persists? I’ve just tested this here, SF7 joins work for me. Two related remarks:
Perhaps your clock is inaccurate, but the error is negligable at the slower SF ratings? To check, add this to your sketch (somewhere during setup):
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.
If you set LMIC.dn2Dr before starting a join, I believe the RX2 window during the join will use that datarate. I do not think that TTN will use RX2 for join accepts (since the RX1 should always have equal or lower SF, so less airtime), but perhaps I’m mistaken and it does matter somehow.
Tested with the latest merged code from matthijs.
Without the above patch (which i also did at line 879), the join process is faster, but still takes around 7 minutes.
I also noticed that the join request is now only performed on a few channels, not all.
Still, when the join process succeeds, it is always right after the request on 868.1Mhz
As experienced with a previous test
(LMIC-1.51 fitting in Arduino Atmega 328)
With the above patch from @Kibet , it is immediately (tested now 3x in a row)
EDIT:
@matthijs, your right!, setting the clock speed adter LMIC_reset() solved the problem also!
No need to patch the LMIC code
