I have RAK3172, flashed with RUI3 and am trying Arduino LoraWan OTAA example sketch. The device is outputting multiple Restricted_Wait_3335681_ms messages, what are those?
Hi @ec3 ,
When do you encounter this output? If only when you failed joining the network, then there is nothing to worry about. You just have to ensure that the EUIs and KEY are correct and you ware within a working LoRaWAN gateway.
We have seen this when network is not joined After looking further into RUI3 on github it appears this message comes from the underlying STM32W lora service component.
Another error we are seeing is AT_BUSY_ERROR returned when trying to send AT commands to the 3172 while it is trying to join the network. Can you explain when AT commands are not allowed (thus returning AT_BUSY_ERROR)? Something appears to be blocking the AT system during the join process. Problem we see is that if the system is setup to auto-join and the eui and key are not correct (and need to be changed with AT command) then join timeouts and retries may prevent access to the AT commands required successfully join a network.
Hi @ec3 ,
I understand your concerns. I have some insights that hopefully will be helpful.
The restricted wait is not under STM32WL middleware. It is implemented under our RUI3 firmware to follow the rules of Retransmission back-off. We can’t just send continuous Join Uplinks all the time since that is damaging to the network.
Regarding the AT_BUSY_ERROR, while the node is attempting to join, you wont be able to change the LoRaWAN parameters. This is until the failure of join is recognized. After join failure callback, you have a short window to change it. This is until a new join attempt is initiated.
You can see what I mean on the image.
You are basically trapped in this line of code if you can’t join the network.
You can implement some routine on what to do in case of failure to join the network after certain number of attempts and not get trapped on this infinite loop. Even though you can access the AT commands, you will be limited because Join is being initiated infinitely.
There can be different ways how to navigate this situation with the flexibility RUI3 APIs, together with the availability of AT Commands 
If there are issues or bugs you encounter, just let us know and we will fix or make a workaround.
Continue on this topic, may I confirm in RUI3 if e.g. Restricted_Wait_30790820_ms appears during too many fail to join attampt (api.lorawan.join()), the device will join network again after ~8.5 hour?
Which means the device will simply stop sending OTAA request for the next 8.5 hour until the Restricted_Wait condition is clear, than back to sending join request?
Also I observed that if the event Restricted_Wait appears, the device cannot go to sleep mode, consuming around 5mA for the bare module.
Hi @chansheunglong ,
You are correct that the module will stop joining. However, on the RUI3 LoRaWAN example, the device will not go to sleep so it will consume few milliamperes.
To lower the current, you can add sleep API command on the joining routine.
while (api.lorawan.njs.get() == 0) {
Serial.print("Wait for LoRaWAN join...");
api.lorawan.join();
delay(1000);
api.system.sleep.all(9000);
}
To illustrate, I used here a delay of 1000mS, you can try to make this lower but not too low else there will be undesirable side effects on the join API (likely it will not proceed on restricted mode).
At 9000mS sleep, I can get an average current of less than 700uA. This is not really low for battery powered application. So you still have to optimize it. For example you can try to join for 10minutes with 10 seconds interval but if it fails on that duration, your joining attempt can be much longer (join every 1-min, 10-mins, 30-mins, etc.) since it will be now in restricted mode. This can potentially make the sleep of current of the device less than 10uA.
