Power Consumption of Mobile Devices
Power consumption is one of the most critical aspects of a mobile device, and requires a huge amount of thought and effort throughout development. The first step of this development took place at the component selection phase of the process. Before we even began, we created an extremely-detailed power usage model for our device, to help us pick the right components.
Our actual model is a gigantic spreadsheet, but it can be mostly distilled down into these two graphs:
Key takeaways from the graph:
A dog spends much of his or her day resting, while in between periods of activity. In this state, the Whistle device can be in a very low-power state, waiting for motion to wake it up.
When the dog is moving, the lowest power state kicks in, taking sensor measurements and storing them in local memory.
Once an hour, for a few seconds, the device powers up its wireless interface and synchronizes its data to Whistle's servers. This uses ~200x as much power as when the dog is at rest, but it only occurs during a tiny percentage of the time that the device is in-use.
Since the battery is about 2/3 of the entire volume of our device, these component decisions were critical to determining the physical size of our device. This model allowed us to compute our theoretical power targets, which in turn determined the size of the Whistle device.
We made all of our component selection decisions with this model in mind. We chose a low-power Cortex M-series microcontroller, with embedded SRAM and flash memory (as opposed to the Cortex-A series microprocessors found in typical cellphones). Using a microcontroller with embedded SRAM eliminates the largest source of standby power usage found in higher-powered mobile systems: DRAM refresh current.
The downside? We have to measure our memory usage in Kilobytes, instead of the Megabytes or even Gigabytes found in a typical cellphone or tablet. This means that we have to use a small, purpose-built real-time OS, instead of something larger like Linux.
After choosing our microcontroller, the other components for our system were entered into our model before we selected them, to make sure they stayed within our targets.
For our product, in order to hit our battery life targets, we need to use, on average, less than one milliamp. Factoring in high-power (but short duration) events (like Wi-Fi syncing), that means we need to use closer to half a milliamp when our system is idle. To put that in perspective, a typical mobile phone uses approximately 5 milliamps when it is standby. We needed to beat that by a factor of ten.
First, we built non-form-factor prototypes with power measurement in mind. We were able to measure all of the current flowing into each subsystem of our design, so that any extra current could be eliminated. When we first powered up these prototypes, we were at an idle current of around 30 milliamps. Sixty times the target. Then we began the most difficult task—the slow, incremental work of the firmware team.
Modern microcontrollers are a maze of clock trees and power islands, all of which need to be set up and tuned with device software (firmware) for each running mode. Direct Memory Accesses (DMA) between peripherals need to be used and tuned so that the CPU inside the microcontroller can be asleep as much as possible. We used software profiling tools that can sample battery current at a high rate so we could track down bugs and tune our power usage. We even went as far as de-soldering chips from our boards to track down every wasted microamp.
In the end, we managed to meet our targets, and create a tiny device with Wi-Fi that lasts over a week on a single charge. This means the Whistle device can spend less time in its charger, and more time on its dog’s collar.
May 29, 2013
Tags: pet tech