Deep sleep consumption

I am trying to get to lowest possible deep sleep consumption for my Heltec Wifi Lora V3.2 module. With following code I am getting around 135 µA and I think it is possible to be at 15 µA. I would super grateful if anyone here could help me and see what else I can do or turn off? Here is my deepSleep code:

void gotoDeepSleep(uint32_t seconds) {
// Power management for LoRa and peripheral components
Serial.printf("[%s] Preparing for deep sleep for %lu seconds\n", getCurrentTime().c_str(), seconds);
Serial.flush();
// If display is disabled, turn it off completely
if (!displayEnabled) {
display.displayOff();
}
VextOFF();
// Power down LoRa module
Radio.Sleep();
SPI.end();
// Set all LoRa pins to analog to save power
pinMode(RADIO_DIO_1, ANALOG);
pinMode(RADIO_NSS, ANALOG);
pinMode(RADIO_RESET, ANALOG);
pinMode(RADIO_BUSY, ANALOG);
pinMode(LORA_CLK, ANALOG);
pinMode(LORA_MISO, ANALOG);
pinMode(LORA_MOSI, ANALOG);
// Disable I2C bus for MPU6050
Wire1.end();
// Disable voltage monitoring
digitalWrite(ADC_CTRL, LOW);
// Disable WiFi and Bluetooth
esp_wifi_stop();
esp_bt_controller_disable();
// Configure wake sources
esp_sleep_enable_timer_wakeup(seconds * 1000000ULL); // Timer wake
esp_sleep_enable_ext0_wakeup(GPIO_NUM_0, 0); // Button wake on LOW
// Enter deep sleep
esp_deep_sleep_start();

// Code below only executes if deep sleep failed
Serial.printf("[%s] Sleep failed, forcing restart in 10 seconds\n", getCurrentTime().c_str());
delay(10000);
ESP.restart();
}

Remove the button wake and you’ll be at the promised ±15uA. Pin wakeup increases the sleep consumption by a lot unfortunately. If you find a way to use pin wake-up and still achieve double-digit currents, please let us know!

1 Like

@bns Thank you! Yes, to confirm - after removing Button wake - I am ranging from 14 to 18µA. Its too bad that button wake is so expensive! I will work on it and let you know if I find a better way. I also curious that during my LoRa transmission even with TX_OUTPUT_POWER set to 1 the consumption spikes for 10 millis at 420mA! Thats alot, I wonder if TX_OUTPUT_POWER setting does anything to change it?
One more thing, is there a way to hold a GPIO pin high during deep sleep? I can’t seem to find a Heltec library equivalent for gpio_deep_sleep_hold_en()

Thanks!

Yep… that sucks. It would probably double the battery life of one of my devices if it wasn’t that bad. Not sure it’s something with Heltec hardware or inherent to the ESP32(-S3); I haven’t properly dug that deep yet.

Frankly, I have never bothered to use the LoRa(WAN) stuff from Heltec, but rather use RadioLib because it provides much more feedback on what is happening and is much better documented.

Heltec’s framework is built on top of the Arduino-ESP32 framework so in general, all normal functions are available. You may need to check if you’re running the newest version of Heltec’s framework to catch up on newer functions. Otherwise, which is a bit of a learning curve but IMO a useful one, ignore the Heltec framework and consider your Heltec hardware as a normal Arduino-ESP32 board. This may require you to do a bit of digging around because some examples may need modifications or you need to find pinouts yourself, but it means that you can always use the latest & greatest.
But, if you’re uncomfortable with that, I can understand you may want to stick to the Heltec framework. Sometimes it’s just a bit difficult to work around limitations like these.

1 Like

Perhaps hit the reset pin - given that’s the same as coming out of deep sleep and is how it is done for the ESP8266?

NO! You’d lose all the RTC RAM.

1 Like

Thank you for the heads up! Yes, I will most likely transition to RadioLib as well. Also, might checkout unofficial_heltec_library and see if it is better documented. I agree with your approach to be more Heltec free as support is not there.

Ha, ha, ha, ha, ha, bonk - that’s me laughing my head off.

Who do you know who wrote the (majority) of the RL LW code?

And who do you know who wrote the manual for LW on RL?

And which people do you know that answer LW on RL questions typically same day?

But sure, go via a third-party layer that bundles RL that the RL peeps don’t support because it’s an unnecessary complication to something already complicated enough.

If you do anything with it, I’d just pull the display code out.

The stuff works, but as I’ve said else where, we don’t really pay enough to fund support.

The main reason for going RL is that the stack is more up to date & compliant.

See Good news regarding power consumption for pin-wakeup from deepsleep for the solution.

1 Like

@bns thank you!! I will test it soon and see how it works with my solution. Thank you!!