# Pycom fipy connects ok with ABP but not OTAA

**URL:** <https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426>\
**Category:** Pycom\
**Created:** [April 14, 2018, 7:26am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426 "2018-04-14T07:26:17Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 14, 2018, 7:26am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/1 "2018-04-14T07:26:18Z")

</div>

I have a Things Gateway setup here with a ThingsNode connecting and talking to it using ABP with no issue.

However, my poor little Pycom fipy will only connect with ABP. If I try the example below using OTAA I get not a peep on the TTN gateway and the fipy just loops printing “Not joined yet”.

Any ideas on how I can debug, see what is happening?

```
from network import LoRa
import time
import binascii

lora = LoRa(mode=LoRa.LORAWAN)

app_eui = binascii.unhexlify('<app eui key here>')
app_key = binascii.unhexlify('<app key here>')

lora.join(activation=LoRa.OTAA, auth=(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 joined yet...')

print('Network joined!')
```

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [April 14, 2018, 10:23am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/2 "2018-04-14T10:23:02Z")

</div>

> [@mikcatta](#):
>
> my poor little Pycom fipy will only connect with ABP

As with ABP a node does not really “connect” or join (but gets all its secrets during programming, so is simply always ready to send data): so with ABP you can actually send data, and see that data in the gateway traffic (and application data) in TTN Console? Or did you not try sending actual data?

> [@mikcatta](#):
>
> using OTAA I get not a peep on the TTN gateway

Again, just to be sure: “not a peep” means that TTN Console shows absolutely nothing at all for OTAA? (Not even an OTAA Join Request, let alone a Join Accept?)

---

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 14, 2018, 11:21am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/3 "2018-04-14T11:21:08Z")

</div>

Hi Arjan

First of all, apologises if my terminology is not quite correct, still getting use to LoraWan technologises.

With ABP I can see the test bytes come through the TTN console and they get passed to my HTTP handler with no issues.

With OTAA, it never gets past the “while not lora.has\_joined():” loop and there is nothing at all in the console. I have tried setting the timeout to 30000 and it just times out after 30 seconds.

Just to confirm my TTN gateway and settings are correct, I can see the registration and first data packet from my TTN node with no issues.

Just to confirm the code is correct, I have explicitly set the Lora module to use 868mhz as per “lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)”. Apart from that, the code is per my example.

Regards  
Mike

---

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 14, 2018, 11:31am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/4 "2018-04-14T11:31:07Z")

</div>

Just noticed that there is a “join request” in the Gateway log, but it doesn’t get acknowledged. Something at least.

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [April 14, 2018, 11:38am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/5 "2018-04-14T11:38:23Z")

</div>

If there’s only an OTAA Join Request, but no OTAA Join Accept, then one of the following applies:

- TTN has rejected the request due to invalid keys
- or, TTN has elected another gateway to send the Join Accept (only applies if another gateway received the Join Request as well)
- or, TTN has not found a gateway that is suitable to send the Join Accept at all (might apply if TTN thinks you’re using a single-channel test gateway that does not support downlinks).

If there is also a Join Accept, then somehow the node did not receive that.

