Checklist for energy minimization on WisBlock

Hi All,

Attempting a wireless sensor application using WisBlock 5005/4630 with the RAK1906 sensor (BME680), in a simple receive-only activity using single-channel LoRa. It will get a little more complex later, but first I need to get the sustained RX current draw down. I’d like to see the idle unit drawing less than 1mA.

Right now my application seems to be drawing about 37mA. I started with the obvious by turning off the LEDs, but that made little difference. I’ve surrounded all the Serial calls with #ifndef #endif, but there’s still something pulling a bunch of current.

For context, here are my includes:

#include <Arduino.h>
#include <SX126x-RAK4630.h> //http://librarymanager/All#SX126x
#include <SPI.h>

I’ve been wandering randomly around the web , picking up an anecdote here and there, but haven’t found an overview of power reduction on the WisBlock platform. Any pointers or suggestions would be much appreciated!

Art

Just to be precise, I’m pulling 37mA at 4.21v on BAT. That seems right out of line with the datasheet specs… which say the baseboard should be pulling something in the uA range. So it seems something somewhere is pulling down a honking >20mA.

The datasheet for the 5005-o says “Idle current, with MCU and sensor are in sleep mode… 10uA”

So I guess what I’m asking is, what do I need to do to get from 37mA down into the micro-AH range?

2 Likes

Hi,
Power consumption is a difficult subject. Here are some things to check:

  • Early RAK4631 modules had a flash chip (on the bottom of the board) that caused excessive power consumption (70-120mA without BLE and LoRa enabled). The chip was removed but there might be some RAK4631 out that still have the flash chip. You can check if your boards have the chip or not:

  • The BME680 is not really a low-power chip, especially if you enable the gas measurement (requires the chip heater).

    • What library are you using? If you are using the ClosedCube BME680 library, there is a function to put the chip into sleep mode bme680.setSleepMode();.
    • If you are using the Bosch BSEC library it doesn’t have such a feature. As the BSEC library sources are not open-source, I cannot say if the sleep mode is used or not (my guess is that it is not used)
    • You can find some consumption values in the data sheet of the BME680.
  • nRF52840 and Arduino framework

    • It is quite difficult to put the nRF52840 into sleep mode when using the Arduino framework. There is some information in the issue list, but I guess you read this already.
    • We have an example how to put the nRF52 into deep sleep. It is for LoRaWAN, but the principle can be used for LoRa P2P as well.
    • Once BLE is initialized, the Arduino framework does not offer any function to shut it down completely again. There is no solution for this.
1 Like

Excellent links, Bernd. Thanks!

I’m holding my breath on the flash chip… could it be that simple?

I was all prepared to work out the management of the BME680 when this 20000uA appeared. Now it appears I must drill into FreeRTOS a bit first.

And thanks for the warning about BLE.

Alas, no flash chip on the 4631, but I did get an additional observation by removing everything from the base board. With nothing plugged in, the 5005-O draws 5uA with 3.3v applied to VDD… but with the same voltage applied to BAT, it jumps to a whopping 33mA.

Is that normal? It’s making me wonder about the health of the LDO.

As the SX126x chips consume depending on configuration 4 - 10 mA in receive mode, this simply isn’t going to happen.

The only way you can achieve your goal is to make reception non-continuous but rather limited to brief windows in time when you activate the receive preamble detector and see if there is a message; if there isn’t, you then go right back to sleep.

This requires time coordination between transmitter and receiver. Battery powered LoRaWAN nodes do it by means of the LoRaWAN contract, which says that reply transmissions are sent (depending on mode) precisely 1 or 2, or 5, or 6 seconds after the end up the uplink they are in reply to. So a node transmits whenever it likes, but only listens at two very brief points in time afterwards. All of that works, because the battery powered nodes are in communication with an always-on mains-powered gateway.

This is more challenging when it is the receiver which is battery powered. One approach is to have a mains powered transmitter which sends beacons frequently enough that a receiver can be put in an always-on “pairing” mode and by listening for no more than a minute, detect one of these unsolicited transmissions.

Once you have one transmission, with a known interval you can know when to wake up the receiver and try for the next - basically the expected time minus to plus an error allowance. If you don’t get the next transmission, then you try again at the next opportunity, but listen for longer as your error allowance must now be doubled. And then tripled. If you fail to get anything enough cycles in a row, at some point you have to declare failure and give up. Maybe you do nothing overnight and trigger another pairing attempt the next day on the theory the transmitter has been repaired; maybe you assume it has been taken out of service and don’t try again until pairing is manually re-triggered.

Thanks, Chris. Yes, I was looking at that sort of synchronized sleep approach when I became aware of RxDutyCycle, which does somewhat the same thing but at a lower level. However, 30+mA baseline even before I plug in the 4631 is a show-stopper for me either way. I’d like to use the WisBoard platform, but I can’t afford that much battery.

So my question right now is… is this normal for the WisBlock system? I have trouble believing it is, but if I can’t find a way to get down into single-digit mAs at most, I’m guessing it’s time for Plan B.

Hi Art,

Just to verify, you do not use LoRaWAN, correct?
You mentioned in the first post single-channel LoRa

With just LoRa I can get down to ~700 uA when I choose only TX and do not listen to incoming messages. When I use RxDutyCycle, I get between 5 and 7mA (depending how many other nodes are sending on the same frequency) but can receive LoRa messages from other LoRa nodes.

I cannot attach the example code for both ArduinoIDE and PlatformIO here, but you can get them from Github repo

The switch between TX only and RxDutyCycle is made in the file lora.cpp in line 14
To enable RxDutyCycle comment out the #define TX_ONLY

Keep in mind this does not any sensor readings. It is just sending a 14 bytes package every
10 seconds.
RxDutyCycle:


TX only:

Another improvement in TX only mode. Replacing Radio.Standby() with Radio.Sleep() brought the power consumption down to 100uA.

Again, this is not including any sensor readings nor was a sensor plugged in.

1 Like

Thank you, Bernd, for your work to help! What you’re showing is very much the sort of readings I was expecting… now I need only achieve them myself! If I can then my basic design using WisBlock gets a green light and I can work on the application code.

Yes, my application is simple half-duplex LoRa, no LoRaWan involved. I had to request access to your Google drive to access your code, but I’m increasingly suspicious of my 5005-O board… I have another one on order and hope to compare it soon.

Thanks again!

Art

Hi Art,
You say I had to request access to your Google drive to access your code?
Could you download the code?
If not, I can put it on my Github as a repo.

Thanks for the example, Bernd! With the 4331 mounted but no sensor, running the example code, that draws 38mA on my baseboard. I have another 5005-O on order, so we’ll know more when that arrives. Thanks again!

38mA is way too high. Please keep me updated when you receive the other RAK5005-O. If there is a problem with the base board we have to track it down.

I’ll take careful measurements on the new one when it arrives and let you know.

hi… its normal when in deepsleep i get around ~48uA? i use rak5005 with rak4630 only…

Seems other people are interested as well, so I put both Arduino and PlatformIO projects into a Github repo.

1 Like

That is a good value. There is a variation in the current consumption depending on the charging level of your battery. If the battery is at 4.2V you will get lower current, if the battery is nearly empty (3.6V) you will get higher current.

Good news, Bernd! My new 5005 arrived and, loaded with the 4631, it starts up at a very reasonable 4mA. So apparently I snapped a diode or something on the other one, which I’ll now retire to base-station use.

Thanks for your support. I’m very glad about this.

Art

1 Like

Hello Art,
That is indeed very good news. I am glad I could help you.