Pycom fipy connects ok with ABP but not OTAA

End Devices (Nodes) Pycom
1

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!')
2

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?

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

3

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

4

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

5

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 for what’s expected. Also, the “Trace” part in the gateway’s traffic in TTN Console might give you some clues.

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

LoRaWAN :wink:

1 Like
6

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.

1 Like
7

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)

8

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?

9

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)

10

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

1 Like
11

A post was merged into an existing topic: OTAA then ABP