RAK3172 - UART2 / UART1

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.

UART2 is for AT commands and firmware updates.
UART1 is for custom usage, but in default mode, it accepts as well AT commands.

To use UART1 for custom usage, initialize it with

Serial1.begin(19200, RAK_CUSTOM_MODE);

You should not directly control the RX and TX pins, this is done by RUI3.
If you use low power mode with

AT+LPM=2

or from code with

// Enable low power mode|
api.system.lpm.set(1);

UART2 will be set to low power mode automatically.

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

How do you power the CH340? From the same supply as the RAK3172 or through VUSB?

If you are powering from the same supply as the RAK3172, try the following:

Change the supply as shown here:

Use

Serial.end();
udrv_serial_deinit(SERIAL_UART0);

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

OK! Following your step(s) + pulling low turns off our led.

You can see the code here, which uses your example as a base.

With this, I measured around 0.9ua, which is still quite high - And thats with all sensors disconnected…

0.9uA or 0.9mA?

0.9uA is really good in my opinion.

0.9mA. Sorry! Not 0.9 uA:P

It was measured to 0.9mA

“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.

Hello Bernd,

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
  • enable low power mode with api.system.lpm.set(1);

Here is my changed code
Simpel_power_test_RAK3172.ino (4.0 KB)

1 Like

Pulled out my RAK3272 Breakout Board (RAK3172 on a PCB, no external components)
Flashed the same code, supply directly with 3.3V

~2.4uA sleep current.

Hi! Thanks for that. And is it simillar when going to sleep, but lorawan is joined?

Yes, it is the same.

Not your code, but same setup. RUI3-LowPower-Example

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.

How do you setup LoRaWAN?
What LoRaWAN Class?
Does the device connect to a LoRaWAN server?

Hi. As the docs.
V 1.0.3
Class A
And yes - chirpstack. We are right next to the gateway

Sorry, I don’t know. Did you follow all my changes I showed earlier?

As shown here

I get low current with LoRaWAN enabled and connected to the server.

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.

Hello Bernd,

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.