Understanding battery life for IoT devices
The increasingly complex world of IoT solutions requires novel approaches to keep the cost and usability at an acceptable level, like using advanced AI algorithms, including machine learning and neural networks running on the “edge”. Smart devices doing as much of the data-heavy lifting as possible can cut down the cost associated with uploading raw data to the cloud and processing it there. But since many of the edge devices are powered by batteries, how does this affect their battery life?
This article helps to build an understanding of how the battery life of a device is affected by various factors.
Battery-powered device operation lifecycle
To start, a basic understanding of low-power device operation is required.
A battery-powered product will most likely reside in the lowest power consumption state possible most of the time to maximize battery life. This means turning off any communication interfaces, sensors, and data processing systems. This state is often referred to as the standby or power-down state.
A purely wakeup-based system will most likely reside in this state and keep a minimum amount of components active. The simplest example is a button-based wake-up when the device’s power is switched on by a button press, so only a small portion of the circuit consumes power to monitor the button press. A Real Time Clock can be kept running to allow time-based wakeups, either periodically, or at a specified time.
Quite often, however, we need to monitor the external environment continuously, reacting to sudden changes or conditions and acting on them. This leads us to the always-on concept, which usually means that a bigger portion of the device is awake all the time. For example, an always-on temperature sensor can wake up a system when the temperature reaches a critical level to send an alert to the cloud. Or a smart speaker with an always-on microphone and audio processor is constantly powered on to detect and classify “wake words”.
In the always-on cases, the designer should pay special attention to the power consumption of the always-on components, as they are likely to define the battery life for the whole product.
Multi-level sensing
Sometimes the active power consumption of components that are supposed to work in always-on mode is too high to satisfy battery life requirements. In that case, a multi-level sensing approach can be taken. For example, instead of keeping the GPS receiver on a location-tracking device, why not just use a low-power accelerometer so that system power consumption is ~1000x less when the tracker is not in motion? Or, why run a power-hungry AI camera to detect objects when there are no objects in the scene if you can switch it on with a proximity sensor or light detector?
Major contributors to device energy usage
An embedded device is a complex beast with lots of components that consume energy, but typically there are a few dominant consumers that should be a subject to power optimization.
Wireless connectivity
Wireless communication constitutes a significant portion of the system’s power consumption, so it is important to choose the communication protocol wisely. The basic parameters that go into requirements are data rate, range, whether a complementary receiver/gateway is acceptable, and whether a 3rd party network provider fees are acceptable (as is the case for cellular networks, for example).
An important factor is the wake-up period of the RF communication system. In a transmit-only system, like a temperature sensor, the RF communication will happen at pre-determined intervals which can be quite far apart to conserve energy (e.g. every hour). On the other hand, a smart switch will need to respond to user commands quickly, in real-time. The latency of response is the maximum amount of time it takes for the switch to turn on or off after the user command. Low latency requires the switch to enable the RF communication system more often (e.g. once per second) and causes higher average power usage, albeit delivering a better user experience.
This kind of distinction is well depicted in the LoRaWAN specification, where the three classes of devices differ by when and how often they wake up to transmit or receive messages.
If you want to know more about wireless communication solutions, here is our article that compares different options available on the market.
Light emitters and displays
Light-emitting diodes (LEDs) are mostly included for user interface and user feedback. In that case, they don’t consume a lot of energy. Unless, of course, they are supposed to be enabled during standby, which might drain the battery quite fast if not done properly. It is often a good practice to dim the LEDs by driving them with a PWM signal, to adjust the brightness to an optimal value.
LCD backlight can also consume a significant amount of energy, so it is important to only switch it on when necessary. If an always-on display is needed, consider using e-Ink displays as a low-power alternative. As with everything in engineering, this comes with its tradeoffs.
Always-on sensors
While proximity sensors, image sensors, and microphones might come with low average current, it is vitally important to choose components with adequate energy usage if they are supposed to be running in an always-on mode. Some tips below:
- Proximity sensors with larger ranging distances typically have higher power demands.
- Consider reducing the image sensor update rate, resolution, and region of interest to reduce its power consumption.
- Using monochrome image sensors instead of RGB ones can also lower power consumption significantly.
- Analog microphones have lower power consumption than digital ones but require careful circuit design to ensure good analog signal quality.
Standby leakage current
The standby leakage current can get too high due to circuit design mistakes. Some of the most common are:
- Constant current leakage through smaller value resistors. This often happens if the pull-up/pull-down configuration is not chosen correctly, or the voltage divider resistance is too small.
- Improper power management of system components.
- Using internal RC-based clock sources for RTC instead of the external crystal.
- Inefficient DC/DC converters are enabled during device standby.
To know more on this topic, check our article on optimizing circuits for low power .
Building power consumption model
To analyze the device’s battery life it is useful to have a power consumption model, that describes how much power the device consumes in different conditions and configurations.
The divide and conquer principle is often used to build the mode. It involves involves breaking down the lifecycle of a device into a set of distinct states and using theoretical or empirical data to assign power consumption to each state. The model can have various input parameters, such as data rate, data resolution, maximum latency, and environmental conditions. Keeping all these parameters as inputs to the model allows us to analyze the system in different configurations and select the most optimal one.
The output of the model could be a battery life duration or the battery capacity/number of cells. The type of output will depend on input parameters. For example, if a model is parametrized by the battery capacity, its output will likely be the battery life given the battery size. On the other hand, it is possible to find the required battery size given the required battery life and other fundamental parameters. Sometimes we need to find optimal values for other model parameters, which is also achievable when a proper model is available.
It is worth noting that, in some cases, battery size (and hence the product size) can be limited, which means optimizing power consumption is crucial to achieving desired battery life, while in other case battery size can be increased to a reasonable degree, without spending significant time and budget on optimization. In both cases, it is valuable to have the correct power consumption model to ensure that the solution cost is as low as possible.
Before modeling power consumption, is important to lock down the requirements and build a basic operation algorithm. It might also be useful to have multiple power consumption models for different approaches to compare them and select the best one.
Below is the table of typical embedded applications and their projected battery life from two AA alkaline batteries:
| Application | Battery life estimate |
|---|---|
| BLE beacon transmitting temperature data every second | 1 year |
| Sending 200kB of data via WiFi every 10 minutes, not maintaining connection | 2 months |
| NBIoT device listening for MQTT commands with 1-2 seconds latency | 3 weeks |
| Microphone recording into internal memory, no upload | 17 days |
| Infrared Time-of-Flight proximity running detection at 10Hz | 10 days |
| GPS tracker with 1Hz update period, no data connection | 40 hours |
| 2MP camera streaming video at 15FPS via WiFi | 5 hours |
Reducing the size of the data to be transmitted
As a rule of thumb, the more data a wireless device needs to transmit, the more energy it will consume, that is why it is important to choose what data to send carefully, and employ various techniques to reduce data size requirements:
- Many of the well-known data compression algorithms can be run even on resource-constrained systems to reduce data size before sending.
- Computer vision algorithms running on the device allow sending metadata instead of the picture (e.g. list of objects), or only sending a section of an image within a particular region of interest.
- Sound classification algorithms only send relevant metadata and events instead of uploading audio data to the cloud.
Most importantly, careful examination of system requirements and data schemas might uncover smarter, application-specific optimizations. For example, relying on previously uploaded data and uploading only the changes (deltas).
Conclusion
Battery life is a key factor in product success and is always a hot topic in embedded product development. It is important to understand how various components contribute to energy draw to ensure the product is feasible and delivers exceptional performance to the user. Using edge computing and advanced AI algorithms can improve the battery life of a product by reducing the amount of costly wireless transmissions, but if used incorrectly, can cause the opposite effect. Experimental data and thorough measurements should be used to justify the use of various optimizations and algorithms.
Power consumption modeling helps to estimate and understand the energy usage of a system. By building a correct model, it is possible to compare different device operation modes and architecture approaches and navigate system tradeoffs.
At Maxlab we have wide experience in designing devices powered by batteries and renewable energy sources, allowing devices to function autonomously for months or even years.