Seven ways to accurately estimate battery life - Embedded.com

# Seven ways to accurately estimate battery life

One of the top complaints about electronic devices in our modern, mobile society is that their batteries don't last as long as expected. 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.

Trick 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, which can also be downloaded by clicking here.

Figure 1

Example of a traditional battery budget.

Once each component has been analyzed 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 .)

Trick 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.

Figure 2

Example of a software task analysis.

From this information, a simple listing of the different tasks and behavior of the microcontroller can be documented in order to improve the traditional battery budget “guestimations.” A simple example of this can be seen in Figure 2. Note that an RMA will also give the developer a comfort level in that all tasks will complete in a deterministic manner, with no deadlines being missed.

Trick No. 3: Chip vendor tools
One of the foggiest areas when it comes to energy consumption is the microcontroller. There are so many variables concerning how these little guys will consume energy. A review of most vendor datasheets will provide wide ranges of energy consumption based on temperature, voltage, peripheral set, altitude, wind speed, birth sign of the developer, and so forth. There is always the question as to where and how these numbers were obtained and if they are accurate or not.

Even with a little bit of “hand waving” though, there are some new tools that chip vendors are starting to supply to developers that will greatly improve how battery budgets are estimated. One that immediately comes to mind is STMCubeMx from STMicroelectronics. This tool is primarily intended to be used to set up and configure an STM32 microcontroller, but the really cool part about it is that it has the ability to simulate current consumption. An example can be seen in Figure 3.

Figure 3

STMicroelectronics' STMCubeMx tool.