OTAA V3 Acting Weird

End Devices (Nodes) LMIC
1

Hello,

I have been working on a new device using MCCI LMIC library (latest version) and ESP32 TTGO T-Beam however I am having problems getting OTAA working with V3…

I tried it on V2 using separate app / dev EUI and it works just fine connecting to TTN V2 via my TTIG.
I tried it on Helium using another device registration and my Helium hotspot, it works fine.
I tried it on V3 with my V3 Pi based GW and it gets stuck in a join loop…

The above makes me think my code is ok and its something V3 specific.

Here we see the join activity in the console…
Screenshot 2021-04-05 at 17.33.38

Any advice would be greatly appreciated.

Best Regards,

Rob

2

FWIW, not running on an ESP32 but I’ve got a test device on my desk running LMIC 3.3 on OTAA v3 with no issues with join or uplinks or downlinks.

3

Sure, I get that it works I have other devices working in V3 with OTAA, it was more I have exhausted troubleshooting with this LMIC based device, and it has worked fine in V2 and other networks so I am confused what the problem is with getting it running with V3. Are there any common gotchas I should checkout?

4

Nothing springs to mind.

What does the serial console tell you?

You could turn on the debugging to see what the LMiC logging yields.

5

No luck I am afraid. It is very odd, I am only having problems with LMIC library, I have other devices which are on TTN V3 with OTAA working just fine, like I said it works fine with V2 and Helium, so I think the code is sufficient, maybe there is something with the timings on V3 which I am missing or some other problem?

BTW here is the raw output of the LMIC debug in the serial when the JOIN is attempted…

serial

and the gateway and the node…

gw

node

Don’t worry about exposing the keys its a temp test app / node.

I am guessing the “RX timeout” means it never got a packet back from the gateway, but it’s easily in range of 2 or 3 V3 gateways and a V2 gateway.

6

What region have you got setup on LMiC and on the gateway?

The Rx2 window isn’t using settings I’ve seen in normal use.

7

The gateway is using EU868 and is configured with the global_config.json file downloaded from the V3 console.

The LMIC project_config.h defines EU868 as the region and in the code it runs LMIC.dn2dr to set SF9 DR, however it is odd that in the serial output it seems to listen on SF12 for the downlink. I have tried using both EU868 SF9 and SF12 options in the device config in V3 console to no avail. It isn’t my code so maybe the dn2dr happens too late, I’ll move it to right after the LMIC.reset so we know it has happened prior to the join.

8

I think you should focus on RX1. The LMIC debug output suggests the receive window is opened a bit after 5 seconds, not at 5 seconds exactly. That might be late.

For joins RX2 should use SF12. Don’t adjust it. Only for ABP you need to adapt RX2 SF.

9

Ok I have done some adjustments with the LMIC_setClockError on this board and have it as near as I can get it to 5 seconds on the RX1 (SF7) and 6 seconds on the RX2 (SF12) after transmission…

joinfail

So Join TX happens at 39:57.695 and RX1 window opens at 40:02.679 aka just under 5 seconds later. Is it really that picky over ~20ms?

Yet still no JoinAccept :frowning:

Any other words of wisdom?

10

I read here - EV_JOIN_TXCOMPLETE: no JoinAccept with TTGO-LoRa 2.1.6 · Issue #666 · mcci-catena/arduino-lmic · GitHub that debug prints aren’t even a good idea when trying to solve timing issues as serial write is too slow, not sure how you are meant to tune it blind though :-\

11

Toggle a pin and use an oscilloscope. Or a cheap dongle on the PC, uncle Ali probably has dozens of options.

And indeed serial comms can cause huge timing issues depending on the controller and it’s capabilities. So your 20ms early might become 100ms late.

12

What I do not understand is this exact node AND code works with V2 and Helium networks, surely the timing is the same for V3?

13

I agree, it should work. I’ve been scratching my head regarding this as well.