@roadfox Late response, but this doesn't look like a correct approach, as the join (and send) might have failed. Next time it will detect that it comes out of deepsleep and assume that it has joined, which it hasn't, so "if boot" must be replaced by something like "if successfully joined and not boot".

@jamjam In the last Kickstarter update they said end of Sept, but let's say 2 months.

@mcmxii Depends what you mean by "at the same time" but I'm pretty sure you can queue one message for transmission via LTE and the same via LoRa. (of course LoRa will be the limitation due to limited packet size and airtime regulatory restrictions) I'm also pretty sure - unless the team pulled off some miracle - that you cannot queue a message over LoRa and Sigfox at the same time because those two share the same chip.

Hi @RobTuDelft Thanks! Jiemde

@berni I would like to add my name to the list of people having the same problem with join issues. Incidentally I have another Node using an Arduino LoRaWan shield on the same nano gateway that joins successfully every time so I would tend to exclude noise issues with the Pycom OTAA / Nano Gateway example. It looks like software or firmware issues in the node to me. Hope this helps.

Just released 1.7.9.b3 which solves the ABP issue. Apologies for this bug, we'll investigate why it was not picked up by our automatic tests.

@jmarcelino hi , yes! Was about reading one ultrasonic sensor. Problem was fixed by using two other pins for sensor connecting. First was P11 and P12 and i did move to P21 and P22. I can not explain why...but seems work.

@jcaron The code is using ABP so there is no actual join procedure, it's just assigning keys

@jmarcelino Thank you for your answer!

@jmarcelino wow, thanks a lot for that find. explains the headaches I've been having :)

This is really an issue, as maximum payload size can be 250 bytes according to LoraWAN specification.

@jmarcelino Ok, I'll try with ABP as well and let you know. If this is the reason, then if i remove and re-set the channels after the join operation, wouldn't be "fixed"? UPDATE: With ABP all seem fine. I also tried again with OTAA. I noticed that in the github code the non-default channels were actually removed after join, whereas in my code this did not happen. So, when I added this code after join OTAA did work fine as well. Another remark: how do we know if we work with 3 or 8 channels? Many thanks @jmarcelino for your help!

@nojava4u if your gateway is connected, you should see in it's log lines like: [1194454.555] Pull ack [1194479.579] Push ack [1194479.579] Pull ack [1194504.623] Pull ack [1194529.418] Pull ack If you do not get that, then either your gateway cannot connect to the the TTN server (unlikely), or your gateway is not (properly) registered. For that, follow the instructions at: https://docs.pycom.io/chapter/tutorials/lora/lorawan-nano-gateway.html, starting with "Registering at TTN". Besides that, you will ever see messages being received by your gateway. I see them here too, at my nanogateway about once every 30 minutes. At my fully compliant gateway I'm receiving these every two minutes. Looking at the content, it looks like noise, even if I do not understand the statistics behind that. At a triggering preamble length of 40 bit and a data rate of 5670 bit/s, there should not be a random match more often than once every 3 years.

@dangerdan02 It's clear, someone invested a lot of money to develop Symphony Link. But if they license it to "large customers" without a fee, why not license it to e.g. Pycom for one dollar or two per LoPy? Think about the possibilities. And they could still sell their gateways.

@jellium This is not possible yet, please see the existing topic: https://forum.pycom.io/topic/1350/strategy-for-lorawan-with-deepsleep-2