@mnovella Hello Thus, we can say that currently the LoPy4 does not support RejoinRequest natively, and that for it to happen the LoRa Module would have to be v1.1 compliant. Is this correct? LoPy AND LoraWAN operator have to be conform to 1.1 specification to use it. If yes, then given it's not natively supported, the responsibility for rejoining, etc. would fall on the application programmer (that is, me, or the code my LoPy has), just like you said that you start a join procedure after X time of not getting a downlink. Am I right? Yes, that's i do, after two week if no downlink as been recevied the device do a new OTA join request The 1.1 specs say that: "Once activated a device MAY periodically transmit a Rejoin-request message on top of its normal applicative traffic" It's very important when reading ISO/RFC/ETSI/official specification to be veray careful to the use of 'MUST',"MAY" and 'SHOULD" and there's indeed meaning. The low-level stack MUST support processing RejoinRequest but it's not mandatory that the application use it or is allowed to use it. That "MAY" part was the one that made me dubious if it was supported by the device or not... so I guess that even if/when Pycom supports LoraWAN 1.1 it will be up to Pycom to decide if/when to do the RejoinRequest if I'm not mistaken... I don't know what pycom will do when they will working to 1.1 port, but for me it's a "No" if i have had to vote, sending a new RejoinRequest is IMHO and application job and not a low-level stack/driver job. However, RejoinRequest is not send by a device, it's send by the network. When you do roaming (even in same country) you cant be in a specific area where some frequence channel is unusable (jammed), the network send to the device a RejoinRequest, the device perfom a new joinrequest and in the answer it receive a new channel list used in the area (frequency plan). If your device is static you don't have to think about this. My device perform new joinrequest as it's a moved device and can be for a long time out-of-network and when it come back is framecounter is far from when it leave the network and we don't receive anymore it's frame if we don't do a new joinrequest.

@jmarcelino thanks for the clear explanation. It would be really useful if you could put this small section of code on the Getting Started section of Pycom's LoPy documentation for those who are connecting to TTN; the most popular LoRa network in Australia/New Zealand region. I will try and post something in The Things Network Australia Community page too. If you would prefer, I can raise it through GitHub, but I suspect your ability to change the Pycom documentation is much quicker! thanks again for your help Jose. Also, I really enjoyed your talk on The Things Network conference

@brunos ! With s.setblocking (True) before s.send(), it's OK !!

I think you are right. I don't know how it was stuck in my mind that I could not change the join DR. Maybe by older topics of the forum. Thank you!

@aris This topic looks quite old, and I really do hope that you have found the solution by now, but if not: To hardcode SF12 when joining this works for us: when joining: self.lora.join(activation=LoRa.OTAA, auth=(self.dev_eui, self.app_eui, self.app_key), timeout=0, dr=0) After setting up the socket: self.s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0)

@jmarcelino Is there any example code that incorporates deepsleep and LoraWAN with these new functionalities to test it? thanks

@blackansible Try this modification in your nanogateway.py code: https://forum.pycom.io/post/8290

@berpast awesome I updated my project with your solution and it is working perfectly.

Finally I could get the node to join TTN! :D I needed to add a delay of 5 seconds before the node starts listening for the response of the Join Request with the command AT+JD: > AT+JD=5 OK > AT+JOIN Successfully joined network OK Also the fix for _send_down_link in my last post is no more needed as the frequency in the Event Data is now ok.

OK This seems to be a restriction introduced by LoRa Alliance. It seems a join request uses AlternateDatarate() to cycle over datarates 0-5 in way that makes 5 dominant. See below for the first cycles. Doesn't explain why I can't join a nano gateway with a SF=12, BW=125. 55555554 55555553 55555552 55555551 55555554 55555550 55555554 55555551 55555552 55555553 55555554 55555550 55555554 55555553 55555552 55555551 55555554 55555550 55555554 55555551 55555552

I know this is an old post, but I have similar issues and after some debugging this is what I found: The nanogateway gets the join request from the node using OTAA and it forwards it to TTN. TTN sees the join requests and replies back to the gateway: [image: 1502281017569-upload-048f98c6-4102-4923-a308-a7e4133b21d8.png] Adding some debugging I can display the data received from TTN and sent to the node using the _send_down_link function: def _send_down_link(self, data, tmst, datarate, frequency): self.lora.init(mode=LoRa.LORA, frequency=frequency, bandwidth=LoRa.BW_125KHZ, sf=self._dr_to_sf(datarate), preamble=8, coding_rate=LoRa.CODING_4_5, tx_iq=True) while time.ticks_us() < tmst: pass print(binascii.hexlify(data).upper()) self.lora_sock.send(data) Decoding the returned data shows that TTN is accepting the node to join: https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=20B6330995FA5AD1601C019F596C711FE11FF096E1C4915F94F183BEA903746F23 Assuming hex-encoded packet 20B6330995FA5AD1601C019F596C711FE11FF096E1C4915F94F183BEA903746F23 Message Type = Join Accept AppNonce = 0933B6 NetID = 5AFA95 DevAddr = 011C60D1 MIC = 03746F23 However, the node keeps trying and is unable to join or takes several attempts until it is successful. I hope this helps solving this issue...