Tips for accurate estimation of battery life

One of the top complaints about electronic devices in our modern, mobile society is the battery life that falls short of expectations. Human beings have to some degree become addicted to our ability to be connected and streaming data at all times in one form or another.

The increased use of mobile devices has not only resulted in chip manufacturers being forced to rethink how they design microcontrollers, but how embedded system designers build systems. Developers armed with even the latest techniques and technologies can struggle to ensure they have enough battery to operate their product for the anticipated and required duration. There are seven tricks that—if followed—can help to help guarantee an accurate estimation of battery life.

Tip no. 1: Traditional battery budget analysis
The first—and usually the last—trick an engineer performs to estimate the required battery size and anticipated battery life is to create a traditional battery budget. This type of analysis typically involves creating a spreadsheet in which each component in the system is listed. The engineer then goes through each component, determining its minimum, typical, and maximum current consumption, and recording these values.

With this information in hand, the engineer can now start to estimate what percentage of time the system will be in each of these "consumption bins." For example, the microcontroller may only spend 5% of the time in run mode, 25% in a low-power stop mode, and 70% in an ultra-low-power deep sleep mode. An example can be seen in figure 1.

Once each component has been analysed in this way, the results are summed and the system now has minimum, typical, and maximum current consumption numbers that can be used to size a battery. This all sounds fairly straightforward, but the problem with this type of analysis is that many of the numbers used are more-or-less determined based on experience. (This is a kind way of saying that they are a complete guess.)

The engineers make guesses to the best of their ability, but usually there remains a level of uneasiness, since there may be unexpected leakage currents, a bad estimate on how much the microcontroller will truly consume, and any number of other factors. (I once sized a battery for an application, after which the mechanical team decided they couldn't get the "look and feel" they desired, so they instead designed in a different battery with half of the capacity.)

Tip no. 2: Software RMA
As part of the software architecture design and analysis, a Rate Monotonic Analysis (RMA) should be performed on the software. This analysis will not only identify the different tasks that the software is going to be performing, but it should also include a relative idea about how long each of those tasks will run and the different peripherals involved.