Excessive Current Consumption in Blank Sketch

No matter what I do, I cannot get the famed 10uA (or anywhere close).

Running the following sketch on a RAK4631 + RAK5005-O when powering the device via the 3V3 and GND breakout on the RAK4631 module results in an average current draw of 2.24mA (2.41mA max over 52ms). Current consumption measured with a Nordic PPK2 in Source Meter mode.

void setup() {
// put your setup code here, to run once:

}

void loop() {
delay(1000);
}

The microcontroller has the latest bootloader on it (Mar 31 2021 version) upgraded via BLE OTA DFU and confirmed via INFO_UF2.txt.

Using Arduino IDE 1.8.13, downloaded the board definition file and associated libraries not that long ago so they should be up to date as well.

Am I missing something?

Hello @cmod Welcome to the RAK forum.

The problem with the power consumption when using an empty setup() and loop() is simple.
The RAK4630/4631 has an SX1262 LoRa transceiver. This chip goes after power up in the status STANDBY which is not the lowest power consumption state of the chip. See paragraph 9.8 of the SX1261/2 datasheet:
image

You have to initialize the communication to the SX1262 and send it to SLEEP mode.

To do this, you need only two lines of code:

lora_rak4630_init();
Radio.Sleep()

You should get much better result when you add this two lines.

1 Like

Hello @beegee, thank you for your warm welcome and advice!

Adding the code you mentioned did indeed help greatly, thank you. However the current consumption is still higher than I expect (see below). Any further advice?

Not much.
Keep in mind that this is not a standalone nRF52840. There are components on the WisBlock Base and WisBlock Core that always use some current.

One SW proposal, instead of delay(), use xSemaphoreTake() to keep the MCU in sleep:

SemaphoreHandle_t loopEnable;

setup()
{
	loopEnable = xSemaphoreCreateBinary();
	xSemaphoreGive(loopEnable);
	xSemaphoreTake(loopEnable, (TickType_t)10);
}

void loop()
{
	xSemaphoreTake(loopEnable, portMAX_DELAY);
}

Another SW thing, but that is something difficult to control, is the Softdevice. Basically a firmware running in the nRF52 handling all the BLE stuff. How long did you measure? I see above 52ms. Try to measure longer. It takes some time before the Softdevice task goes to sleep as well.

From HW side, there is a voltage divider on the Vbat to read the battery voltage. It is 1M Ohm / 1.5M Ohm (R3 and R4 => schematic), so should not make much of a difference.

Thank you very much for your support and quick replies, they are very much appreciated.

I tried running the code you supplied on top of the previous code you gave me, leading to the sketch below:

#include <LoRaWan-Arduino.h>
#include <LoRaWan-ISP4520.h>
#include <LoRaWan-RAK4630.h>
#include <SX126x-Arduino.h>
#include <sx126x-debug.h>
#include <SX126x-ISP4520.h>
#include <SX126x-RAK4630.h>

SemaphoreHandle_t loopEnable;


void setup() {
  lora_rak4630_init();
  Radio.Sleep();

    loopEnable = xSemaphoreCreateBinary();
  xSemaphoreGive(loopEnable);
  xSemaphoreTake(loopEnable, (TickType_t)10);

}

void loop() {
  xSemaphoreTake(loopEnable, portMAX_DELAY);
}

Aside from eliminating the peak where the microcontroller wakes up, the average current was still ~450uA. Unfortunately the PPK2 software only lets me see 52ms windows at a time, but even after letting it run for >30s the average current stayed pretty much the same.

It’s worth noting for general knowledge’s sake that I saw no appreciable difference in current consumption between using the code you provided versus just using the radio init and sleep code plus delay(x) in the main loop, even including the consumption peak from the microcontroller waking up every x ms. So interesting outcome there.

Any chance you have run a similar power consumption study before to compare this against? Any idea if this current consumption is within what is expected?

I also tried the same study, same code, but with only the Core module (separated from the base) but oddly saw roughly twice the average current draw by doing so, 450uA->850uA. Strange!

I made some basic investigations, but they are more looking into LoRa P2P mode:
How to Reduce the Power Consumption of WisBlock Solutions?

The best I got at that time was 120uA.

When did you receive your RAK4631? On the first batch of modules there was a design error, causing higher power consumption. It was caused by U2 (an EEprom chip) assembled on the bottom of the module.
image

Can you check if this spot is empty on your module?

That is my last idea.

My PPK2 gives me all sorts of options both in the application window & for export of data running to hours, or if I sample too fast, hundred of minutes.

I know this doesn’t necessarily help get the current down, but it’s so much easier to debug if you have a full picture.

@nmcc great point, I’ll see about getting a longer capture to see if it clears things up, however I think even with the 52ms window after waiting >30s, with a very low trigger threshold, I should still be getting an accurate average reading.

@beegee Thank you again for your responses. Unfortunately, U2 is indeed empty and unpopulated. I greatly wish I could get down to at most 120uA, that would be sufficient for the future projects I had in mind I believe. Is there any chance you could provide the sketch you used to get that value, or better yet, the sketch and compiled .hex file? Then we could compare apples to apples and make sure there isn’t something else going on.

This is all in the name of discovery for our product line that would use the WisBlock Core for hundreds of devices if this prototype shows promise, so anything you could do to help make that a reality would be appreciated.

You can try this piece of code RAK4631-DeepSleep, but it is LoRa P2P only, not LoRaWAN!

When set to TX only mode, I get 45uA


When set to RX mode, I get 4.9mA

Not for the sleep if you’ve got that 5mA spike in it - it will distort the average considerably.

