@Gijs Hello! that pin are not needed, infact my code is working, one hardware pin "p2" had some issue, it is constant 3.3V which means that the ploadPin are not toggled. The code awill hopefully be uploaded on Git!

@elizar Thank you for confirming this!

We could change the default sort order but I'm not sure this would affect existing users. I admit it throws me off too if I'm on the forum but not logged into my account. I'll see if our system admin can do some internal tests.

hank for your help but i tried hard but didn't succeed so for now i'll go with telnet connection. To do it with my desktop Pc i use my android smartphone with the usb tethear function

@jcaron Isn't this the opposite of what what stated here: Not completely the opposite, it's still more efficient to use a regulated 3.3V supply (low voltage forces the onboard regulator into bypass ECO mode) But it needs to be updated to reflect that 3.3V should be applied to the 5V/VIN pin. Is the Pysense/Pytrack sending power to the module via 5V Yes, all the various shields implementing deep sleep control the *py board's 5V rail

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

@jmarcelino Is this problem fixed?

Ugh. Not everyone is willing to have a github account.