Adam Dunkels, PhD 
Power consumption literally is matter a life and death for battery-powered devices. Making devices last for a long time will reduce deployment costs. And being able to predict the lifetime in advance makes planning easier and allow us to replace batteries at scheduled intervals.
Today we will use the Thingsquare system to make a wireless TI Sensortag live for a year on one coin cell battery.
We see that making the right choices in software can make a stunning 400x difference in power consumption – two orders of magnitude – even with an already extremely power-efficient hardware.
We use the Thingsquare system’s built-in power consumption monitoring mechanism that allow us to predict the lifetime of a device without having to run it until the battery depletes – which would take us at least a year.
What We Want to Achieve
We want a wireless sensor that lasts a year.
We use the Texas Instruments Sensortag hardware, which is readily available and has a number of useful sensors. It also happens to be powered by a single CR2032 coin cell battery.
But having it last a year is by itself not enough: we must be able to remotely access the data the sensor generates. We want the system to be secure, so that no outside people can eavesdrop on the data generated by the sensor and so that it is impossible for someone else to fake data coming from the sensor.
The wireless sensor sends its data, reliably and securely, to the backend server through its wireless mesh network. All wireless devices are running the Thingsquare 6lowpan firmware and the server is running the Thingsquare backend software.
To be able to place the sensor at the location we want to, we may need to use a mesh network: that is, some other devices that help to extend the range of the network. The sensor itself need not take an active part in helping others, but it may itself need the assistance of other mesh devices.
We also need the system to be robust. We do not want it to fail because we need to replace other devices in the system and we do not want data to get lost. For example, if the wireless sensor is part of a burglar alarm, designed to detect that a particular door was opened, we absolutely need that information to reach us. We can not afford that the sensor drops the data.
Moreover, we want the ability to update the sensor in the field. We may need to change how often it samples its sensors and we may even want to be able to update the firmware on the sensor over the air. We may have discovered a bug that needs to be fixed, or we may want to improve the system in some other way.
These requirements all add to the challenge of getting that wireless sensor to live for a long time on one coin cell battery. Fortunately, the Thingsquare system was built to tackle just these challenges. Let’s first turn to the factors that affect the lifetime of a device.
The Factors that Affect Device Lifetime
The lifetime of a device is determined by how much power the device’s components consume.
The first step is choosing hardware components that have a low power consumption. The Sensortag is built around the Texas Instruments CC2650 chip. The CC2650 is an impressive device: an extremely power-efficient chip that packs an ARM Cortex-M3 microprocessor together with a combined Bluetooth and IEEE 802.15.4 radio into a single chip.
But choosing the right hardware is no way near enough: as we see below, being wise about how to use the hardware can make a 400x difference in terms of lifetime.
We divide the components into three categories:
- The microprocessor. At the heart of the device is the microprocessor. Today’s low-power microprocessors are really low-power – but they still consume an amount of power that is significant enough to affect the lifetime of the device.
- The radio. Every wireless device has a radio. Even really low-power radios such as IEEE 802.15.4 consumes power, typically at least one order of magnitude than the microprocessor.
- Any external components. A wireless device always has some form of external components, such as sensors or actuators. Those will inevitably consume power, but since they are wildly different from device to device, we will not consider them here. Also, their power consumption is often relatively easy to control: just turn them off when they are not needed.
In this post, we focus on how to control the power consumption of the first two in this list: the microprocessor and the radio. We leave the external components as an exercise to the reader.
The microprocessor’s power consumption characteristics is controlled by the operating system running it. Low-power microprocessors have a multitude of power modes that allow the system’s power consumption to be efficiently managed by the operating system.
The trickiest part of the system to manage is the wireless communication. We will look into that in a moment.
Batteries
In theory, a battery is a chunk of energy stored in a small capsule from which power can be drawn until the energy is depleted. In reality, there is a little more to it than that. The pattern by which that power is drawn from the battery affects the amount of energy that can be drawn. And at some point the voltage that can be drawn drops below a usable amount. (For more background of this, read Jack Ganssle’s excellent in-depth articles here and here.)
A battery's energy storage capacity is measured in milliampere hours (mAh) – how many hours the battery can deliver a current of one Ampere. A CR2032 coin cell battery typically is specified with around 250 mAh.
A wireless sensortag with a CR2032 coin cell battery
From these 250 mAh, not all energy can be used. A reasonable rule-of-thumb is that 40% of the capacity can be used. This leaves us with some 100 mAh of energy.
And 100 mAh is not a lot of energy for us to get to a year of lifetime. We must be prepared to really optimize our power consumption.
Measuring Power Consumption and Predicting Lifetime
To optimize the power consumption, we must first be able to measure it.
The Thingsquare system tracks the power consumption of every device by measuring how much time the device spends using its radio and microprocessor. By measuring the power consumption and multiplying it with the time measurements, we can build a model of a device’s power consumption and from this we can predict its expected lifetime.
In the Device Viewer app, the lifetime estimate is available via the `Power Consumption` button. Via the `Power Settings` interface, we can tune the device configuration to see how it affects the power consumption and expected lifetime.
The lifetime estimation uses the assumption from the battery model we discuss above: that we are able to use only 40% of the available energy.
The Power Consumption view in the Device Viewer app
Let’s now turn to the baseline power consumption of a wireless sensortag.
Baseline Power Consumption
The CC2650 has a power consumption that is an order of magnitude lower than previous-generation chips, which makes it a great chip for us to use. But we need to handle the chip wisely, otherwise we will not get anyway near that year of lifetime.
To find what the baseline power consumption is, we first run the CC2650 with the radio in an always-on mode. In this mode, the radio is able to receive a transmission at any time. In the Thingsquare system, this mode of operation is called high performance mode because it gives us the best wireless performance, at the cost of a higher power consumption.
We measure the power consumption of the device to see how close to one year of lifetime this gets us. The result can be seen in the screenshot below:
The power consumption of the system with the radio in high performance mode, where the radio is in always-on mode, always ready to receive data
We see that the baseline power consumption of the ultra low-power CC2650 chip is around 6 mA, giving us an expected lifetime of about 16 hours with a coin cell battery. A far cry from the year-long lifetime we were hoping for.
Fortunately, we can do better.
Optimizing the Wireless Power Consumption
As we’ve seen, wireless communication consumes a significant amount of power. It is also the most tricky component to optimize, because we need it to communicate with devices around us.
The counter-intuitive rule of low-power wireless communication is this: listening for data is much more expensive than sending data. This is because when listening for data, you need to keep the radio turned on for longer time than the time it takes to send the data: you need to be sure to be awake when the data arrives, and you are not always sure exactly when that happens.
To optimize the wireless power consumption, it is therefore not enough to simply reduce the amount of data we send. We must be very smart about how much time we spend listening for data. In general, striking a good balance is difficult. (There have literally been hundreds of PhD theses written on this topic alone.)
The first thing we can do to save power is to be smart about how to listen for incoming data. We duty-cycle the radio so that we listen only for a brief while, with a fixed amount of time in between, instead of listening all the time. We alter the sending side, so that the sender sends a train of wake-up messages before sending the actual data. These wake-up packets tell the receiver that it is time to wake up to receive the data. This is called sampled listening and it a good way to significantly reduce the power consumption, while having almost the performance of the always-on mode.
With Thingsquare’s sampled listening, we can reduce the power consumption a lot. In fact, we can reduce the power consumed by the radio by 98%, while still being able to have a responsive communication with a device. In the Thingsquare system, this mode is called responsive mode.
The power consumption of the system in responsive mode
This 98% reduction does get us far, but not far enough. As we see above, we get a current draw of about 0.232 mA, which is one order of magnitude lower than before, but only gets us some 17 days of lifetime on a coin cell battery.
Getting to Months of Lifetime
To go beyond the 17 days we can get with sampled listening, we need go even further: we need to completely turn off all communication. To allow us to respond to remote commands, we periodically wake up to see if there is anything waiting for us. In the Thingsquare system, this mode is called lifetime mode.
In lifetime mode, the device wakes up in a regular pattern to check if anyone wants to talk to the device. If so, it briefly starts to do sampled listening, but only for a short while. This allows the device to be reachable while staying asleep for most of the time.
If we switch on lifetime mode with its default settings we get the power consumption seen in the screenshot below: 0.0444 mA. This gives us some 3 months of lifetime.
The power consumption of the system in lifetime mode
This power consumption is one order of magnitude lower than what we had before – see the chart below. But a 3 month life is still not quite the year that we were looking for.
The current draw of high performance mode is an order of magnitude higher than that of responsive mode, which in turn is an order of magnitude higher than lifetime mode
Getting to a Year – and Beyond
We still have some way to go before we get to a year of lifetime, but so far we have seen significant improvements in each step of the way.
Let’s now look at the remaining knobs we can turn to further improve lifetime:
- Data rate. How often we send data will obviously affect the power consumption and lifetime.
- Responsiveness. As we’ve seen, how often we want the sensor to be able to respond to commands does affect the power consumption and lifetime.
To see what effect varying these parameters have, we set up a bunch of sensortags and give them different configurations through the Power Settings window. We make sure to turn off proximity beacons to save additional power.
We set up a bunch of sensortags and give them different power settings with the Power Settings window. We then measure the resulting power consumption via the Power Consumption window.
The Effect of Data Rate
We expect that lifetime will increase with lower data rate. That is, the less data we send, the longer we live.
To see the effect of data rate, we vary the rate between sending once per minute to once every 12 hours. We keep the responsiveness constant with one wake-up per minute.
As seen in the graph, our measurements support our hypothesis that lower data rate results in longer lifetime.
The less data we send, the longer we live – up to a certain point.
If we send data once every minute, we can expect about 50 days of lifetime. If we turn down the sending rate to send only once every 12 hours we can expect a longer life.
Unfortunately, modifying the sending rate alone does not give us one year of lifetime. We reach only about some 280 days, about 9 months, which is some 3/4 of a year of lifetime. To achieve the year-long life we want to, we must turn to tuning the responsiveness.
The Effect of Responsiveness
The responsiveness determine how often each sensor will wake up to listen for commands or data. In most cases, a wireless sensor does not need to be very responsive: waking up only a few times per hour may be enough.
To see the effect of responsiveness, we keep the data rate constant at one measurement per 30 minutes and vary the responsiveness between 10 wake-ups per second to one wake-up per 10 minutes.
The results are in the graph below.
The less responsive we are, the longer we live.
We see that the responsiveness has a profound impact on lifetime. With a data rate of one measurement per 30 minutes and a responsiveness of one wake-up per 5 minutes, we are finally above one year of lifetime.
And with a wake-up rate of once per 10 minutes, we are well above one year of lifetime. In fact, with almost 600 days of predicted lifetime, we are closer to a two-year life for our wireless sensor.
Conclusions
We set out with an ambitious goal: to make a wireless sensor live for a year on one coin cell battery. And we wanted the sensor to be secure, robust, remotely available, and remotely upgradeable. A challenging task, but a task for which the Thingsquare system was built.
We use very power-efficient hardware and the built-in power measurement mechanism in the Thingsquare system to find a system configuration that gets us a year of lifetime.
This result allows for large-scale installations of wireless sensors with very long life expectancy – and the ability to predict the lifetime before deploying them.
