Skip to main content
abdelrahman-kadah-azka
Visitor II
Nov 10, 2026 2:11 PM UTC
Question

Class B Ping Slots and Class C RX Window Behavior After Storing LoRaWAN Context

Dear Team,

I hope you are doing well.

I am currently working with a Nucleo-WL55JC1 board running the LoRaWAN_AT_Slave application from the STM32WL v1.4.0 SDK.

I have enabled both Context Management and Class B support in the lorawan_conf.h configuration file and successfully completed the following steps:

  1. Joined the LoRaWAN network.

  2. Configured the ping slot periodicity.

  3. Switched the device to Class B.

  4. Sent several uplink messages to the ChirpStack Network Server to notify it that the device had switched to Class B.

After enabling the debug logs, I confirmed that:

  • Beacon reception was working correctly.

  • Ping slots were being opened as expected.

  • Queued downlink messages were successfully received during the ping slots.

However, I noticed an unexpected behavior after executing the AT+CS command, which returns NVM_CONTEXT_STORED.

Following this command, beacon reception and ping slot activity stop appearing in the logs. They only resume after I send another uplink message.

I have observed similar behavior when operating in Class C: the RXC window activity disappears after storing the context and resumes only after transmitting another uplink.

My questions are:

  1. Is this behavior expected when operating in Class B and Class C?

  2. Why does storing the LoRaWAN context using AT+CS cause beacon reception and ping slot activity (or the Class C RX window activity) to stop?

  3. Is there any additional step required to maintain Class B or Class C operation after storing the context?

I would appreciate your clarification on this behavior and any recommendations for handling context storage correctly.

Thank you for your support.

Best regards,
Abdelrahman Kadah
Firmware Engineer
Azka Technology

 

Terms & ConditionsAccessibility statement