@miroslav-petrov Hi, yes adr need to be driven by gateway. In pycom documentation adr is parameter of lora constructor.
So what make you said it's not work ? As far i know some network compute adr setting only after a big sample of rx frame (for a nation wide operator in france they use approximatly one hundred of frame before send first downlink adr request to my device).
Does your gateway show if adr is set in your uplink frame ?
hi @Harish-kumar , we released here Lora-Mesh, that I thought it will help you.
Well, mesh-network over LoRa, has a specific protocol (Thread), and probably it's not implemented neither in Arduino, nor Multitech.
This would work if all 3 devices would be Lopys, the last one (gateway) would be registering itself to TTN as gateway, and forwarding data from the first Lora (sensor), thru the second one (the repeater, which does this automatically, being a Mesh node - router role).
@prawnhead It' less a bug in the firmware, than the way the device is handled by the user and some interference with the background database at Pycom, which keeps the assigned dev_uid. The dev_uid is stored in the device's flash and can be written to that using the updater tool. So you have three elements (flash, user, background system), which have to interact correctly, and there are few way to succeed and many ways to fail.
@livius I made a version in which you can control the join behaviour. It is just a handful of code lines. You'll find it here: https://github.com/robert-hh/pycom-micropython-sigfox/tree/otaa
I added an optional parameter to join.
Edit: While testing it came again to my mind to me that you can achieve the same thing with the standard SW:
step1: do an otaa join
step2: take the parameters from the web console, use them as ABP parameters and use ABP join then with just the single frequency in the list of channels. If you then save the state to nvs_ram, you do not have to call join again. The keys will be restored by nvs_restore(), which you must call anyhow to set the counters.
I have currently set up a nano gateway and several nodes (with LoPy) on the 868MHz using the EU868. From what I understand, AS923 is supposed to be used, but there are no strict regulations on the frequencies around 868MHz as of today. It would be better to work on the 923MHz frequency, thus I am currently wondering if anyone has gotten any success on 923MHz, or AS923.
When I tried to replicate the EU868 to the AS923, I couldn't get the TTN to display any values other than a random value to pop up only once. I was wondering if anyone with success or failures can share their experience.
@apiwize after the join worked, the TTN server will send a list of frequencies to use. The node will uses these in a random matter. Unfortunately the nanogateway can listen only to one of these three frequencies, meaning that you will miss 2 of 3 messages. That is not related to timing.
The best option then is to switch to abp mode, copying over from the TTN console the values for device address, network session key and app session key.
See the discussion at this thread about 10 days ago. https://forum.pycom.io/topic/2728/lopy-and-nanogateway-example-inaccurate-timing-prevent-otaa-join
I am having issue with activating using method otaa lopy with ttn gateway fot US915.
whats correct code i should use I searched a lot of topics over weekend and could not find correct code.
Same time using ttn node US915 with ttn gateway activation worked as shown.