Wireless Stick Lite Low Power Mode

Hi All,

I recently got a Wireless Stick Lite board for prototyping a Lora end device. Previously was using a WiFi Lora 32 (v2).

The board does in general consume less power. But when tested the deep sleep mode in the provided in the examples (same code @Supporter used here WiFi LoRa 32(V2) deep sleep low power test) I get about 2.67 mA when the board is powered from a 3.7v 750mAh RCR123a battery. The description claims 35 microAmps in deep sleep mode.

Only changes I made to the example was disable the display in the Heltec.begin() method, since this board doesn’t have a display and I increased the sleep/active period to 30 seconds, so I have some time to read the values from my multimeter.
In active time, the board is drawing around 44mA.
Setting RTC peripherals to sleep also didn’t make much difference. Is there anything specific that needs to be configured besides running that test?


After some more changes I can get to about 1.5mA in deep sleep. But I don’t think the 0.35uA is achievable unless you can run some of the code in ULP processor and that isn’t trivial to do.
So at this point I don’t think any of the ESP32 are suitable as battery operated end device.

I don’t think there is any chip with a low power mode that can reach 0.35uA.:smiley:

But we did get a sleep current of 30uA in the low-power test of Wireless Stick Lite.
Have you updated to the latest low-power example, or did you choose the right board?


Sorry, I meant to say 35uA. Could you provide a link to the latest version of the example? I believe I am using the latest one, I copied it directly from the repo here:

I am not sure what in the example would be specific to the stick lite.


I have tested this example.
It works fine.
When using a 3.7V 1A lithium battery, the current is about 30uA.

Please check again if it is a development board selection error?

Hi! Im messuring the battery live of the wirless stick, I get as low as 14uA of consumption in deep sleep(with a bit of extra code to the standar low power example from heltec), but im a bit lost, what is the most optimal way to calculate the battery life? When its on, it uses 67mA, with the led on, 45 with the led of and 150-180 when LoRaWAN is transmitting. I calculate a working time of one year but the battery depleted in 6 months, could some one give me a hint on how to do it properly? I can only upload one img, so i will upload the image showing the 14uA

and here is the set up

and the last one, with the led on

I have a wireless stick lite also.

The firmware says to connect a MOSFET between GPIO21 and Vext.
Is this necessary? Does it mean this has been designed into the Wireless Stick Lite?

I seem to be able to get 30uA without connecting a MOSFET anyway, pretty good!

please refer the picture:

Hi, I can get low power mode working well.
However, I can’t get the LoRaWAN example to go to the same low power state.

Here’s the low power example that gets the board down to less than 30uA:
. https://github.com/HelTecAutomation/Heltec_ESP32/blob/master/examples/Low_Power/Low_Power.ino

Here’s the LoRaWAN example with deep sleep, but it does not sleep at 30uA, but much higher.
. https://github.com/HelTecAutomation/ESP32_LoRaWAN/blob/master/examples/OTAA_Battery_power/OTAA_Battery_power.ino

Is there another LoRaWAN compatible sketch that deep sleeps at 30uA and has all the necessary bits to work with TheThingsNetwork etc? Or do I have to port some of the sleep and wake library calls from the ‘Low Power’ example to the ‘LoRaWAN’ example?


could you try this code:

1 Like

Apologies, I don’t know what I had wrong before but both the OTAA.ino and OTAA_Battery_power.ino examples are getting down to the 30uA now!
All good.

Its really a big problem! I have more than 200 of wirelles stick lite, around 40% works fine. The others have much higher power consumption. I have no answer from heltec about this issue yet. My supplier just bought 50 new boards and had just 30% working around 30 uA.

N Current (mA)
1 0,07
2 0,06
3 0,07
4 0,06
5 0,07
6 0,01
7 0,01
8 0,05
9 0,01
10 0,01
11 0,03
12 0,01
13 0,03
14 0,02
15 0,03
16 0,04
17 0,01
18 0,15
19 0,09
20 0,36
21 0,11
22 0,12
23 0,09
24 0,09
25 0,26
26 0,11
27 0,10
28 0,15
29 0,36
30 0,12
31 0,20
32 0,11
33 0,31
34 0,31
35 0,11
36 0,13
37 0,40
38 0,15
39 0,24
40 0,27
41 0,15
42 0,14
43 0,35
44 0,17
45 0,42
46 0,41
47 0,21
48 0,30
49 0,12
50 0,32

