LoraWAN packet performance?

[robert-hh]

@misterlisty I opened an issue & got a good explanation, allowing a workaround: https://github.com/pycom/pycom-micropython-sigfox/issues/143
The workaround is to remove in the node all channels but the first one AFTER joining, like this way:

# remove all channels but the first
for i in range(1, 16):
    lora.remove_channel(i)

That worked for me.

[misterlisty]

Using the Multi-Tech as the gateway. Using a stub antenna for both. Distance between node and gateway is about 5 metres.

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



lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915)
print("Lora send::-3")

print("DevEUI[",binascii.hexlify(lora.mac()).upper().decode('utf-8'),"]")


# create an OTAA authentication parameters
dev_eui = binascii.unhexlify('00 A3 D5 59 96 62 A9 85'.replace(' ','')) 
app_eui = binascii.unhexlify('00 80 11 00 00 11 B7 E2'.replace(' ',''))
app_key = binascii.unhexlify('2B 7E 15 10 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C'.replace(' ',''))


print("Lora send::-1")


lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)
#lora.join(activation=LoRa.ABP, auth=(dev_eui,app_eui, app_key), timeout=0)
print("Lora send::0")

while not lora.has_joined():
    time.sleep(5)
    print('Not yet joined...')

print('Finally joined...')


s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

print("Lora send::1")

s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, 0)

i = 0
while True:
    s.setblocking(True)
    print("Sending Hello there #" + str(i))
    count = s.send("Hello there #" + str(i))
    print('Sent %s bytes' % count)
    print(lora.stats())
    time.sleep(60)
    i += 1

[robert-hh]

@misterlisty Did you try to remove all but one channel after joining, like I did in the example below?

[misterlisty]

@robert-hh Ill try this tomorrow. Why is this required?

[jcaron]

@misterlisty Not familiar with the specifics of the AU region, but as I understand it, there are 72 different frequencies available, and gateways usually listen only on 8 or so. The network should send LinkAdrReq commands to the node to tell it which frequencies to use (it should somehow know which frequencies the gateway listens on). This may require you to turn on adr=True in your code.

[robert-hh]

@misterlisty As @daniel explained:
"@robert-hh thanks for reporting this. The difference with OTAA actually makes sense if the network server (TTN) is adding channels and the node is accepting it, making the nano-gateway (which only operates in 1 channel) to not receive the messages sent on the new channels.

The fix is to reject "New Channel Requests" made on the channels that have been manually removed. This was the case on our previous LoRaWAN stack, but something didn't go right when moving to the new 1.0.2 stack."

That is not true for your gateway, but maybe there is a mis-match of channels being used and seen. As far as I recall the example code for the node, all channels are set to the same frequency.

[jmarcelino]

Hi @misterlisty

Since the gateway is set to Frequency sub-band 2 you need to remove all channels other except those in sub-band 2 (channels 8-15)

This isn't done automatically by the network.

Please add this after initialising LoRa to remove the channels the gateway doesn't support:

for channel in range(0, 8):
        lora.remove_channel(channel)

for channel in range(16, 64):
        lora.remove_channel(channel)

[misterlisty]

@jcaron what is adr=True

[misterlisty]

ok..i seem to be getting all the data packets now..mmm..now i'm going to test how far i can go with my car in distance :)

[jcaron]

@misterlisty it's an optional parameter on the LoRa constructor which enables ADR (adaptive data rate), which is a LoRaWAN features which enables the node and network to adjust parameters (the most important being the data rate, but channels lists as well). Some MAC commands sent by the network are only honoured by the LoPy if ADR is enabled.

However @jmarcelino says the network doesn't send those commands anyway, so it may not be useful.

Also note that the current firmware version does not correctly preserve channel masks during deep sleep.