OTAA/ABP node unable to join TTN



  • I have successfully connected the gateway to TTN, but the node isn't working.

    alt text

    OTAA:
    alt text

    ABP:
    alt text

    Is it because of this part of coding? Most of the coding follow the example at github. Except the dev_addr, nwk_swkey and app_swkey

    # remove all the non-default channels
    for i in range(3, 16):
        lora.remove_channel(i)
    
    # set the 3 default channels to the same frequency
    lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
    

    i am in Asia, using frequency 923MHz. i have try data rate 1, 2, 3 and 4.

    Can anyone help? thanks



  • @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.



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



  • @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.



  • @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.



  • @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



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



  • 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.



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



  • @vicky_

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



  • @Burgeh Thanks for replying me! Sure

    alt text

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



  • Could you provide a screenshot of your console connected to your gateway? Such as acknowledgements it is getting?

    e.g.
    Push Ack
    Pull Ack


Log in to reply
 

Pycom on Twitter