Energy trade-offs in the IBM wristwatch computer
TL;DR: The unique energy related challenges and tradeoffs the authors encountered while building this watch are described and it is shown that the usage duty factor for the device heavily dictates which of the powers needs to be minimized more aggressively in order to achieve the longest perceived battery life.
Abstract: We recently demonstrated a high function wrist watch computer prototype that runs the Linux operating system and also XII graphics libraries. In this paper we describe the unique energy related challenges and tradeoffs we encountered while building this watch. We show that the usage duty factor for the device heavily dictates which of the powers, active power or sleep power, needs to be minimized more aggressively in order to achieve the longest perceived battery life. We also describe the energy issues that percolate through several layers of software all the way from device usage scenarios, applications, user interfaces, system level software to device drivers. All of these need to be systematically addressed to achieve the battery life dictated by the hardware components and the capacity of the battery in the device.
Summary (3 min read)
- The authors built the high function IBM wrist watch computer prototype to study several areas of mobile computing such as user interfaces , high resolution displays , system software, wireless communication, security, and interaction patterns between various pervasive devices.
- The authors view this watch as a wearable computing platform rather than a special purpose device.
- The main card has an ARM 7 based Cirrus EP 7211 processor, 8MB of Flash memory and 8MB of DRAM, and serial, IrDA, and expansion interfaces.
- Third party software developers are less likely to be interested in learning new programming interfaces unless the platform is already widely deployed.
- Notwithstanding, battery life is an important aspect that the authors paid attention to, and is at the heart of many trade-offs in the design of the entire system .
1.1 The Energy Challenge
- Calculators powered by solar cells and self-winding mechanical watches are examples of devices that have attained this goal.
- Under normal usage patterns, cell phone batteries last about a week which appears to be an acceptable threshold.
- An analogy can be drawn from automobiles.
- The device is likely to get used if it provides services to the user that outweigh the difficulty for caring for it.
- If the energy requirement is such that the user will need to replace the battery too often, rechargeable batteries have to be employed to minimize user aggravation and to protect the environment.
1.2 Challenges in a wrist watch form factor
- In addition to the general energy challenge faced by other wearable computing devices, there are several additional challenges imposed by the choice of a wrist watch form factor.
- Traditional watch manufacturers attempt to make the battery last so long that the user is more inclined to buy a new watch when it is time to replace the battery.
- The third problem relates to user perception.
- It is important to make the user perceive a high function wrist watch as being similar to these other devices rather than traditional wrist watches.
- In the following sections the authors describe the energy related tradeoffs associated to the device usage model, the hardware, system level software and application level software.
2 Device usage model
- Wearable computing devices are generally in one of two modes, sleeping or active.
- The device is in the active state typically when the device is doing something for the user; e.g., performing some computation, obtaining and displaying data etc.
- The exceptions to low duty factors tend to be devices that perform active functions even when the user is not consciously and actively using the device.
- Based on these metrics, the average power consumed by the device is given by Psleep (1-D) + PactiveD.
- At the frequently encountered low duty factors, it is very important to focus on minimizing the sleep power because reducing the PFR has less perceivable impact on relative battery life because the authors are at the left end of the curves in Figure 3.
3 Hardware level energy trade-offs
- The upper and lower bounds on the battery life for a device are determined by hardware.
- Similarly, the minimum battery life is dictated by the maximum current consumption when all hardware components are turned on.
- Compared to other wrist watches their design trades off energy efficiency for greater function, as is evident from the 32-bit processor and large amount of memory the authors incorporated.
- Fitting all of the components onto a small board, measuring 27.5 mm x 35.3 mm, was very challenging.
- This constraint ruled out coin cells and led us to choose a rechargeable Lithium Polymer battery.
4 System software level energy trade-offs
- As noted earlier, battery life depends to a large extent on the power consumed in the sleep state if the usage duty factor is low.
- So reducing the power consumed in the sleep state is the first issue the authors looked at.
4.1 Kernel Optimizations
- When the system is in the sleep mode, the task scheduler in the Linux kernel sees no tasks that are ready to run.
- The kernel switches the processor into the IDLE mode.
- From a user perspective, the 250ms delay is perceptible, but not annoyingly so.
- If this time-out interval is long enough the authors put the processor in STANDBY mode after programming the real-time clock (RTC) to wake us up before this time-out.
- The lines in bold are the statements the authors have added.
4.2 Other Optimizations
- Once the authors have done all that they can to reduce the power consumption in the sleep state, the next focus from a system software perspective is to ensure that the duration spent in the active state in response to user action is minimized.
- Device drivers also use interrupts and eliminate polling or kernel timer based scheduling whenever possible.
- As noted above, the authors run the X11 graphics library on their watches.
- The Xserver typically draws directly to a frame buffer and in their case would typically directly write to the LCD or the OLED.
- Individual byte or word writes to these devices are expensive in terms of power consumption and can also result in a visible flicker.
5 Application level energy trade-offs
- In the default mode the application displays the time and calendar information.
- Both the LCD and OLED displays consume less energy if fewer pixels are turned on.
- The authors found that an analog clock face could be displayed with fewer pixels.
- So eliminating busy loops in the application helps the kernel save energy by going into the STANDBY mode quicker.
- The display and the wireless communication subsystems could be turned off.
- Power consumption is very important for wearable computers, and the smaller they get, the more significant this issue becomes, and as the authors have shown, a wrist watch formfactor is pushing the limit.
- The authors studied the power consumption problem at several levels such as hardware, operating system scheduler, and the application level.
- The authors illustrated various trade-offs at these different levels and how they impact overall battery life.
- The authors have covered a significant distance in the race to design high function devices that are small, truly wearable and usable.
Did you find this useful? Give us your feedback
Cites background from "Energy trade-offs in the IBM wristw..."
...Already today, there are devices available that integrate them ....
Cites background or methods from "Energy trade-offs in the IBM wristw..."
...We also propose a power-secure architecture to thwart these power attacks by employing multi-level authentication and energy signatures....
...For battery-powered devices, authentication based upon X.509 may be applicable if the encryption algorithms and protocols are evaluated for their energy usage Research in low power design is also applicable to the problem, particularly in estimating battery life of mobile systems , measuring…...
...One major difference between attacks on batteries and low power design has is that the goal of low power design is typically assumed to be to lower the energy per operation of the device, which is a measure of both the power consumption and the execution time of an operation....
Related Papers (5)
Frequently Asked Questions (2)
Q1. What are the contributions in this paper?
The authors recently demonstrated a high function wrist watch computer prototype that runs the Linux operating system and also X11 graphics libraries. In this paper the authors describe the unique energy related challenges and tradeoffs they encountered while building this watch. The authors show that the usage duty factor for the device heavily dictates which of the powers, active power or sleep power, needs to be minimized more aggressively in order to achieve the longest perceived battery life. The authors also describe the energy issues that percolate through several layers of software all the way from device usage scenarios, applications, user interfaces, system level software to device drivers and the need to systematically address all of them to achieve the battery life dictated by the hardware components and the capacity of the battery in the device.
Q2. What are the future works in this paper?
Another possibility for saving power in the sleep state is turning off the DRAM. 0V at some point in the future the improvement for the active power consumed by the processor will be a factor of 2. Another important question is whether the current required for the device to be in sleep mode can be provided by external means so that the user pays only for active use of the device and not for the sleep mode. If the authors assume that the is 3 cm x 2 cm watch face has transparent solar cells such as a Grätzelcell [ 15 ], and use the above power and efficiency numbers ( precise efficiency numbers on transparent solar cells are not readily available ), the amount of power that can be redirected towards charging the watch battery is 164x0.