See screenshots at [Things Uno not joining anymore - #5 by arjanvanb](https://www.thethingsnetwork.org/forum/t/things-uno-not-joining-anymore/12772/5) for what’s expected. Also, the “Trace” part in the gateway’s traffic in TTN Console might give you some clues.

> [@mikcatta](#):
>
> Just to confirm my TTN gateway and settings are correct, I can see the registration and first data packet from my TTN node with no issues.

So that TTN Node is using OTAA as well? Then TTN knows the gateway supports downlinks. You might still need to reverse the keys when using different hardware. (I don’t know if the LoPy expects MSB or LSB for its keys.)

> [@mikcatta](#):
>
> still getting use to LoraWan technologises

LoRaWAN 😉

---

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 14, 2018, 10:11pm UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/6 "2018-04-14T22:11:47Z")

</div>

Got there in the end, it seems that the device EUI was wrong.

I think the Pycom documentation is possibly at fault, in that when you add the node, you need to know the value assigned to the device EUI and use that value rather than the seemingly random value assigned by the TTN console.

For reference, I included the following piece of code to the example OTAA.

> print(‘DeviceEui Hex Payload ’ + ‘’.join(’{:02x}'.format(x) for x in lora.mac()))

PS I never did find out how to “trace” in the gateway traffic.Sounds kinda useful.

---

<div class="post-metadata">

**Author:** ![asavvin](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/asavvin/32/36808_2.png) [@asavvin](https://www.thethingsnetwork.org/forum/u/asavvin)\
**Post date:** [April 28, 2018, 11:55pm UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/7 "2018-04-28T23:55:58Z")

</div>

Hi

I used Pycom Lopy with latest firmware. TTN gateway with original firmware.

from network import LoRa  
import socket  
import time  
import struct  
import binascii

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915)

dev\_eui = binascii.unhexlify(‘xxxx’)  
app\_eui = binascii.unhexlify(‘xxxx’)  
app\_key = binascii.unhexlify(‘xxxx’)

for channel in range(0, 72):  
lora.add\_channel(channel, frequency=903900000, dr\_min=0, dr\_max=3)

join a network using OTAA  
lora.join(activation=LoRa.OTAA, auth=(dev\_eui, app\_eui, app\_key), timeout=0, dr=4)

wait until the module has joined the network  
join\_wait = 0  
while True:  
time.sleep(2.5)  
if not lora.has\_joined():  
print(‘Not joined yet…’)  
join\_wait += 1  
if join\_wait == 5:  
lora.join(activation=LoRa.OTAA, auth=(dev\_eui, app\_eui, app\_key), timeout=0, dr=0)  
join\_wait = 0  
else:  
break

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, 0)

make the socket blocking  
s.setblocking(False)

time.sleep(5.0)

for i in range (200):  
pkt = b’PKT #’ + bytes([i])  
print(‘Sending:’, pkt)  
s.send(pkt)  
time.sleep(4)  
rx, port = s.recvfrom(256)  
if rx:  
print(‘Received: {}, on port: {}’.format(rx, port))  
time.sleep(6)

---

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 29, 2018, 3:30pm UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/8 "2018-04-29T15:30:08Z")

</div>

Anything on the TTN gateway to suggest it was received and forwarding it on? If so, anything on the TTN console to suggest it has replied?

---

<div class="post-metadata">

**Author:** ![asavvin](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/asavvin/32/36808_2.png) [@asavvin](https://www.thethingsnetwork.org/forum/u/asavvin)\
**Post date:** [April 29, 2018, 5:50pm UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/9 "2018-04-29T17:50:53Z")

</div>

I have not done anything on gateway side. I was able to go through activation process and saw in application data flowing, on gateway side I did see anything and I think this is will be next step.  
I think in US915 is required to add dr=4 or 0 after timeout.

lora.join(activation=LoRa.OTAA, auth=(dev\_eui, app\_eui, app\_key), timeout=0, dr=4)

---

<div class="post-metadata">

**Author:** ![mikcatta](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mikcatta/32/35697_2.png) [@mikcatta](https://www.thethingsnetwork.org/forum/u/mikcatta)\
**Post date:** [April 30, 2018, 8:22am UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/10 "2018-04-30T08:22:06Z")

</div>

So activation is fine, but sending data is not ?

Not in the US so can’t test that out, but this post seems to suggest DR 1 & 3 work. [Example PyCom OTAA US version Send with Receive](https://www.thethingsnetwork.org/forum/t/example-pycom-otaa-us-version-send-with-receive/7959/5)

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [November 30, 2018, 12:11pm UTC](https://www.thethingsnetwork.org/forum/t/pycom-fipy-connects-ok-with-abp-but-not-otaa/13426/11 "2018-11-30T12:11:22Z")

</div>

A post was merged into an existing topic: [OTAA then ABP](https://www.thethingsnetwork.org/t/otaa-then-abp/12377/6)
