ESP32 low power modes.  Need some WIFI and I2C - Page 1
Forum section: electronics / general

author: viper
author_rank: Regular Contributor
timestamp: September 30, 2025, 04:54:34 am
content: Hoping someone can answer. I have a 2 part question so I will break this down below. I'm not dead set on the plan, but this is where I am "today". The basic need is to maintain I2C connection and some sort of wifi contact.1. Wifi. I would be using a sort of IoT device where battery life is important, but also need to connect and send info packets every 1min at times, and others about 15min. It's very obvious that leaving an ESP32 in shi* hot mode will eat power. What I'm trying to figure out is because of that, the first thing to get ditched in power conservation modes is wireless. I read of the beacon approach, but not familiar. Basically what are my options here?2. Also have I2C ICs I will connect, and will need periodic data from them to monitor the playground. Is there a way to keep I2C active in the ESP, or is the best route to plan to lose I2C and have to constantly wake the MCU to get the data? I'm talking like a 2-3 register pull every 2-3min. Probably a bigger part of the picture is I am stuck with a charger IC that will default to unsafe factory settings unless I either reset the watchdog with a checkin, or I disable it in I2C. Just trying to build a strategy here.3. there are only a couple things that should cause a true wake up, and none are uS speeds. I've could prob lose 10-20mS and never know it. Basically an inductive sensor sends signal to a GPIO that something is running. That tells the system to wake up and pay attention.

author: woofy
author_rank: Frequent Contributor
timestamp: September 30, 2025, 09:00:52 am
content: Use MQTT.I would keep the esp32 powered, but in deep sleep mode and waking up periodically to check the MQTT broker. It can publish any data it collects and receive new instructions/data. One of the instructions it picks up could be the time delay to the next wakeup, 1min or 15min.I've had a project running 18 months on 3 AA cells, waking up every two hours and reporting data back. On my system (it's an oil tank level monitor) it takes about 1 second to powerup, log-on and send its data.

author: hans
author_rank: Super Contributor
timestamp: September 30, 2025, 11:56:51 am
content: Indeed, look at deep power sleep.There are few "complaints" from my side on ESP32 notorious power usage:- Keep the duty cycle of radio as low as possible. It is a giant power guzzlers. BT is a bit better, but there are far better MCUs than ESP32s which can do this (e.g. Nordic of SiLabs MCUs)The newer ESP32s do support TIM (traffic indication map). This allows the WiFi Modem to periodically sleep and have frames cached by the AP. This increases latency quite a lot (ping times of up to 100ms) but I did see a drop from 80mA to 20mA on ESP32-C3. Nice savings, but for a bursty LAN transfer (e.g. MQTT broker) not that useful IMO.- The deep-sleep features requires a full device reboot (in contrast to many other MCUs). It also forgets all state except for data stored in RTC RAM. Noteworthy: the ESP32 bootloader is very slow, in the order of 200ms+. This might be a problem for 3) if you need to respond to some GPIO event in lets say a few 100ms.- I'm not sure what you mean about keeping I2c active. The bus should idle with external pull-ups and then consume virtually zero power.Indeed, I've also achieved similar battery lifetimes on 2 AA cells in the order of a 1 to 2 years. I'm not sure what low power (or energy) requirements you specifically have.One trick to keep the wake time of radio as short as possible, is to configure your AP to a fixed WiFi channel. You can pass down the channel# as an optional argument when you connect to an AP. When I tried this with Arduino's WiFi libraries this was a bit buggy (few years ago), but using ESP IDF commands directly did make the connect times a lot shorter. If you don't pass the channel# it has to do a spectrum scan and wait for APs to send a beacon frame. This could take over 3 seconds. With direct channel# I saw connect times in the order of 300-500ms.

author: xvr
author_rank: Frequent Contributor
timestamp: September 30, 2025, 12:04:34 pm
content: ESP32-C6 support WiFi6 with Target Wake Time (TWT) feature. It can significantly reduce power consumption (by periodically going into sleep mode) while keeping the WiFi connection active. But it required WiFi 6 capable AP.

author: viper
author_rank: Regular Contributor
timestamp: September 30, 2025, 08:20:40 pm
content: Quote from: woofy on September 30, 2025, 09:00:52 amI'd be curious what level sensor you chose!As for my issues, I will admit I know very little about MQTT and need to get up to speed! There are just a lot of check marks to apply. As it stands, the collected data would stay in RAM, periodically wake up, send that data as an 'update', receive an ACK that it was delivered, and go back to some sort of sleep mode. This data somehow needs to make it back to our commercial server. I don't yet know if these 'brokers' are loaded on each target device? The data may go to a cell phone or router, as conditions allow. Is the deal with MQTT that technically no connection needs made, the radio just wakes and sends, and waits briefly for a reply (if desired)?As for battery, we would have a pretty robust 30Wh battery with solar charging.As for wake time and strategy, I have yet to find good documentation of all the power modes and what is possible in terms of what services go offline. The mention of the ESP basically doing a total reboot every time it wakes from deep sleep could be an issue, as well as the boot time through a boot loader?The main wake strategy is responding to a running motor in which an inductive sensor needs to capture the transient inrush, which normally only lasts for 150ms. I don't really need to know the precise duration, but know that inrush happened, what the peak was, and that the line returns to running amps. A wake strategy that takes 200ms won't work. I read somewhere that the ESP will wake from deep sleep in 1ms, but apparently I need more info on these modes.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 30, 2025, 09:00:02 pm
content: Yes, about using deep sleep on an ESP32, this is a nightmare - I confirm "boot" times over 200 ms.This can be fine for like a sensor node waking up infrequently with no wakeup latency concern, otherwise I might suggest to find another MCU altogether.

author: woofy
author_rank: Frequent Contributor
timestamp: September 30, 2025, 09:47:11 pm
content: Quote from: viper on September 30, 2025, 08:20:40 pmMy sensor is just a standard 40khz ultrasonic transducer, not even a waterproof one. The ESP32 does the ranging whilst the wifi is connecting to the server. I time the awake time of the ESP32 from boot to sleep. its typically around 1 second. That doesn't count the time from boot trigger to executing first instruction though. That may be >200mS as Siliconwizard says. I wake from a low power timer every couple of hours so don't really know.A 30WH solar connected battery is plenty of power for an ESP32, you can get down to 3mA in low power modem sleep which will allow you to continuously fetch the i2c data. You can power up and connect to wifi, send the data and then go back to low power.

author: viper
author_rank: Regular Contributor
timestamp: September 30, 2025, 11:00:47 pm
content: Thanks guys! I found some more info on power modes and such and it seems deep sleep is probably not practical for this but does seem that the combination of modem sleep and light sleep can keep the power budget in check. What I am working out is head room or redundancy for the energy calcs.It seems like the right approach is to excuse the desire to keep I2C alive, and just turn it on to gather data, and turn back off.As for the IC that wants to reset itself if I2C is lost, I can disable it's watchdog timer to keep I2C settings, then further disable the chip with a GPIO as sort of a fail-safe approach as the IC will not be allowed to function unless the ESP enables it. I think supervising that IC via the ESP is a safer approach.