OTAA with LMIC and arduino+dragino_shield doesn't work

Hi all,

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!

Many Thanks!


1 Like

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);

Hi jdelaet,

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?

Hi jdelaet,

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

TTN console

1 Like

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…)