I updated my LoPy to the latest firmware and go the latest nano gateway sources from Pycom from github.
The issue is still there. Gateway is connected well but node is not able to connect to TNN. The join accept messages shown in the TTN console are received but PyMakr console still shows "Not joined".
Can you please fix this issue?
@bmarkus unfortunately that doesn't work either. I already tried this.
Also when I look at the output of lora.mac() it returns b'\xff\xff\xff\xff\xff\xff\xff\xff' so one could only expect the id to be FFFFFFFFFFFFFFFF.
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.
@mark915 There is definitely support for both, but your mileage may vary significantly depending on exactly what you want/need to do. The paint is still quite wet, and there are regular fixes, and a few outstanding issues here and there. All in all it works quite well, but there are sometimes a few surprises.
If you have a more precise description of what you want/need to do, you may be able to get more precise feedback on whether specific features are well supported or not. Including things like what expansion board you are planning to use, whether you need deep sleep, if you need to interface with external sensors (or use any of the provided sensors), whether you're using LoRa in "raw" or LoRaWAN mode, what BLE features you need (advertising, scanning, connecting...) would probably help a lot.
Yes I use a similar thing for my commercial product. But remember that nodes may miss (due to RF issues, power) the "key change" message and still use the old one.
What I did was to clone the existing device on the server backend but with the new keys. Then when a transmission arrives on the new device (which means the node has updated the keys) the old device is deleted.
If the next transmission still arrives on the old device it means the node has not picked it up so a new key change message is scheduled for retransmission - this is repeated until it's finally picked up.
@sjp770 SPI is a bus system. In a star configuration you can connect several slave devices to one master, as long as the (capacitive) load is not exceeded. But you need a CS for each device. If D/C is needed, you may be able to share it. If devices have active feedback pins like an Alarm pin, that has to be connected too to a separate I/O.