I meet some issues with class C downlinks. Here what I have done:
Set up a gateway (with SEMTECH UDP Packet Forwarder).
Set up a STM32WL with a classic End-Node project (furnished by STMicroelectronics by the way). In this project, I have configured the device as a class C end-node using OTAA for activation.
Set up, in ChirpStack: The network server, the service-profile, the application, the device and of course the device-profile with the class C enabled.
Then, the Join procedure works well, and all uplinks are successful. BUT when I schedule downlink frames to my STM32WL, they go to the “Downlink Queue” and are not immediately transmitted to my device. Therefore, theses downlink frames are handled as class A downlinks: they are sent during the RX1/RX2 window right after an uplink. I can confirm this observation with my STM32WL logs. Moreover, I have seen in the LoRaWAN frames details (see screenshot below) of my downlinks that the parameter “timing” is always set as “DELAY” and I never see the word “IMMEDIATELY” as it should be for class C devices. Theses downlink frames are thus definitively not handled as class C downlink frames. The question is: why?
In addition to this, I have to say I have reproduced the same experimentation with The Things Network (even with The Things Stack). And it works well.
Hello!
I have faced similar problems but backwards, class A acting as class C
In my case it solved itself after I rebooted the whole chirpstack stack (rebooted after changing the class)
Hope this help!
Thank you for your help, @Digitalmosaw !
But unfortunately, this operation did not work for me… I work with Docker and after a reboot (with a stop command and even with a down command), nothing change. I still have the same behavior with my class C downlink frames.
Im sorry, the only things I could thing off is just remake the whole device profile again and adding the device again, if you actually configure your classes on chirpstack rigth then it should work
God luck!
AT+JOIN=1 //OTA JOIN
AT+CLASS=C // STM32WL SWITCH TO CLASS C
AT+SEND=0:0:00 // SEND A PORT 0 NO_ACK MESSAGE TO THE SERVER TO SEND PENDING MAC COMMANDS. (THIS WORKS FOR CLASS B.)
My error… Class C was checked in the device profile… It can’t operate in class C in running time.
One question/suggestion @brocaar. Would it be possible in the future set a Device Profile with Class B options and the device will choose in run-time if it will operate in Class B or C without the actual limitation? Is this a limitation only for STM32WL chipset or it is extended to other devices?
Another question: Does ChirpStack support the transition between Class C to Class A without doing a re-join?
