LoRaWAN Class C in STM32 Cube WL 1.5.0

[bgoedel]

Dear Community,

after the most recent Webinar regarding LoRaWAN Relays I downloaded the newest CubeWL, which was version 1.5.0 and now I'm trying to migrate my code from CubeWL 1.3.1 to 1.5.0.

My project is the Firmware for LoRaWAN Class C end nodes - which was no problem in CubeWL 1.3.1 as there was a setting in CubeMX to make the node Class C in the startup. As a consequence of this, a function was generated called OnRxData() in the file lora_app.c that would be called whenever a packet is received. It would differentiate the treatment depending on the port (e.g., the example code was port 2 or LORAWAN_USER_APP_PORT to switch on and off the LED on the Eval Board).

I think, it wouldn't be a problem to switch the end node from class A to class C after startup but I'm struggling to find code that is called when a packet is received in the LoRaWAN_End_Node_LBM project.

Could you please point me to the code I'm searching for?

Kind regards,

Bernhard

[Imen.D]

Hello @bgoedel ,

When migrating STM32CubeWL FW package version to 1.5, try follow updated API and structure guidelines with migration notes that are described in this AN6473. This may help you.

[bgoedel]

Dear @Imen.D ,

thank you for your suggestion. I read the document and found out that Class C is apparently supported through a MAC Command sent by the Network Server after a successful Join.

I consulted an AI that explained to me that I need to call

smtc_modem_set_class( STACK_ID, SMTC_MODEM_CLASS_C );

in the handling of the SMTC_MODEM_EVENT_JOINED in order to tell my end node that I want it to switch to class C. As a consequence, it apparently would queue a DeviceModeInd MAC Command that would be sent to the Network Server on the next uplink.

As a consequence, the Network Server would send a DeviceModeConf MAC Command which would complete the process of switching the end node to Class C.

I tried this but failed. I got a lot of "write CMD error" in my log output of the end node. The AI keeps telling me that the CubeWL 1.5.0 implements LoRaWAN 1.1.0, so I need to change the Device Profile on my Chirpstack to 1.1.0 and I did. This made everything worse - nothing worked anymore.

The reason for this seems to be that the end node configuration in the CubeMX says that it is using LoRaWAN Link Layer 1.0.4. This setting is grey, so I cannot change it.

I can only assume that the end node is operating on 1.0.4 (although the Semtech LBM is basically an implementation of 1.1.0). In 1.0.4 there is no MAC Command DeviceModeInd or DeviceModeConf, so the LoRaWAN Stack in the end node doesn't know what to do when it receives such a MAC command.

If I switch the Network Server to use 1.1.0 for my device, nothing works as it tries to communicate with a 1.0.4 end node.

So, I'm kind of stuck. I would like to use the new CubeWL 1.5.0 especially as the LoRaWAN 1.1.0 is recommended for enterprise networks, which my end nodes will be in. But if I cannot come around the switch to Class C, I must go back to CubeWL 1.4.0 to use LoRaWAN 1.0.4.

Could you please point me to a solution how to make the LBM end node to switch to Class C?

Kind regards,
Bernhard

PS: I also found in the release notes of the LoRaWAN Stack (in Middlewares/Third_Party/LoRaWAN/Release_Notes.html) that Multicast is "not fully supported", so this might be no option for me because we heavily rely on Multicast (that's why the end nodes need to be in Class C).

[bgoedel]

Hi,

I just wanted to check whether you have any updates on this topic.

Apparently, CubeWL 1.5.0 is neither capable of running End Nodes on Class B or Class C and thus is also not capable of running anything that can receive Multicasts.
Class B is officially not supported (as written in the readme). The End Node is simply unable to enter Class C because the handshake with the Network Server is not working as the LoRaWAN Stack underlying the LBM is still 1.0.4.

Is that correct?

Kind regards,
Bernhard