Hi everyone.
RAK3172 - Using RUI3, latest version
So to understand per the docs:
UART2 is used for communication firmware etc wise
What is UART1 used for? Defining “serial1” and outputting to it does nothing when we hook in on serial1
We are having issues that UART2 consumes alot of power, but if we set the pins to low, no command is executed after this on the device. Currently, we are awating a lorawan join - IF successfull, set RX on UART2 to low. This however stops any further code execution. The test we are running is from the lorawan low power mode example.
Hi.
Issue is we have ch340 on uart2, and a led. Whenever we run off battery the led is still lit because uart 2 is giving 3.3v. Setting it to low solves it but stops executing code then
RAK and CH340 share supply via our TP converter 5/3.7V down to 3.3V. but there is a specific switch for the CH340 supply, which runs via a jumper.
So according to your schematics with the red cross outs - those connections are already cut
“Sensors disconnected”
You mean physically removed or put into low power mode?
Not sure where the consumption is coming from. I had a look into your code, nothing special there.
On a RAK3372 WisBlock Core, I get 23uA sleep current, partly coming from the CH340, because we don’t did what I proposed to you, it is powered by 3.3V.
I never touch the GPIO’s directly, RUI3 is quite good to keep the power consumption low.
I’m working with Kevin on our custom RAK3172. As he mentioned, we’re experiencing an unusually high current consumption. Initially, we thought it might be due to our PCB design (and there might still be something there we can optimize). However, I created a simple sleep code—no use of LoRa, just sleeping for 15 seconds, waking up to blink once, and then going back to sleep.
On the first sleep, the current drops to around ~10 uA (our instruments aren’t super accurate in that range, but it gives a general idea of the consumption). After the first sleep, though, it won’t go below 0.35 mA, which is a big difference. That said, compared to the first code Kevin provided, it’s still much lower. What we don’t get is this: when we add the LoRa part, do the sleep and all, it still won’t go under 7 mA, which is even higher.
Given our custom PCB, I’d accept that it’s not perfectly ideal—but clearly, it’s still possible to go below 0.35 mA. What we don’t understand is why we can’t utilize sleep in the same way when LoRa is involved.
Hope the question makes sense?
Here’s the link to the test code, just for making it sleep:
I am not a trained software engineer, but I am quite familiar with RUI3.
A few changes in above code and the current consumption goes down to ~22uA.
This is on a WisBlock Base Board RAK19003 with a WisBlock Core Module RAk3372 (uses RAK3172 WisDuo module). These WisBlock modules are not fully optimized for low power consumption, that’s why I am getting such a high sleep current.
I left comments in the code what I would never do when using RUI3.
no need to force unused GPIO to LOW
never disable SERIAL, this stops any AT commands from being accepted and it does not save any power. SERIAL is using UART2, which is set into low power mode already. It wakes up the system on incoming data, otherwise it is in low power mode.
What I do for lowest power consumption with RUI3
if LoRaWAN is not needed (like in this example code), initialize it, but stop automatic join
I have been testing all day with the adjusted code (Simple_Power_Test_RAK3172.ino) and the removal of a power LED (we had added to the CH340) as well as the removal of the CH340 itself. With these changes, I managed to bring the current consumption down to ~7 uA on our own board, which is great!
However, when I try to use your RUI3_LowPower_Example.ino, the current doesn’t go lower than ~0.7 mA. It seems that as soon as we start using the LoRa functionality, the consumption rises—even when the module is supposed to be in sleep mode.
I’m brainstorming here: could this be a firmware issue? I can’t see why everything works perfectly in the simple power test (~7 uA), but as soon as we use LoRa, the consumption jumps. There’s nothing else on our PCB that could cause this, which is why I’m guessing it might be related to the firmware.
Hi Bernd. Thanks for your help. I’m unsure aswell. Without LoRa we are down to 8-10ua, but as soon as we use the lora low power example our sleep rises significant.
I want to thank you for your help with our power consumption issues. You certainly pointed us in the right direction. Some code rework and the removal of the CH340 from the PCB helped bring the consumption down to ~15uA. I’m not entirely sure what in the code was causing the issue, but after reworking it, everything is now perfect.
Once again, thank you — we truly appreciate your support.