Receive LoRa messages continuously (STM32 NUCLEO-WL55JC1)

[SamuelJ]

Hello!

My code is based on the LoRaWAN Endnode example and I adjusted it to send data when pushing the BUT1. I have three board all with the same code and depending on which device sent the data I want to toggle LEDs connected with the boards. This works fine so far and I can see and process the data in the STM32CubeMonitor.

For this I used the TX_ON_TIMER mode which just works fine, but the latency between pushing the button and the LEDs lighting up is pretty high.

To reduce the response time I switched to TX_ON_EVENT mode, but on the boards the data (for turning on the LEDs) isn't received until I send data to the gateway. I also tried switching from LoRa class A to B and C but it doen't really change the behaviour. Shouldn't the data be received continuously when using LoRa class C? It seems somehow as if the devices are still in LoRa class A mode.

I'm still pretty new to working with STM32 and LoRa so it's all very confusing for me right now.
Is there a fix for this?

Thanks in advance!

[Andrew Larkin]

Just to save future confusion, LoRa is not technically the same as LoRaWAN. You can use LoRa to communicate directly between devices using your own protocols (haven't done this myself, but look at the Ping Pong example).

LoRaWAN defines a protocol over the top of LoRa that involves a gateway, a network server, an application server, and an application "in the cloud".

I am pretty sure you are using LoRaWAN based your references to the EndNode example and to device classes.

Class A devices only receive data during one of two RX windows following a TX.  So, a node transmits, and 2 seconds later will listen for a downlink. If none is received, it will listen again one second later.

Class B nodes have scheduled receive windows associated based on a beacon signal.

Class C nodes are in listen mode when not actually transmitting. These have the highest power use.

Assuming you have two class A nodes, the latency will be long:

1. Node X sends button press uplink to gateway

2. Gateway sends it to Network server -> Application Server -> your application code.

3. Your application code queues a downlink message to Node Y.

4. At some time, Node Y sends an uplink and, a couple of seconds later, the Rx window opens and the queued downlink message arrives. LED turns on.

This is not a complete nor totally accurate view of what happens, but the point is that you have really no control over the latency with Class A nodes - this is actually the point as they are intended to be ultra low power and do things in their own sweet time.

Class B supposedly requires the gateway has a GPS time source.

Class C is the simplest but highest power as it doesn't sleep.

You still have round trip latency via the LoRaWAN software suite and whatever application logic you are running.

If your intention is to communicate directly between the boards, then LoRaWAN is not the solution you want and you need to dig into LoRa directly - again, see the Ping Pong example code.

[SamuelJ]

Thank you for your reply and information!
I wasn't working on the project for about a month now so I didn't check on the post here.

Just for your information: This project with two end nodes and LEDs is just a prototype for a similar project with much more end nodes (~20), so I think LoraWAN is definitly needed here.

I am familiar how the different classes work (or should work) and I switched from class A (which is active in the example project) to class c by changing "#define LORAWAN_DEFAULT_CLASS CLASS_A" to "#define LORAWAN_DEFAULT_CLASS CLASS_C" in the "lora_app.h" file. I also tried adjusting the settings regarding lora classes in "lorawan_conf.h", but it seems as if the STM32 doesn't switch to class c and is still in class a because i only receive downlinks on the end nodes after sending an upload. I also changed "#define DISABLE_LORAWAN_RX_WINDOW 0" to "#define DISABLE_LORAWAN_RX_WINDOW 1" in "lorawan_conf.h" and then I don't get any downlinks on my end nodes (and they are definitly sent by the gateway).
It gives me the feeling that there are some settings which need to be changed for class c to work.

 

Am I missing something here or is the LoRaWAN Endnode example just not made for class c?

[fainlaip]

Hi Samuel, I have run at the similar problem, I also tried to change my end node from class A to class C, but unfortunately did not manage to achieve that.

Did You maybe find the solution to this problem?

 

Best regards,

Filip

[Andrew Larkin]

I haven't tried doing a class C node (yet) but I thought you had to set up the LoRaWAN server to tell the device to switch to class C.  This could be completely bogus..