Class C device can't receive Downlink

[maqbool]

I'm trying out the example given in https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node.py. My eventual goal is to use the device as a class C device by modifiying the LoRa function as

LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868, device_class=LoRa.CLASS_C)

However, neither the example in the page nor the class C modification seems to work. Join is successful, but I always get the result of s.recv(64) as b''. I am using the chirpstack application server https://www.chirpstack.io/. The network server logs show the downlink being transmitted without error.

My gateway (single channel) logs also seem to be transmitting the downlink OK:

[down] {"txpk : {"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":824943453,"freq":868.1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":15,"data":"YOyWBQCAAQAC1f5clYt0"}}

However, nothing in the recv function. lora.stats() also always gives rx_timestamp = 0.

The successful join request and accept indicates that the communication channels are correctly configured. The network server also resets the frame counters at every new join request, and there is no nvram save in the script, so I assume frame counter validity wouldn't be an issue ...

What could I be missing?

The firmware info is:
(sysname='FiPy', nodename='FiPy', release='1.20.1.r2', version='v1.11-06dfad0 on 2019-11-30', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.3.0')

[Alexander Pilhar]

@jcaron yes, the device is declared to be a class C device via device profile in chirpstack.
Here are more details on the setup:

• Device is a LoPy 4.
• Every 3 hours it receives data via LoRa and displays it on e-paper.
• Data comes from a sensor device (Tekelek TEK 766).
• Communication from sensor to display via Chirpstack, LoRa all the way (Logs show downlink to LoPy 4).
• No deepsleep nor sleep.
• Every 5 minutes it updates the information on the display with latest timestamp to see if the device itself is still working.

After a power reset it seems to be working as expected. Only after some time the problems occur.

I need to do some further testing because over the last weekend the device has stopped working.

[jcaron]

@Alexander-Pilhar did you declare the device as class C in the network server (LNS)? The class parameter on the device tells the device to listen all the time, but it is not sent to the network. It is up to you to configure the network so that it knows that device can receive a downlink at any time.

[Alexander Pilhar]

I have the same problem (Class C).
I only receive the expected downlink when another downlink is made (as if it was Class A).

[javier maroto]

@maqbool did you get it? I have the same problem

[maqbool]

I will also attach the modified code I'm using, in case I miss something trivial.

#!/usr/bin/env python
#
# Copyright (c) 2019, Pycom Limited.
#
# This software is licensed under the GNU GPL version 3 or any
# later version, with permitted additional terms. For more information
# see the Pycom Licence v1.0 document supplied with this file, or
# available at https://www.pycom.io/opensource/licensing
#

""" OTAA Node example compatible with the LoPy Nano Gateway """

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

# initialize LoRa in LORAWAN mode.
# Please pick the region that matches where you are using the device:
# Asia = LoRa.AS923
# Australia = LoRa.AU915
# Europe = LoRa.EU868
# United States = LoRa.US915
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868, adr=False, public=True, tx_retries=1, device_class=LoRa.CLASS_C)
lora.init(mode=LoRa.LORAWAN, region=LoRa.EU868, adr=False, public=True, tx_retries=1, device_class=LoRa.CLASS_C)
LORA_FREQUENCY = 868100000
LORA_GW_DR = "SF7BW125" # DR_5
LORA_NODE_DR = 5

# create an OTA authentication params
dev_eui = binascii.unhexlify('***********')
app_eui = binascii.unhexlify('0000000000000000') #from Chirpstack, JoinEUI/AppEUI is not yet supported: https://forum.chirpstack.io/t/where-do-i-set-the-appeui/381/14
app_key = binascii.unhexlify('*********') #key from my server

# set the 3 default channels to the same frequency (must be before sending the OTAA join request)
lora.add_channel(0, frequency=LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(1, frequency=LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(2, frequency=LORA_FREQUENCY, dr_min=0, dr_max=5)

# join a network using OTAA
lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0, dr=LORA_NODE_DR)

# wait until the module has joined the network
while not lora.has_joined():
    time.sleep(2.5)
    print('Not joined yet...')

# remove all the non-default channels
for i in range(3, 16):
    lora.remove_channel(i)

# 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, LORA_NODE_DR)

# make the socket non-blocking
#s.setblocking(False)

time.sleep(5.0)

for i in range (200):
    pkt = b'PKT #' + bytes([i])
    print('Sending:', pkt)
    #s.setblocking(True)
    s.send(pkt)
    time.sleep(1)
    s.setblocking(False)
    rx, port = s.recvfrom(256)
    print(lora.stats())
    if rx:
        print('Received: {}, on port: {}'.format(rx, port))
    time.sleep(20)

[maqbool]

Didn't help. I used the Pycom Firmware Update Tool which updated me to 1.20.2.rc9. Can anyone say if the script I am using is the correct one? Are there any further diagnosic functions similar to lora.stats(), that at least show if a message (valid or invalid) arrived at all?

[rholas]

1.20.1.r2 is an old firmware.
try with latest version