ABP Node not receiving data while trying class C features

[ThatStudentGuy]

So while trying out some code I noticed that the code provided for the latest Nanogateway TTN examplelink does not seem to work properly. The code responsible for processing downlink data:
'''
for i in range (200):
s.send(b'PKT #' + bytes([i]))
time.sleep(4)
rx = s.recv(256)
if rx:
print(rx)
time.sleep(6)
'''
I tried to modify it to work like a "Class-C" node:
'''
while True:
data = s.recv(64)
if data:
print(data)
'''
This code responds to nothing at all. The backend is running on the open source LoRaWAN application and in the log, I can see that the gateway sends out the packet but the node ignores it.
I tried the code with TTN as well but they seem to experience some problem with gateways. It has also been tried with both a Kerlink gateway and the Nanogateway with the same result. No data picked up by the node. While trying out on the Kerlink all channels were activated as well.

I also tried out the lora.callback function on the node and it picks up TX events but no RX events. It would be a nicer way to handle it compared to a while loop.

Is this not possible to achieve with the LoPy today or am I missing something?
Anyone know what might the problem or have any suggestions?

[rambo]

@jmarcelino I'm also looking at class-C though using OTAA activation but it seems the class is hardcoded in the stack ? I'm using everynet network which does support class-C devices and I see on SDR that the gateway does try to send the packet to the device but the device is not receiving.

[jmarcelino]

@ThatStudentGuy
The board supports it, it's just that the stack is set to Class A and there's no option in Python to change it.

However it might just be a simple matter of changing LoRaMacDeviceClass = CLASS_A; in pycom-micropython-sigfox/blob/master/lib/lora/Mac/LoRaMac.c to LoRaMacDeviceClass = CLASS_C; and rebuilding the firmware.

You can follow the guide here https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/README.md to learn how to build your own custom stack and flash into to the LoPy.

Raw LoRa should at least show something as well, though encrypted and encoded.

You will also need a network server that supports Class C. The Things Network (TTN) doesn't yet.

Let us know how it goes. Class C is still bit of niche topic, mainly because the increased power usage limits many of the typical LoRa use cases.

[ThatStudentGuy]

@jmarcelino
Thanks for the answer!
Okay so when the LoPy is initialized in LoRaWAN mode it works as a class A device? That is probably the problem then. This was not clear from the specification as it specifies both class A and C. It is possible to work around using the device in only LoRa mode.

[jmarcelino]

In LoRaWAN Class A (which is what the LoPy and TTN implements) you have to send first (uplink) before you can do a receive (downlink)

Without doing the send() first TTN will not send you any data. Also because the LoPy is a Class A device you need to do a send to get receive windows, just calling recv() isn't enough.