I have around 50 devices in the field integrating the RAK4630 module, all of which have been working correctly.
Recently, I spent some time testing newer RUI3 versions. I am currently using version 4.1.1, and I have tested all newer available versions from 4.1.1. However, I’ve encountered some issues. With the exact same application firmware, incoming messages are unreliable: some messages are received correctly, while most of them are lost after the upgrade. Situation is reverted when I downgrade to 4.1.1 again.
Has anyone experienced a similar problem? Is there a known cause or a recommended fix?
If you can give us more details, it will be helpful so we can replicate and see possible breaking changes that affects your code.
Are you using LoRaWAN or LoRa P2P? Is the issue present in all modules you test?
If LoRaWAN, when you say most message are lost, does it mean that the uplinks are not received by the gateway (no uplinks sent to LNS). Any error you see on the serial terminal?
Is the packet loss at the same rate on joining or only when already joined (normal uplinks)?
Anything that might be related to transmit power or reception sensitivity?
Any simple code you use that replicates the issue even stripping other parts (sensor readings, display, housekeeping, etc.) aside from LoRaWAN? This basic code will accelerate debugging if there is problem in the rui3 itself.
I’m using Lorawan with ABP, class C, ADR disabled. Yes, it happens with all the modules I tested.
I have no problem with uplink messages (no message lost), the problems is with downlink (most of the messages are not received by the modules). Same behaviour for unicast and multicast.
Using ABP, so no message exchange for joining.
I don’t think it is related with transmit power or reception sensitivity. I have a test bench where modules and gateway are close together. Changing the firmware back to 4.1.1 without physically touching the module works without problems.
Unfortunatelly I cannot prepare the code snippet right now, I will try to do it along the week. What I realized is that downlinks are received only after uplink is sent ok, as if it is configured in class A. I double checked and the module returns “SUCCESS” to api.lorawan.deviceClass.set(RAK_LORA_CLASS_C).
Thanks for providing the details. These are helpful to understand the situation beter.
Some further thoughts/insight from my end:
To operate on Class C, you really need an uplink first. This is a requirement in the LoRaWAN specification. Once the first uplink is sent, it will switch to Class C.
What LNS (LoRaWAN Network Server) do you use and what LoRaWAN version (1.0.3 or 1.0.4)?
You confirm that class C is activated on the settings of LNS right (very likely since you said it is already working in 4.1.1)?
What specific higher firmware version did you upgrade it with? Right now the latest is RUI3 v4.2.2.
On the LNS when it starts failing, it is continuous downlink failure? Or erratic (random failure with mostly failed than pass)?
I will wait for the code so I can run it and verify. Once verified, I can forward it to our R&D team.
Thank your quick answer. Please, find my answers below:
This is clear. Device sends the first uplink 10s after being ready. The device still behaves as in class A.
I’m using Chirpstack v4.14.1 with LoraWAN 1.0.4. I’ve verified that messages are going out of the gateway.
Yes, in both RUI3 v4.1.1 and v4.2.2, it respons succes to class configuration. Not sure if there are any requirement on when the class configuration should be done. Anyway, I check with AT commands and answers that it is in class C.
I tested both 4.2.1 and 4.2.2 and I see no difference.
In my test set up, node is sending periodically an uplink. If just after receiving (<2s) the uplink in the LNS, I sent a downlink, the message is received. If I delay the downlink, the node doesn’t read the downlink. That’s what make my think that device is behaving as in class A.
I’m sorry for the delay providing a simplied test code for reproducing the error, but here you have.
I tested with 4.1.1 and dowlinks are read ok, with 4.2.2 downlink are only read if uplink (apart from the intial one) has been sent 1-2s before donwlink is sent.
If you need any further clarification let me know.