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

@paul-thornton Thanks, this worked! I figured out that the same addition 'region=LoRa.EU868' is needed at 4 locations in nanogateway.py: around line 169, 263, 355, and 378. I still have a problem with the downlink not getting to the node (without giving any error message). This may be a timing problem: Only in one instance, the TTN website indicated that the node confirmed receipt of the downlink. In all other cases, no such confirmation was received. Let me investigate that further first.

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

@suad_m5 As a LoPy (and hence a nano gateway) can only listen on one channel at a time, it is not LoRaWAN compliant, and only devices that are configured to use that single channel will be supported. It is not a generic gateway, it's just a tool to make quick tests without a real gateway around. This does not mean only LoPys can be used. If you can configure your device to only use the channel you configured on your nano gateway, it should work. This is however not possible on many devices.

@cooper Hi, do you remember which firmware version did you use?, I am having issues with downlinks that I did not have before (too many looses), thanks

@robert-hh said in TTN EU inconsistent to LoRAWan Spec: I just stumbled over an inconsistency between TTN EU and the LoRa WAN specification. For Downlink messages with DR < 4 TTN uses the RX2 window with DR=3 (SF9BW125) at 869,525 MHz and a power level of 27. This does deviate from the LoRa Spec in two aspects: a) I would expect that for a downlink message at first the RX1 window ist used, with the data rate and frequency matching the Uplink message. b) If the RX2 windows is used, DR0 = SF12BW125 should be used. That is what the PyCom devices expect for the RX2 window. The Pycom devices seem to implement the LoRAWAN spec. As a consequence, downlink messages for low data rates are lost. @bmarkus : How is the behavior in the loriot network? @robert-hh LORIOT EU868 settings are compliant to the LoRaWAN Regional Specification, see channel plan: [image: 1535355311417-918ed79a-4566-4454-a9be-ce3624589ddc-image.png]

@robert-hh They are next to each other - 1 meter I would say.

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

@rskoniec Hi, Only one of my Gateways out of two accepted join request, but still on the terminal I got the message as not yet joined. I saw the device eui displayes in Gateway join request message is APP eui which was false. I included device eui also in my code(Also I cant be very sure if it is what got my device to join but it worked for me). By the way I used sample code available on pycom docs for LoRaWAN OTAA. # create an OTAA authentication parameters device_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_key = binascii.unhexlify('FFFFFFFFFFFFFFFFF') # join a network using OTAA (Over the Air Activation) lora.join(activation=LoRa.OTAA, auth=(device_eui, app_eui, app_key), timeout=0) # wait until the module has joined the network while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...') # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) # make the socket blocking # (waits for the data to be sent and for the 2 receive windows to expire) s.setblocking(True)

@amket Thanks for the feedback, I'll look into adding some output such as "Connecting to Wifi network..." to make it more clear what is happening.

LoRaWAN is using a non-licensed shared frequency band. As long as you meet local regulations, e.g. in Europe max. 1% transmit duty cycle, do not exceed transmit power and bandwidth limits you are safe. It is not about LoRaWAN it is about local radio regulations. These rules are the same for single and 'normal' multi channel GW's.

I'm having a similar issue with mine - US, 915 mhz, on the dr=None allows the function to run but it never really joins.

@jmarcelino Hey, got it, thanks As you suggested I'll write a prog to quick send data and looks on my backend for frequencies of received packet ;-) Look like the faster way

@obladio I'm not sure if the Raspberry Pi code works in the current form, it's been a while since I tried it - almost as long as that code has been sitting there unchanged (1 1/2 years) but maybe it does. I do know downlinks are not supported at all in that code which is what TTN is really annoyed about - in the past gateways without downlinks were blocked from participating in TTN https://www.thethingsnetwork.org/forum/t/resolved-some-single-channel-gateways-stopped-working/6529 and https://www.thethingsnetwork.org/forum/t/the-future-of-single-channel-gateways/6590/72 I'd recommend using a single channel gateway which supports downlinks, such as the LoPy with nano-gateway code or some of of the suggestions on that 2nd thread I linked. If you want to use the Raspberry Pi code you have I guess you have to do some tests to understand if it's currently working.

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

@jmarcelino OK, i contact the owner of the gateway to see if it's possible to connect to that gateway. Thanks for all informations! we can close the post ;)

@jmarcelino Thanks, it works!

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

anyone reading this. please refer to: Problem joining TTN in Australia with OTAA using a LoPy 4 post on the LoPy section of the forum. The solution to this issue seems to be to restrict the channels of the AU915 regional settings.