Wi-Fi as the primary communications protocol in battery powered IoT devices – Does it work and how to reduce power consumption? – Part 3Follow article
As 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 I embarked on an investigation resulting in a three-part article on power consumption. Read part 1 and part 2 where I investigated ways of reducing power consumption with some great and some annoying findings. In this article, part 3, I focus on battery life estimation, hopefully answering whether Wi-Fi could be an option as a primary communications protocol in battery-powered IoT devices.
Battery life estimations
Now let's make some calculations using the data given in the final tests from part 2 of this article to see how long the different configurations can run on different batteries. The functionality for calculating and estimating this was recently added to the standard Otii software for Otii Arc , under the menu item “Window” it is possible to find the “Battery Life Estimator”. In this window, you will have to define the capacity of the battery you are testing in [Ah]. After this, you can select/highlight the active part of the graph, which in our case is the connect and transmission of data section. Then you pull the data into the calculator by using the “Get from selection” button. Lastly, you do the same for the “standby/sleep” part of the code.
To make the recordings a bit faster I ran with an interval of 30 seconds between transmissions, and this updating frequency might be a bit too fast, but that is easy to test and expand in the Estimator tool. The estimator uses the average consumption during sleep as well as the sleep length in its calculations. So, if a longer sleep length is needed one could just change that value to whatever the actual transmission interval should be.
Fig 1: Qoitech Battery Life Estimator
Down below I will present the battery lifetime for some suitable batteries which in my opinion would be acceptable size-wise and then compare all the configurations from the last test with one another. Please note that this estimator does not account for the self-discharge of the batteries.
|Battery||Configuration 1 [Timer]||Configuration 1 [Delay]||Configuration 2 [Modem Sleep]||Configuration 3 [Deep Sleep]|
|1.3 days||1.3 days||1,7 days||1.2 months|
|2.4 days||2.4 days||3.1 days||2.2 months|
|6.3 days||6.3 days||8.1 days||5.8 months|
|7.2 days||7.1 days||9.1 days||6.7 months|
Table 1: Estimated battery life for all configurations using different types of batteries. The time in between transmissions has been changed from 30 seconds to an hour.
I’m actually amazed that the device should be able to run for 1.2 months with such a small coin cell battery as a CR2450, however, I realized that this, unfortunately, never can be possible due to limitations in the maximum current draw of the battery. During a boot from deep sleep the ESP creates a rather large current peak of about 460 mA which is way too much for the small coin cell battery to handle/deliver. Moving on with comments on the next two batteries on the list, the capacity for both the AAA and the AA battery is taken from the highest tier in the datasheet which corresponds to a continuous discharge of 25mA from full to 0.8 volts at 21°C. My reasoning behind this is that current peaks producing 460mA only occur shortly during startup thus the overall mean current draw is substantially lower than this and could hopefully go under the 25mA tier. A final note on these types of batteries is that they have a rather low nominal voltage, two batteries must be placed in series to get a voltage high enough to run the microcontroller. This unfortunately results in more space needed with the same capacity as one battery.
Another thing that astonishes me is the absolute huge difference in running time, between using Configuration 2 (Modem/Light-Sleep) and Configuration 3 (Deep-Sleep). When looking into the reasons for this unbelievable increase I really suspect that the power usage in idle should be studied more closely. When using the battery estimator and comparing the average current usage during active time as well as the usage during sleep/idle between the two configurations the large difference suspected, mainly in the idle state, can be verified.
Fig 2: Battery Life Estimator configurations
The average current consumption is roughly the same between the two configurations but when the microprocessor is idle the current drops from a modest 15.4mA to an impressive 605µA. That certainly shows how important idle usage is! If it only were possible to reduce the active part a bit more, then this protocol and hardware combined with one of the batteries mentioned above could be a feasible solution. Regrettably, I must say that a little more than half a year of running time on a single charge is not enough in my opinion for me to continue this hardware and software development. I think I will have to look into another more energy-friendly transmission protocol...
Alright, so maybe using Wi-Fi as the primary communications protocol for sending sensory data isn't the best alternative. It’s certainly possible but you’ll have to compromise a bit with regards to battery size. I would’ve liked to see a charge that lasts somewhere closer to 2 years so that there’s some margin for the connection attempts that fail due to a bad Wi-Fi signal or when there’s a power outage. However, this doesn’t seem to be a possibility at least with my code and setup. In hindsight, I probably was a bit too ambiguous thinking that I could test all functionality at once. Breaking up the different functionalities into separate tests and then optimizing each before combining them seems to be the way to go. I should also note that these tests have not been taking the power usage of a much-needed voltage regulator into consideration. Such a device must certainly be used to regulate the battery voltage since the battery will not keep the same voltage during its entire discharge. However, power electronics usually have a high efficiency so I suspect that the usage might not increase significantly. I’m also certain that the usage would decrease further if another simpler microcontroller were to be used, e.g. an ESP-1 since the footprint of the entire PCB is smaller as well as there being fewer components on it.
With that said I hope you enjoyed the articles!