By Jamirsen Ezell, Firmware Engineer
It’s important to me that I work on interesting, challenging projects as an engineer. So, it was great news that when I first joined the Orion Labs team in August of 2016 we were working on an interesting problem: battery life.
The amount of time a device can be used before the battery dies is one of the most important factors in consumer electronics. When I joined Orion, battery life for the Onyx — a wearable smart walkie-talkie that allows instant voice conversations with other Onyx users — was 6 to 8 hours. However many of our customers, like contractors, are on their feet and away from outlets for 12 hours at a time. To make Onyx work for them, we needed to increase the battery life to at least 12 hours. It took us four months, but we finally cracked it. Let me walk you through our thought process.
Estimated Use Model
At Orion, our estimated use model is 5/5/90. This means the user will be transmitting 5% of the time, receiving 5% of the time, and idle 90% of the time. This was the criteria we used for battery life, based on data from actual Onyx users. Since we estimated the user will be idle 90% of the time, the team focused on reducing power when the device is in that idle state.
Originally, we speculated that the Bluetooth system was responsible for draining most of the Onyx’s battery. We talked about changing the connection interval and all kinds of other stuff but quickly realized that we should verify our assumption first.
Our general approach was to first understand which parts of Onyx’s system were drawing the most power, and then determine how to reduce their power consumption. To measure power in the system we used current consumption because power consumption is proportional to the current drawn (P=IV). Total idle current consumption came in at around 42mA. This was rather high and gave us confidence there was some headroom to reduce the draw. After a quick estimate, we realized that to reach our goal we needed to be drawing about 20mA.
After this first test, we had the total current consumption, but we still needed to isolate subsystems to find where the power was being drawn. The problem then became how do we measure the power each of these subsystems is using? We could just look at datasheets and get an estimate. However, we wanted to be sure before we put any work in.
The next step was to power on each system one at a time and measure. Right off the bat, however, this technique had a flaw. Some subsystems depend on one another in order to run. Our best option was to use the slice removal, or SR method (yes, I just made that up). We would remove one subsystem, then measure the whole system again. From that exercise, we could infer the power drawn by that subsystem.
We wrote code to shut off each subsystem and used a series of console commands to allow us to toggle these subsystems on and off in real time, giving us the most accurate picture of how current was flowing. As expected, the MCU was the most power hungry, drawing ~20mA of the total 42mA. As mentioned earlier, our hypothesis was that the wireless connection would draw much of the current. It was a good thing that we tested that assumption; we discovered that due to our use of Bluetooth Low Energy (BLE), the connection only drew about 3mA.
We continued to measure and found:
- The CPLD drew about 9.3mA
- The DSP drew ~8mA
- The battery monitor and LED controller systems <1mA
With the battery monitor and LED controller and BLE systems ruled out, we now knew what systems to target.
Tackling the Problem
To start saving power, we looked at the lowest hanging fruit. For us, that was the DSP.
Knowing the DSP subsystem and looking at the scripts that configure the DSP chip, we knew that the amplifiers driving the speaker, mics, and headset were left on, even while no audio was being recorded or played. A quick test to verify our hunch showed that turning off the amplifiers saved us ~6mA — exactly what we were looking for.
Now, the hard part. The team had to find the timing that would turn the amplifiers back on quickly enough to not disrupt audio actions or headset detection. After a bit of trial and error, we found a good balance of power savings and performance. With the DSP optimized, Onyx had a total current draw of ~36mA, still well above our goal.
The MCU was next since it drew most of the power. We quickly stumbled onto what seemed like the holy grail. The MCU had a feature to shut down and restart peripherals automatically when the MCU sleeps. We had utilized the sleep ability but were not shutting off the peripherals. After shutting off everything we could — and testing to make sure we didn’t break anything — we saved ~5mA. Still not good enough.
The next bit looked similar to the exercise we went through earlier: shutting down each peripheral in the MCU individually to figure out what was sucking up all the current. The culprits were the 2 data transfer modules, DMA1 and DMA2. Shutting these modules down, however, basically renders the MCU useless. All the data from the DSP, battery monitor, Bluetooth, and other internal MCU peripherals are transferred over the DMAs. And, in addition to that, the DMAs are meant to be run while the MCU is sleeping, to save time and power.
So we found a clever way to interface with the DMA modules and make sure they were idle before shutting them down, while still starting them up as soon as there was any possibility they will be needed. Now, the final current draw while idle in the MCU is a measly 4.5mA. If you remember, it started around 20mA.
In the end, Onyx’s total current consumption is between 18–20mA while the device is idle. This gives us about 12.5+ hours of battery life using the 90/10 split model from above.
This whole process took about four months of work. Despite all of the hard work, it was well worth the learning experience and the results that came from it. But, the Orion Labs team isn’t done yet. Our next goal is 18+ hours of battery life, and we’re moving towards it fast!