Datalogger uses ESP32 and ESP8266 Low Power Modes

[G6EJD] wanted to design a low power datalogger and decided to look at the power consumption of an ESP32 versus an ESP8266. You can see the video results below.

Of course, anytime someone does a power test, you have to wonder if there were any tricks or changes that would have made a big difference. However, the relative data is interesting (even though you could posit situations where even those results would be misleading). You should watch the videos, but the bottom line was a 3000 mAh battery provided 315 days of run time for the ESP8266 and 213 days with the ESP32.

The fact that the hardware and software only differ in the central processing unit means the results should be pretty comparable. [G6EJD] accounts for the current draws throughout the circuit. The number of days were computed with math, so they don’t reflect actual use. It also depends on how many samples you take per unit time. The goal was to get operation on batteries to last a year, and that was possible if you were willing to reduce the sample rate.

While we generally like the ESP32, [G6EJD] makes the point that if battery life is important to you, you might want to stick to the ESP8266, or look for something else. Naturally, if you are trying to maximize battery life, you are going to have to do a lot of sleeping.

35 thoughts on “Datalogger uses ESP32 and ESP8266 Low Power Modes

    1. G6EJD is my Radio Amateur call-sign and my alter ego :). It was the original 0 revision chip, I’ve not found many suppliers with Revision-1 devices. The sleep current is consistently low at 5.6uA across all 3 devices that I tried and I believe this is as a good as it gets, but for battery powered use that current level is not dominant even over many years and is probably less than most battery self-discharge currents. RF power consumption is the driver in my particular experiment’s outcome.

  1. Eep, 3 seconds active radio time to upload a handful of bytes of data? Work on that from two angles: Why is it taking 3 seconds—are you doing DHCP every time, say? Is the server just slow to respond to the request?

    If it must take 3 seconds, then at least gather up an hour of data to send, and squirt it all at once, so you have 3 seconds per hour instead of 18 seconds per hour (say). You’ve just saved about 80% of your battery right there.

    1. He’s using a cloud service called Thingspeak, which has REST and MQTT interfaces it appears. REST is going to be tossing around boilerplate in HTTP headers, and both of these are TCP protocols. On a really bad link I could see there being a crapload of resent packets. I could easily see DNS being in there, and if it’s sleeping for long times it may have just been assumed that the DHCP lease expires, or it isn’t stored at all for minimum battery use. If it was just me I’d be sending a single datagram with a secure hash for verification to a static IP. But I’m lazy as hell and would much rather use a PI or OpenWRT unit as a gateway bundling unit running a C app than try to interface with a web app from a device with no OS.

      1. This is where an intermediary would be of good use. I do the same thing with my power meter. I talk to my own server which sends out a single TCP message, and the server then later uploads to Thinkspeak for this reason.

      2. Or you can run a MQTT broker on your local box and use static configuration for all the sensors. And if you want to expose your sensor data to the Internet, then run a web server too…
        Anything cloud-based is a bad idea…

      3. Given someone further down the page is talking about saving values to the RTC memory so they survive deep sleep on an esp8266, the information from DHCP and DNS being lost in sleep and needing to be redone seems increasingly likely.

      4. (Hi I’m G6EJD) what I found was the ESP8266 was significantly more reliable and faster at making a network connection than the ESP32, yes in both cases using a DHCP assigned IP address and negotiating the TCP/IP protocol overheads. I did try using RTC RAM but the devices take such a large in-rush current, especially the ESP32 that without a low impedance regulator to provided the much needed stability the ESP32 barely operated thereby losing RTC RAM contents. I used the capacitor to help regulate energy demands, but the true value required (i.t=C.v) (where I, C and V are the delta current and voltage demands) of 10,000uF to provide sufficient energy demands during the initial transmit phases looked impractical, so a 10uF was a compromise, also the AMS1117 LDO regulator has a quiescent demand of ~3mA and that was a factor of 10 greater than the ESP32 average current demand, so it’s all a compromise; suffice to say the only difference between the two trials was the device. I measured mAh consumption with 0.1ohm shunt and a digital storage scope over a period of 48-hours to enable me to get the best possible average current demand with sufficient validation for the figures I quote of 74mA (ESP8266) and 115mA (ESP32) that enabled me to predict with reasonable degree of confidence the expected battery life. As I say in the video, the ESP32 is being marketed as a low power IOT device and I was surprised that I could not achieve better (IMO) battery life than I did.

        I also tried reducing RF output power and I assume the library call I used worked, but the result was no reduction in current demand, but (I have not measured it yet) I suspect RF output power is reduced. This outcome is not unusual for an RF output stage, where you can reduce the RF output power and yet the input power remains largely the same albeit efficiency drops-off markedly. My HF transmitter demands 16A at its full 100-Watt output and 12Amps on 10Watts and this is typical of a class-A/B RF output stage that I surmise the ESP devices are also using, but there is little or no published design data to verify my assertion.

        I note similar devices produced by Microchip offer far superior low power performance and these offer the solution I was looking for.

        1. I think what some of us were starting to wonder is how the math would have worked out for never going into deep sleep and having a larger sleep current draw in exchange for not forgetting the DHCP and DNS info while the leases and TTL are still valid resulting in a drastically shorter time using the radio (just one short TCP session).

          1. The power budget is 0.34mAh/day to last 1-year with a 3000mAh battery, so the maximum Tx time would need to be 1.8 seconds for a 10-min update rate and I’m currently near 3-secs. Yes it’s possible that not having to negotiate an IP before upload will be faster or by keeping the link active (although my experience shows for no more than 24-hours), but as far as I can see from Espressiff’s documentation it would need a low power mode that kept the link active but all their modes that use sufficiently low enough CPU power also shut down the WiFi / BLE, so I believe my trial aim is not feasible with this device. I will run a trial with a fixed IP though to see if that improves timing, but I’m beginning to wonder if the Thingspeak server may be the dominant part of the overall upload timing. I can get the ESP to record the timeline from wake-up to sleep, that may be of interest.

  2. but, how about storing the numbers in memory, if it’s not that different from the last measurement, and only sending if you accumulate 5 of them in a batch or if it’s very different from the last measurement then you might get 4 years of battery life. if you are detecting things like water leaks, you don’t have to send every hour.

    1. Bold claim right there, I’d like to know of a leak within seconds!
      Apart from potential optimisation of his algorithm, the title promised a comparison between the two systems, and it delivered exactly that.

      1. The problem with sensors that only communicate when something has changed is “nothing has changed” looks exactly the same as “sensor is dead”. I wouldn’t use something like that for anything safety critical.

        1. Agree. There’s no easy way to know if a battery failed, etc. My ESP8266 water sensor project checks in and reports battery voltage every 3 days. It wakes up hourly, increments a counter, and then goes back to sleep until 3 days have passed. A water leak will trigger the RST pin to wake up the ESP and in that case it reports in immediately. No check in for more than 3 days means something has failed. Of course, I’m using more circuitry to accomplish this than just what the ESP8266 is capable of.

        2. Agreed.. I try to avoid this situation. My ESP8266 project uses auto light sleep, and MQTT. I only get 2 weeks from an NCR18650, but i hope to couple that with a small solar panel to get me to infinity. not bad for real time.

  3. You can get much more battery life if you log a lot of data offline and only transmit rarely. Depends on the application if that is a suitable option, but by transmitting larger batches of data less frequently, you should reduce the modem up time which is a big consumer of power.

  4. I’m working on a similar project and are experimenting with RTC memory on the ESP8266 to extend the battery life. The idea is to save samples in the RTC memory (which survives deep sleep) and to only transmit them to the server when the RTC memory is full. Reading a sample and writing it to RTC memory is much quicker and less power hungry than starting the WiFi module and transmitting data. I don’t have the final results yet.

    1. Ahh, we think alike, yes I tried that (40MHz) and no discernible difference. Out of interest, the ESP32 consumes ~44mA with the Wi-Fi off and the ESP8266 about half that, I need to measure CPU draw at different clock speeds to get a definitive answer to that question. But, the dominant component in the mAh calculation is the (relatively) high RF stage (Wi-Fi) current demand, if that was down at 55mA it would have achieved 365-days easily. The ESP32 takes ~120mA, followed by pulse of 350mA (I believe the RF calibration phase) and then drops back to ~120mA, it is a common failure of many ESP32 designs that these high start-up current demands cannot be met leading to poor reliability. In my trial having those two batteries in parallel (3000mAh) should have been more than enough to provide a sufficiently low power supply impedance, but they were right on the limit of operating the ESP32 at start-up, it was only when I added the capacitor and shortened the cables that things became stable. Surprising the supply voltage measured at the ESP32 was dipping down to 2.6volts at start-up due to cable resistance, I was using Dupont cables, so not the best. There is much to the peripheral design of the ESP32 than as typically depicted with the bare unit. Most development boards (I now know) use the AMS1117 LDO regulator to provide the stability and dynamic impedance response to cope with the device start-up demands.

  5. @David Would it be possible for you to try how fast ieee80211_freedom_output can be used after wake up? That means you have to have a server that monitors wifi traffic constantly, but that seems doable. Wifi is not supposed to be a single packet protocol but there are other ways than using the freedom_output I’m guessing. I feel it should be doable to get the wake up time down quite a bit.

    1. A good idea, what I’m just about to try out is a measurement of the time-line from wake-up to sleep and see where all the time (3-Secs) is being consumed and by what part of the overall process, I have a idea it might be my Wi-Fi router, I’ll then try a fixed IP and any other techniques. I’m sure my router destroys the link certificate/TTL reset as soon as the connection is dropped, so that’s another factor I’ll look at.

    2. Trial aim: Determine time budget needed to update a Thingspeak server with Temperature, Humidity and Pressure readings.
      Trial conditions: ESP32 connected to a Bosch BME280E via a 320Mbps Wi-Fi connection to a 80Mbps fibre broadband connection.

      DHCP Assigned IP address:
      Start: timer=0
      Time to get an IP and start server: 2501mS
      Time to update Thingspeak: 3381mS
      Total time 5.882secs
      Same update of Thingspeak, but connection still active
      Connecting to ThingSpeak…
      Time to update Thingspeak:2479mS
      Going to sleep

      DHCP Assigned Fixed IP address:
      Start: timer=0
      Time to get an IP and start server: 2487mS
      Time to update Thingspeak: 3321mS
      Total time 5.798secs
      Same update of Thingspeak, but connection still active
      Connecting to ThingSpeak…
      Time to update Thingspeak:2479mS
      Going to sleep

      DHCP Assigned and Reserved Fixed IP address, lease still active:
      Start: timer=0
      Time to get an IP and start server: 2461mS
      Time to update Thingspeak: 3323mS
      Total time 5.784secs
      Same update of Thingspeak, but connection still active
      Connecting to ThingSpeak…
      Time to update Thingspeak:2485mS
      Going to sleep

      1. There is little performance gain from using a DHCP assign or Fixed IP address. DHCP protocol overhead is minimal.
      2. Leaving the connection active provides an improvement of ~850mS, but an ESP low power mode with Wi-Fi active and of sufficient low power does not yet exist AFAIK.
      3. The Thingspeak server takes a finite time (about 3-secs) to process the update. When I conducted my first trials the Thingspeak update timing was much faster, must depend on their server load.

      Try it yourself, I’d be interest to see other results or a solution.

      1. awesome details! I didn’t notice you specifying the type of Wi-Fi network security you used. I would try it on an open network and see if that brings the time down. If that works, then you could look at ways of dealing with security issues. You could do some fancy firewall stuff, but I would try running another ESP8266 as the AP and then connect it to a computer over a UART. The open network sounds bad, but if you only use it for transport with no IP access to your network it should be OK (similar to unsecured ISM band communications). I would also disable over the air (OTA) updates when running on an open network.

        Hope it helps!

        1. Hi, the security in use was WPA2 and although I have not tried an open network, I suspect the IP packet overhead is not that great, maybe a few percent slower. The connection time is is quite quick but Thingspeak servers take some time, it may be because it’s not an SSL connection and that may cause a change in access creating the delay. However, I have since purchased a Wemos Lokin ESP32 Lite and that uses considerably less power, if I get time I’ll repeat the trial with that device. I’m currently running a weather forecaster on it and can see it’s using so much less power but it needs days of running to get a good accumulated result. The Lite version is using the CH340c hart that takes 50uA in standby rather than the normal 22mA of the CP2102 fitted to a development board, so it’s my new favourite board. I will try out the test using an open network though, a good suggestion, thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s