I am trying to activate my arduino+dragino_shield v1.3 with OTAA procedure, but it doesn’t work as it should be.
Just to make things crystal clear, I uploaded the basic “ttn-otaa” example provided by the LMIC library. I payed attention in setting the DevEUI and AppEUI in LSB, whereas the AppKey in MSB, as advised in the code itself. The packets are sent to a close by Kerlink Wirnet Station.
The same node registered with ABP works just fine, and I can see packets back and forth the TTN back-end server with no problem at all.
After sending a join request, actually, I get the DevAddr and authentication keys (NwkSKey, AppSKey) from the server since I can see them in the TTN console, but I have feeling like my node can’t successfully use them to start sending my “Hello World” payload. In fact, after few minutes a new join request is sent and I get new keys without going any further in the data exchange process.
To give you the all picture, I post few screenshots of the console status at this time, as well as the response of the Arduino’s serial monitor:
End Node keeps sending join requests
End-node apparently activated (TTN shows all keys)
Arduino Serial Monitor (stuck in join procedure)
I hope that someone that has experienced the same problem can give me a piece of advice about how to fix it!
OTAA join might take up to 7 minutes with the libarary and sketches as found on the net.
There is a fix that you can add at the end of the statements where you init the node.
// got this fix from forum: https://www.thethingsnetwork.org/forum/t/over-the-air-activation-otaa-with-lmic/1921/36
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
thanks for the answer. I fixed the sketch by adding that line of code, however I am still struggling to have it working. In fact, I can establish a connection with server only once at the startup of both the arduino end-node and gateway. As soon as I remove power to the arduino board (or alternatively push the arduino’s reset button) I can’t activate my device any longer. I guess that at the end of a session I should be able to normally open a new one and get new keys for the end-node.
Look forward to get useful tips to overcome this issue!
I am not sure what you mean with “session”.
After joining, are you able to transmit messages? Let’s say every 5 minutes?
And where does it stop when you reset or repower?
Are you able to share you sketch with us?
I try to answer to each point you made:
for “session” I mean a properly established connection, which follows a join request coming from the end-node.
after a join accepted, I can send packets to server, and I see payloads on the device section of TTN console.
As soon as I unplug, and then plug USB power cable to the arduino board back again, I can’t activate my device thorugh OTAA any longer, unless I reboot the gateway.
ABP works just fine instead (even when I unplug/plug power to the Arduino) and a reboot of the gateway is not needed.
- the sketch is the otaa-ttn.ino example provided with library (I fixed the bug with the correction you told me - LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100) ).
Thanks a lot for the help, I look forward for your reply!
Is there any output on serial monitor when you reset or repower?
On the other hand I would start to look at logging in your gateway. There is not that I can help you there. I noticed that you opened a new topic for this already.
Here you can find the output from arduino serial monitor: as you can see it keeps sending a join request increasing the spreading factor at each new tentative. However, it goes on forever, until I get the event join failed. I have tried many times, the only way to make it works is rebooting the gateway.
Debug through serial monitor
I am having the same issue using the Dragino Pi Hat as a node. About 1 in 10 transmissions actually get passed the join request.
I will try adding the line of code mentioned and let you know if that works.
If “transmissions” refers to sending data, then unless it’s really only sending a few times a year, an OTAA node should not activate itself for each transmission; that’s just a waste of air time. If your node cannot save its state between transmissions then ABP might be a better fit, along with the decreased security of disabling the frame counter checks. But going into a low power mode that preserves the activation details is much preferred.
As for OTAA: many more debugging steps and background in OTAA ok, 12h later I get denied, reboot gateway –> OK again …!? (Yes, that’s a long topic…)