OTAA/ABP node unable to join TTN

[Vicky_]

@Burgeh Thanks for replying me! Sure

i dont know why sometimes it will receive packet even my node is not activated and it did not show on TTN traffic.

[Burgeh]

@vicky_

I also have this issue with receiving random packets although my gateway does not have the push or pull ack

[Vicky_]

@burgeh ohh i see. hopefully someone can help us out. :')

[jmarcelino]

Hi @vicky_

That is the wrong node script to use for AS923, that one is only meant for EU868.

We’ll have a correct one up shortly.

[robert-hh]

@vicky_ once the gateway is up, you'll reeceive messages from any node in reach. That's intentional.

[Vicky_]

@jmarcelino I also tried US915 but nothing shows up on the console. Thank you so much!! I can't wait to see that. I am in the midst doing my project. Thanks a lot.

@robert-hh ohh i see. lesson learned. thanks for clarifying this for me :DD

@Burgeh I am not sure if you are in Asia region as well

[Burgeh]

@vicky_
I'm using the US servers, but I am running into pretty much the exact same thing, OTAA can't join and ABP joins and "sends" a packet, but I never receive it or get anymore information on it. My gateway updates on the TTN and has push/pull acks

@jmarcelino
Is the current code for USA working as well? I see it is quite a bit different the EU, besides the frequency/region difference. Same issue as stated above. Also would the join data rate be an issue? Some of the tutorials show it being there some not, it says it's optional, but when I add it, it has an error no matter what dr I put.

[robert-hh]

@burgeh Using a xxPy as nanogateway is kind of a luck with versions up to 1.17.0.b1, because it does not keep the timings well. The joins response has to be forwarded back to the node 5 s +/- 10ms after the request. At the moment, the time used for that is the rtc timer, which is not precise. You may be lucky with a specific device and moment. The reason is known and a fix will come soon (I hope).
For the same reason, downlink messages may also not arrive at the node.
At least, you should see in the gateway logs the requesst to the TTn server and the downlink messages, which will be sent, but unfortunately not at the right time.

[Burgeh]

@robert-hh
Thanks for the information! Is there a document stating this or has this been your expierence?

[robert-hh]

@burgeh The timing requirements are defined in the Lora Specs. The details about the implementation and its's behaviour are a result of my measurements and the code analysis. Nevertheless, the changed firmware works reliably, and Daniel is about to publish it some time.
The trail of my tests are here:
https://forum.pycom.io/topic/2728/lopy-and-nanogateway-example-inaccurate-timing-prevent-otaa-join
and here:
https://forum.pycom.io/topic/2676/abp-mode-and-frame-counters/18
You see, I spiraled a bit around the problem.