Overall the silicon manufacturers are in some bizarre arms race of low current mode in the same way everyone likes to boast about the GHz their CPUs run at - it wouldn’t surprise me if we had a Volkswagen style scandal come up at some point about someone rigging their results via some bizarre mode they built in behind the scenes.

I’ve just done a project where the Rx1 delay time on TTS v3 (now at 5s) turned out to be using 20% of the overall battery consumption. So we concentrated on that as it was a waste to leave the MCU running at full speed twiddling its thumbs.

But rather than shooting for the moon, what’s the use case, what power source will you have? I’m happy to help with the calcs on battery life.

Thank you both again for sticking with this, don’t give up on me!

I uploaded LoRa-DeepSleep-Ard, uncommented #define TX_ONLY, and uploaded it to the board. I then removed the USB from the board.

Then, while powering the board via the PPK2 at 3.3V using the Core’s header pins I captured roughly 30s of data (downloadable here), enough to see 4 TX current peaks and plenty of sleep time in between. To summarize the data, over the ~30s period the average current is 888uA, with a minimum sleep current of 557.8uA. Letting the setup run over a longer period of time (several minutes, with 1 minute FIFO), the average current does not improve, hovering around 840uA average over a 60s window, with minimum currents of ~475uA.

With Enable DUT power output off, the PPK2 reads an average of ~40nA, just FYI.

The use case in mind is a generic sensor node that can be configured to use various sensors, with various sensor polling and LoRaWAN reporting times running on a large non-rechargeable lithium-based battery, intended to last multiple years in the field. The device would utilize the RAK4631 core, with a custom base to do this.

Once we solve this current issue (if it can be solved) I’d definitely greatly appreciate your help with battery life calculations later on.

Well that’s the sixty million dollar answer - the base board provides a lot of different facilities for power, recharging, UART etc.

It’s a bit tricky to do so, but if you take a couple of AA batteries and wire them directly in to the RAK4630, you’ll get much much better results.

I agree, developing a base PCB to implement the peripherals I want while remaining low power is certainly a feat in and of itself, which is why I’m really trying to nail down expectations now.

So far I’ve been reporting values for the starter kit (core + base), powered off of the core’s 3V3 and GND pins with the PPK2 at 3300mV. When I try to power just the core (detached from the base) using the same sketch without reuploading, I don’t see the LoRa functionality or any other peaks aside from the startup current peak. (see below). Am I doing something wrong? Please let me know if I should make another thread for this.

Not sure what exactly the problem with your WisBlock is.
Just two thoughts:

  • Did you try to power the module over the battery connector (like I showed here)? Because you are sourcing the system on the wrong side of the power regulators and I am not sure what leakage you can get with it.

  • Running the RAK4631 without the base board, just supplying with 3.3V should work, but to be honest, I never tried it. I will give it a try later today.

Disregard and do not setup the power supply of the RAK4631 as shown below. It is not safe to use it.

The RAK4631 is designed to work with a WisBlock Base Board only and needs VBat and 3.3V supply to work correct.

About running the RAK4631 without the base board. I just tested it and it works just fine.
Required connections:
3.3V, GND (obvious) and RST pulled to 3V3.
RST is not pulled up inside the RAK4631, so without pulling it up, the MCU doesn’t start.

I tested a new firmware for low power consumption that connects to LoRaWAN server. So it is not like LoRa P2P.

Getting ~7.6 uA when running the RAK4631 separate from the Base board. LoRaWAN join and packet sending works:


Woo Hoo!

This is definitely in the good enough zone to crack on - there may be some optimisations to do with disabling the serial and other peripherals on the MCU, but that’s definitely in the zone.

To put it in context on doing low power on a board with ‘bits’ on, the best I can squeeze out of an Arduino MKR WAN 1310 is 13uA after I’ve detached all the voltage reg / battery charger etc circuitry.

If you need a voltage regulator to cap any over zealous batteries, I use the MCP1703 from Microchip - adds just 2uA to a sleeping device and is cheap & easy to implement.

Further context, the self-discharge of good Alkaline AA batteries is ~10uA.

That’s fantastic! Running my own experiment using the same plain-LoRa TX only send sketch as before but with RST pulled high this time led to a sleep current of ~16.5uA! Exciting stuff, truly. As nmcc said it seems the core will be sufficient for projects moving forward.

@beegee could you please let me know the low power sketch you’re using for LoRaWAN? I’ll need to tackle that soon for the final application I’m developing.

After that, I’ll start tackling getting ultra low power using BLE as well. Any tips there would be appreciated, though I might make another thread for that.

Thank you so much for your help everyone, if I hit another wall I’ll be sure to reach out again. Likewise @nmcc I’ll let you know when I could start using battery estimations, thank you again for your offer there as well.

@cmod

I will share the code on my Github repo. But I have to write some documentation first because it includes a lot of different stuff.

  • Fully event driven, no delay() or endless running loop()
  • Separation of user app and LoRa/BLE event handling
  • AT command interface to setup LoRaWAN credentials
  • BLE interface to setup LoRaWAN credentials
  • Programmable periodic user function call every xxx milliseconds

And the code is made a PlatformIO project. I didn’t try it yet with Arduino IDE.

1 Like

@cmod
Documentation is far from complete, but I put the code I used during the power measurements in my Github repo

It is for sure not a simple and easy to understand code, but it tries to have LoRaWAN and BLE standardized (like an API) so that the user can concentrate on the main application.

@beegee Thank you! Seems like an excellent framework, looking forward to giving this a shot. If you’d like, I can return with some current measurements using that code here, or send them to you some other way if you’re interested.