@Widget Contrary to cellular networks, LoRaWAN networks usually don’t transmit much, if at all. Other than the odd join accept, confirmed frame ack, or downlink, all of which should be very rare, they don’t transmit anything, and definitely no beacons, advertisements or broadcasts. So it’s not possible to check if there’s a network around, just by listening, unless you plan to wait a very long time or get very lucky. But have you checked TTN’s coverage map? Also remember that radio waves don’t like obstacles. Find the closest active gateway(s) and check the path between them and you, taking into account terrain/elevation, buildings, vegetation, etc. There are tools that allow you to simulate all that. TTN being an open initiative, coverage varies widely. Some areas have lots of outdoor gateways in very good (high) locations, others may be the proverbial desert...

Bottom line here is that PyCom sells less than user friendly devices and provides poor documentation on use. I have been trying repeatedly to get my LoPy4 to OTAA join to no avail. I have scoured and tried just about every code sample on GitHub and nothing. Sadly, I did get my 32u4 feather to join with no issues whatsoever. This pisses me off because I dropped nearly $80 on PyCom (board, LoPy4, antenna, shipping) The forum is hardly readable. As are the docs. Just plain lousy.

@eric73 Thank you for your answer, I think it replies my question: It is possible however it depends on the network server allowed behavior.

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

@weingami Hi, I deployed hotfix and tested wifi, sigfox and lora connections. I correctly received the data. We need to test more things and there are a few more bugs, that we know and we're about to fix now.

@harish-kumar Is it a 'Class-A' device? RX window timing can be an issue.

@philwilkinson For readable data you could also use: data = "%.2f" % si.temperature() and use float(recv_data) for back-conversion.

@robert-hh To be more precise, it is in branch nanogateway at the URL: https://github.com/robert-hh/pycom-libraries/blob/master/examples/lorawan-nano-gateway/nanogateway.py

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.

@charly86 thank you, I will try it

@oorrab in application log I can see channels actually keep changing starting from 9039...

@robert-hh I got my FiPy nodes working with both The Things Network and Comcast MachineQ. To get it to work, I removed the code that modifies the channels before the connection https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node_US915.py#L23-L29

@bed Yes, approach it step by step. First check the RF connection witrh the simple examples, which are tricky too. Then try ABP join, since that does not need downlink messages. After that go for OTAA join. There is indeed a problem with DRl 0 in the official 1.17.3.b1 revision, see https://github.com/pycom/pycom-micropython-sigfox/commit/ae3a294c40026433dbdac3e08da788b2b4c4dfdb, but that should not affect here.

@ambropete import binascii import pycom import socket import time import ujson # put that into the import section from network import LoRa from machine import Pin, Timer echo = Pin(Pin.exp_board.G7, mode=Pin.IN) trigger = Pin(Pin.exp_board.G8, mode=Pin.OUT) # Colors off = 0x000000 red = 0xff0000 green = 0x00ff00 blue = 0x0000ff # Turn off hearbeat LED pycom.heartbeat(False) # Initialize LoRaWAN radio lora = LoRa(mode=LoRa.LORAWAN) # Set network keys app_key = binascii.unhexlify('11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 65'.replace(' ','')) app_eui = binascii.unhexlify('00 00 00 00 00 00 00 00'.replace(' ','')) # Join the network lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) pycom.rgbled(red) # Loop until joined while not lora.has_joined(): print('Not joined yet...') pycom.rgbled(off) time.sleep(0.1) pycom.rgbled(red) time.sleep(2) print('Joined') pycom.rgbled(blue) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) s.setblocking(True) trigger(0) chrono = Timer.Chrono() while True: chrono.reset() trigger(1) time.sleep_us(10) trigger(0) while echo() == 0: pass chrono.start() while echo() == 1: pass chrono.stop() distance = chrono.read_us() / 58.0 s.send(str(distance).encode()) pycom.rgbled(green) time.sleep(0.5) pycom.rgbled(blue) time.sleep(0.5) print("Distance {:.0f} cm".format(distance)) time.sleep(5)

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

Hello @jmarcelino 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. [image: 1519737904112-lopy-resized.png]