Wi-Fi as the primary communications protocol in battery powered IoT devices – Does it work and how to reduce power consumption? – Part 2Follow article
I was curious to know if it would be possible to run an ESP8266, with a relay of sensors, on a battery and get a decent battery life relieving me of constantly having to run around and servicing the units. Read here part 1 of the article on what I found out about power consumption playing with different transmission configurations. In this part, I dig deeper into how a Wi-Fi connection is established and handled by the ESP, thus breaking down the code into separate parts to better understand what is happening and how it affects power consumption.
Wi-Fi deep dive
As a first thought I could imagine that a connection attempt to Wi-Fi would start with that the ESP sets its gain quite high and thereafter tunes it down as it gets a response from the network it’s trying to connect to. So, it’s somewhat optimizing the connection according to signal strength and maybe also from the information provided by the access point. And this would result in a rather constant power draw by the modem part of the ESP after a connection has been established, that’s, as long as nothing is transmitted. This could possibly be the explanation as to why we can see a higher usage for the second code configuration, as seen in part 2. So, the average power consumption is lower for a solid connection than a connection that’s consciously being connected and disconnected between transmissions. However, this would only be applicable/true for shorter transmission intervals, since the average usage would come down a lot with a longer interval between transmissions for the second configuration.
Right about now I find myself in a position where I’m not certain as to what’s going on. This led me to make some research regarding the Wi-Fi portion of the ESP to better understand how a connection is established. After reading a bit I realized that instead of having dedicated hardware for the modem processing, the ESP is sharing its system resources and CPU time between the written code and the Wi-Fi driver. Each time the main loop is repeated and every time the delay(ms); or the yield(); command is called, the processor will shift its attention to handling the Wi-Fi/TCP-stacks (which basically is the code/software that runs in the background handling the Wi-Fi and IP connections). So, if the code is taking too long to execute and no time is given to let the TCP stack do its thing, you run the risk of losing data or in the worst case crashing the program. This time is normally limited around 3 seconds before the soft WDT (WatchDog Timer) will reset the ESP. This might not be such an important detail in this particular case, but it will come in handy when deciphering a connection later on.
Another interesting fact of the ESP is that the PWM, interrupt and I2C pins are emulated in software which differs a bit from your typical Arduino board/ATMega chip, which has dedicated hardware for this. But I guess that there’s a limit to how much is possible to cram into such a small device as an ESP. (At least in what’s possible as of right now)
Few tests regarding Wi-Fi connectivity
Right so, now I'm trying to figure out how the Wi-Fi works on the ESP8266 in more detail. In my efforts to minimize potential issues related to weak signal strength I’m going to place an access point right in the near vicinity of my test setup. I suspect that a 20-30% signal sometimes is too weak for the unit so I’m eliminating this issue once and for all.
I also realized that a so-called Wi-Fi disconnect might not be the right way of disabling the Wi-Fi transmissions completely. I suspect that another command has to be sent to turn off the “modem” in between the reconnection attempts or the transmission of data in our case. So, in the previous tests, I’ve probably gone about it the wrong way. Since
“Boot → Connect to Wi-Fi → Send data → Disconnect from Wi-Fi → Back to connecting” isn’t the same as
“Boot → Connect to Wi-Fi → Send data → Turn of modem → Turn on modem → Connect”. So, this is something that I will look into.
Wi-Fi power consumption test setup
This setup will test Wi-Fi connectivity patterns and usage. This test only consists of the ESP connected to the Otii Arc , that I am using to power my device and measure the power consumption. Nothing else, this to isolate the usage of the Wi-Fi connection itself. (Of course, the most basic power draw from the ESP is still present/included in this) 10 connection attempts will be made during 5 minutes with an interval of 30 seconds in between each attempt. I will test the difference between a normal Wi-Fi disconnect and turning off the Wi-Fi modem (with modem-sleep) after each transmission, this will also be done with both a delay and a timer in between transmissions. Lastly, I’ll also be making the same test with ESP deep sleep implemented between connectivity attempts.
Fig 1: Wi-Fi Test 1 - Disconnect from Wi-Fi using a timer in between reconnection attempts
Fig 2: Wi-Fi Test 1 - Disconnect from Wi-Fi using a delay in between reconnection attempts
Fig 3: Wi-Fi Test 2 - Turning off the modem and using a timer in between reconnection attempts
Fig 4: Wi-Fi Test 2 - Turning off the modem and using a delay in between reconnection attempts
Fig 5: Wi-Fi Test 3 - Using deep sleep in between reconnection attempts
Fig 6: Test results from tests 1-3
Now that’s a nice result, it is clear that a modem shut-off is the better alternative than just disconnecting from the Wi-Fi. However, it seems like the best alternative is as previously discovered to let the ESP go into a deep sleep in between connections/transmissions. It is actually rather close between a modem shutoff and deep-sleep in this short test, but for a longer operational time, one should probably use deep-sleep. We can also see a minor difference between using a timer and a delay, although it’s a much smaller difference compared to the previous tests.
Moving on, I decided to test how much current the DHT22 sensor itself is drawing over 5 minutes to see if it’s possible to visually detect power spices during a data request. The current draw of the sensor seems to be more or less neglectable when looking at the red graph in the figure below, but I did however discover something worth mentioning. The modem is turned on by default so if you don’t wish to use the Wi-Fi capabilities of the ESP and are trying to conserve power remember to turn off the modem at boot.
Fig 7: The green line shows the current consumption with the default modem on behaviour compared to the red line when the modem is off.
The final test will consist of ~30 transmissions over 15.5 minutes with a duration in between transmissions of the usual 30 seconds. The resulting graphs over a single transmission interval will be shown below for each configuration.
Fig 8: Configuration 1 - Continuously connected to Wi-Fi using a timer in between transmissions.
Fig 9: Configuration 1 - Continuously connected to Wi-Fi using a delay in between transmissions.
Fig 10: Configuration 2 - Turning off the modem and using a timer in between transmissions.
Fig 11: Configuration 3 - Using deep sleep in between transmissions
Fig 12: Final test results from configurations 1-3
I expected the two configuration 1 tests to have a similar average current and power consumption. However, it is strange that there isn’t a greater difference between configuration 1 and 2… If one looks at the recorded data, it is possible to see that configuration 2 conserves much more power in between transmissions than configuration 1. But when taking a closer look at usage during transmissions it’s possible to observe configuration 2 using more power to wake up the modem and then transmit the data.
Another observation is that the MQTT library seems to utilize the Wi-Fi library and turn off/reduce the power of the modem when it’s not supposed to be used. This behaviour can be observed when comparing the recordings of Configuration 1 with a timer as well as a delay above with the two first Wi-Fi tests.
It is quite clear which configuration is the winner (Configuration 3), the usage gets roughly halved compared to the baseline code which is quite similar to the code of Configuration 1.
Stay tuned for Part 3 of this article, where I will be estimating battery life for a couple of batteries with Otii Battery Life Estimator that comes with Otii Arc standard perpetual software, hopefully answering whether Wi-Fi could be an option as a primary communications protocol in battery-powered IoT devices.