v4.5.2 Class C downlinks don't work (for me) on SX1276/STM32L0

[bwesen]

Hi, I recently updated from a very old stack to v4.5.2 and now I have the issue that Class A works fine, Class C does not work (node never receives any of those packets). I'm using the Multuitech Conduit LORA server (in a custom self-contained setup, it's not on any of the internet lora networks), and if I set the node to Class A there, packets can be received (of course only when the node is doing an uplink). But if the server is in Class C, I can see that it sends the packet but the node on 4.5.2 simply does not receive it.

I'm on the Murata module with SX1276 and STM32L0, and everything worked fine with Class C before. I'm using OTAA.

Any recommendations on where to start debugging? Are there any integration issues that might act up during CLASS C but not in CLASS A, like if I've missed some GPIO pin config on the SX1276 or related.. (had to redo all that as all those peripheral things changed in the stack as well).

What is the first place in the code to add some printouts or something to show if the RX is running at all outside the RX-window following uplinks?

I kind of assume that a lot of other things would have broken if there actually was anything wrong with the SX1276 communication after my upgrade, like no interrupts being triggered from the GPIO or so. But the only symptom is that CLASS C is not receiving.

FWIW this is my setup:

static LmHandlerParams_t LmHandlerParams =
{
  .Region = LORAMAC_REGION_US915,   
  .AdrEnable = LORAMAC_HANDLER_ADR_ON,                   // Start with Adaptive Data Rate enabled
  .IsTxConfirmed = LORAMAC_HANDLER_UNCONFIRMED_MSG,
  .TxDatarate = DR_0,                                    // Uplink datarate, if ADR is off (I think ADR starts at DR_0 then switches up)
  .PublicNetworkEnable = LORAWAN_PUBLIC_NETWORK,
  .DutyCycleEnabled = true,
  .DataBufferMaxSize = LORAWAN_APP_DATA_BUFFER_MAX_SIZE,
  .DataBuffer = AppDataBuffer,
  .PingSlotPeriodicity = REGION_COMMON_DEFAULT_PING_SLOT_PERIODICITY,
};

and on Join I switch to Class C (I also confirmed that the OnClassChange callback is done and it has the Class C argument):

static void OnJoinRequest(LmHandlerJoinParams_t *params)
{
  if(params->Status == LORAMAC_HANDLER_ERROR) {
    PRINTF("error joining..\n");
    LmHandlerJoin();
  } else {
    PRINTF("J!\n");
    LmHandlerRequestClass(CLASS_C);
  }
}

[solunator]

I'm having the same problem in the same hardware, did you find a solution?

[bwesen]

I'm having the same problem in the same hardware, did you find a solution?

I had to spend a lot of time tracking this down, eventually I found that the stack corrupted its own RxCChannel.Frequency and .Datarate parameters upon switching to CLASS_C, so it did listen on the RxC receive window, but with the wrong freq/DR..

I found in the stack mac/LoRaMac.c:SwitchClass() function that it goes through the MulticastChannelList from the Nvm.MacGroup2 and if any MC channel is set, it overwrites the entire stack's RxC window parameters from the specific enabled MC group. I think this is a hack, because different MC groups could have different RxC window parameters, a situation that obviously will never work but why have the params in the MC group then :)

And I hadn't set up the Nvm MutlicastChannelList properly so this just corrupted the normal (non-MC) RxC, it got freq 0 and stuff... I don't remember why I had this setup wrong, probably because there is no documentation or setup examples at all.

I verified this was the cause of my issue by just commenting out the chunk that (potentially) overwrites this, see the #if 0 chunk below inside SwitchClass:

if( deviceClass == CLASS_C )
            {
                Nvm.MacGroup2.DeviceClass = deviceClass;

                MacCtx.RxWindowCConfig = MacCtx.RxWindow2Config;
                MacCtx.RxWindowCConfig.RxSlot = RX_SLOT_WIN_CLASS_C;
#if 0   // TEST REMOVE
                for( int8_t i = 0; i < LORAMAC_MAX_MC_CTX; i++ )
                {
                    if( Nvm.MacGroup2.MulticastChannelList[i].ChannelParams.IsEnabled == true )
                    // TODO: Check multicast channel device class.
                    {
                        Nvm.MacGroup2.MacParams.RxCChannel.Frequency = Nvm.MacGroup2.MulticastChannelList[i].ChannelParams.RxParams.ClassC.Frequency;
                        Nvm.MacGroup2.MacParams.RxCChannel.Datarate = Nvm.MacGroup2.MulticastChannelList[i].ChannelParams.RxParams.ClassC.Datarate;

                        MacCtx.RxWindowCConfig.Channel = MacCtx.Channel;
                        MacCtx.RxWindowCConfig.Frequency = Nvm.MacGroup2.MacParams.RxCChannel.Frequency;
                        MacCtx.RxWindowCConfig.DownlinkDwellTime = Nvm.MacGroup2.MacParams.DownlinkDwellTime;
                        MacCtx.RxWindowCConfig.RxSlot = RX_SLOT_WIN_CLASS_C_MULTICAST;
                        MacCtx.RxWindowCConfig.RxContinuous = true;
                        break;
                    }
                }
#endif
                // Set the NodeAckRequested indicator to default
                MacCtx.NodeAckRequested = false;
                // Set the radio into sleep mode in case we are still in RX mode
                Radio.Sleep( );

                OpenContinuousRxCWindow( );

                status = LORAMAC_STATUS_OK;
            }
            break;

[solunator]

It seems the cause of my problem is different from yours because LORAMAC_MAX_MC_CTX=1 and Nvm.MacGroup2.MulticastChannelList[0].ChannelParams.IsEnabled=false, so nothing is run inside the for loop.

I'm using the latest I-CUBE-LRWAN from st, but it implements LoRaMac 4.4.7. Even the unmodified software from st is having this issue, it stops receiving class C downlinks sometime after joining, but firstly it receives some dowlinks without any problem.

Thank you very much

[bwesen]

What Lora gateway are you using? I debugged my issues by looking closely at the gateway's log, it showed exactly which frequencies and DRs it tried to use for the various downlinks, and which RX windows it tried sending in. Without this info, you might be staring at problems that are really in the gateway (for example it might incorrectly revert to thinking the particular devices is in Class A instead of C).

[solunator]

MultiTech Conduit