V4.4.1 class C downlink doesn't work at all.

[Newsland]

Hi,guys.I'm sorry to trouble you that I move LoRaMac node to my board(stm32l431cbt6 with 32.768khz LSE,8Mhz HSE).and the class A mode works very well.But when I switch to class C mode.my board can't receive downlink packet.Then I do these jobs to check anything wrong:
1.ensure gateway and node both switch to class c mode,same frequency,datarate,coderate,bandwith,spreadfactor.
2.ensure gateway works fine(can receive and send lora packets)
3.ensure node works and open continue rx2 window.
4.I enter debug and set broke points.and find it didn't enter RX_DONE section after I send a downlink packet.Then I found others has the same problem and you update this issue,so I download the new files(sx126x.h sx126x.c radio.c) and replace,but it can't work.Could you please give me some advices.
Thank you a lot.

[altishchenko]

@Newsland The first question is, what server are you using? Other/different boards working with this server at class C?
Usually network servers can't distinguish between Class A and Class C devices, so some special configuration is required on the server side first.

[Newsland]

I use open source lora server,other device with lora module can work,and we are trying to replace lora module by using chips.Actually the problem is rx2 windows period can't receive data whatever in class A or class C.And our lora server can distinguish class a and class c,because we configure basic information on it.And we only use ABP.

[Newsland]

[Newsland]

I found issue#498 has the same problem,then update this files.But not works

[altishchenko]

Hello and what this ACK-False thing is? And what is marked in blue? I am not familiar with this server, so I can't tell where is uplink and where is downlink and for what device this downlink is destined if blue is downlink. For what I can see is that the server receives information from your device and sends nothing back (?) You restart your device often and use ABP with that, what is the setting of the FCnt check on the server side? Some servers will discard "duplicate" FCnts from the devices if not instructed otherwise. Devices too may discard unknown FCnts from the server.. For example, your device doesn't store session data (FCnts) in the NVRAM, so upon its restart it will expect and FCnt of 1 or 0, but your server may remember trying to send some data down to your device and will choose its own next value, not 1 or 0. Your device will naturally ignore this packet as the FCnt count is incorrect / unexpected.

[Pirakutu]

The stack had issues running class C on that version (4.4.2 also), i also had the same problems when running it on ABP. I would recommend to update the stack to the newest version, or at least to V4.4.4 (the stack itself works well on class C there, we are running it there and it works very stable). There was only a problem with the radio drivers on the sx126x side on that version of the stack, so we updated the radio files to v4.4.7, which then solved the problem. Hope this helps.

[mluis1]

As advised by @altishchenko and @Pirakutu I would recommend to update the stack to the latest version supporting LoRaWAN 1.0.3 (Same as 1.0.2 with official inclusion of Class B operation) v4.4.7.

The version that your are using is 3 years old and in meantime a lot of improvements and fixes have been done.
If possible I would recommend to update the stack to latest version v4.5.2 which implements LoRaWAN 1.0.4 specification (which is backwards compatible),

Please note that I have moved this discussion to the project Discussions tab.
In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not.

[bwesen]

Hi, I recently updated from a very old stack to v4.5.2 and now I have the same issue, Class C does not work. 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, it sends the packet and 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).

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);
  }
}