LoraWAN packet performance?

[misterlisty]

I have finally got t he abiliyt o send LOraWan messages. But gateway only gets 1 in 7 sent packets? What is the theory behind this and is it possible to get confirmation on packets sent?

[jcaron]

@misterlisty please give us a lot more details:

• is it your own gateway (and if so, a full gateway supporting multiple channels or a nano-gateway only listening on a single channel)?
• how far is the gateway?
• are you indoors?
• what kind of antenna are you using?
• what script are you using?
• in what region are you?
  ...

You can send confirmed packets over LoRaWAN, but in many regions (including EU868) there are strict limits on how much a node (including a gateway) can send, so it’s usually not practical.

[robert-hh]

@misterlisty I have the same experience, and varying. I am trying that now since a week, and in the beginning I had a better impression of sending packets. Most of the time I was trying to get OTAA join working.
And for @jcaron
Node: FiPy, 4€ Stub antenna lamba/4 in a 6x12cm metal sheet, connected to GND
Gateway: LoPy, Antenna Aurel GP868 (just a low price lambda/4 piece, with assembly for outdoor placement)
Scripts: nanogateway examples from the lib
Firmeware: 1.16.0.b1, homebrew, with a modification for the node to get join working better than once in a million.

The funny thing is, that the join request is ALWAYS received by the gateway on the first attempt, while succeeding test message are more rarely recognized. I might go back to the initial set-up an test that.

Note on Antennas: The simple stub antenna has a better reception than the Aurel GP, most likely caused by the 2.5m cable & 2 connectors.

[robert-hh]

@misterlisty It seems to depend on the joining method:

a) ABP join, original FW: 32 of 33 messages arrived at TTN
b) ABP join, modified FW: 33 of 33 messages arrived at TTN
c) OTAA join, modified FW: 13 of 33 messages arrived at TTN

I cannot run the OTAA joined test with the original FW (case a), since the join never succeeds.

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