Could you tell us which code you are using and your test method?

For the last 50 the test was your Low_Power method.


  • HelTec Automation™ Low_Power test code, witch includ
  • Function summary:
    • Vext connected to 3.3V via a MOS-FET, the gate pin connected to GPIO21;
    • OLED display and PE4259(RF switch) use Vext as power supply;
    • WIFI Kit series V1 don’t have Vext control function;
    • Basic LoRa Function;
    • Esp_Deep_Sleep Function;
  • by lxyzn from HelTec AutoMation, ChengDu, China
  • www.heltec.cn
  • this project also realess in GitHub:
  • https://github.com/HelTecAutomation/Heltec_ESP32

#include “heltec.h”

#define uS_TO_S_FACTOR 1000000 /* Conversion factor for micro seconds to seconds /
#define TIME_TO_SLEEP 10 /
Time ESP32 will go to sleep (in seconds) */

#define BAND 433E6 //you can set band here directly,e.g. 868E6,915E6

RTC_DATA_ATTR int bootCount = 0;

Method to print the reason by which ESP32
has been awaken from sleep
void print_wakeup_reason(){
esp_sleep_wakeup_cause_t wakeup_reason;

wakeup_reason = esp_sleep_get_wakeup_cause();

case 1 :
Serial.println(“Wakeup caused by external signal using RTC_IO”);
} break;
case 2 :
Serial.println(“Wakeup caused by external signal using RTC_CNTL”);
} break;
case 3 :
Serial.println(“Wakeup caused by timer”);
} break;
case 4 :
Serial.println(“Wakeup caused by touchpad”);
} break;
case 5 :
Serial.println(“Wakeup caused by ULP program”);
} break;
default :
Serial.println(“Wakeup was not caused by deep sleep”);
} break;

void setup(){
//WIFI Kit series V1 not support Vext control
Heltec.begin(true /DisplayEnable Enable/, true /LoRa Disable/, true /Serial Enable/, true /PABOOST Enable/, BAND /long BAND/);

//Increment boot number and print it every reboot
Serial.println("Boot number: " + String(bootCount));

//Print the wakeup reason for ESP32

First we configure the wake up source
We set our ESP32 to wake up every 5 seconds
esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
Serial.println(“Setup ESP32 to sleep for every " + String(TIME_TO_SLEEP) +
" Seconds”);

Next we decide what all peripherals to shut down/keep on
By default, ESP32 will automatically power down the peripherals
not needed by the wakeup source, but if you want to be a poweruser
this is for you. Read in detail at the API docs
Left the line commented as an example of how to configure peripherals.
The line below turns off all RTC peripherals in deep sleep.
//esp_deep_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);
//Serial.println(“Configured all RTC Peripherals to be powered down in sleep”);

Now that we have setup a wake cause and if needed setup the
peripherals state in deep sleep, we can now start going to
deep sleep.
In the case that no wake up sources were provided but deep
sleep was started, it will sleep forever unless hardware
reset occurs.




Serial.println(“Going to sleep now”);
Serial.println(“This will never be printed”);

void loop(){
//This is not going to be called

we will testing your code. and result will be got tomorrow.

1 Like

We take your question very seriously. we have tested it. it works fine. here is our test pin connect:

could you confirm it?

Yes, we have used the same pin connection. How many boards did you tried? As I said these last 50 boards just have arrived and the % of successeful was really bad. In the other hand I have already many working in my industrie and I have many cases with high consumption. If you want we can make a video call where I can show to you. Or make a video, as you wish. We just wanna solve this problem as soon as possible.


Because of the network, we use online video calls here to be more lagging. We hope you can shoot a video. Please be careful not to touch the pins with your hands during testing.