Radio not deactivated when switching from class C to class A

[janakj]

I have a LoRaMac-node device operating in class C. When I try to switch the device back to class A, I see the radio being deactivated and then immediately reactivated in a continuous RX mode again. The reactivation is highlighted in bold in the following snippet:

61.95  ATCI: AT+CLASS=0
61.95  SX1276SetAntSwLowPower: 1
61.95  SX1276SetBoardTcxo: 0
61.95  SX1276SetChannel: 923.300 MHz
61.95  SX1276SetRxConfig: LoRa SF12/500kHz 4/5 preamb=8 symTout=9 iqInv rxCont
61.95  SX1276SetBoardTcxo: 1
61.96  SX1276SetAntSwLowPower: 0
61.97  Saving MacGroup2 state to NVM
61.98  Saving system configuration to NVM

In other words, LoRaMac-node keeps the radio on continuously after switching to class A.

I have been able to trace the problem to the following snippet in LoRaMacProcess: https://github.com/Lora-net/LoRaMac-node/blob/e182832f8b79188c63b0737c184fb345932d50a9/src/mac/LoRaMac.c#L1807-L1810 The above code reactivates the radio for continuous RX operation on the next run of LoRaMacProcess, even if the device has been switched to class A in the meantime. The culprit is probably the code that handles the class switch which puts the radio to sleep, but leaves MacCtx.RxSlot untouched: https://github.com/Lora-net/LoRaMac-node/blob/e182832f8b79188c63b0737c184fb345932d50a9/src/mac/LoRaMac.c#L2015-L2033

Is this a bug?

In my fork of LoRaMac-node, I have fixed the issue by modifying LoRaMacProcess as follows:

if( Nvm.MacGroup2.DeviceClass == CLASS_C && MacCtx.RxSlot == RX_SLOT_WIN_CLASS_C )
{
    OpenContinuousRxCWindow( );
}

However, I am not sure if that's the right fix. It might also be possible to reset MacCtx.RxSlot in SwitchClass. Not sure which approach is better. Any thoughts?

[mluis1]

I think that resetting MacCtx.RxSlot in SwitchClass would be the best approach.

        case CLASS_C:
        {
            if( deviceClass == CLASS_A )
            {
                // Reset RxSlot to NONE
                MacCtx.RxSlot = RX_SLOT_NONE;

                Nvm.MacGroup2.DeviceClass = deviceClass;

                // Set the radio into sleep to setup a defined state
                Radio.Sleep( );

                status = LORAMAC_STATUS_OK;

                // Add a DeviceModeInd MAC Command to indicate the network a device mode change.
                if( Nvm.MacGroup2.Version.Fields.Minor >= 1 )
                {
                    LoRaMacCommandsAddCmd( MOTE_MAC_DEVICE_MODE_IND, ( uint8_t* )&Nvm.MacGroup2.DeviceClass, 1 );
                }
            }
            break;
        }

If you agree we will push this fix as soon as possible.

[janakj]

Yes, that makes sense to me. This is probably better than modifying LoRaMacProcess. Thanks.

-Jan

On Wed, Jun 15, 2022 at 5:07 AM Miguel Luis @.***> wrote:

I think that resetting MacCtx.RxSlot in SwitchClass would be the best approach.

    case CLASS_C:
    {
        if( deviceClass == CLASS_A )
        {
            // Reset RxSlot to NONE
            MacCtx.RxSlot = RX_SLOT_NONE;

            Nvm.MacGroup2.DeviceClass = deviceClass;

            // Set the radio into sleep to setup a defined state
            Radio.Sleep( );

            status = LORAMAC_STATUS_OK;

            // Add a DeviceModeInd MAC Command to indicate the network a device mode change.
            if( Nvm.MacGroup2.Version.Fields.Minor >= 1 )
            {
                LoRaMacCommandsAddCmd( MOTE_MAC_DEVICE_MODE_IND, ( uint8_t* )&Nvm.MacGroup2.DeviceClass, 1 );
            }
        }
        break;
    }

If you agree we will push this fix as soon as possible.

— Reply to this email directly, view it on GitHub https://github.com/Lora-net/LoRaMac-node/issues/1322#issuecomment-1156204892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMMAYB6GVNL4SF7UPN2XDVPGMOBANCNFSM5Y2AID7A . You are receiving this because you authored the thread.Message ID: @.***>