scispace - formally typeset

Proceedings ArticleDOI

Energy trade-offs in the IBM wristwatch computer

N. Kamijoh1, T. Inoue1, C.M. Olsen1, M.T. Raghunath1, Chandra Narayanaswami1 
08 Oct 2001-pp 133-140

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.

AbstractWe 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.

Topics: Device Usage (56%), Efficient energy use (52%), Smartwatch (51%), User interface (50%), Software (50%)

Summary (3 min read)

1 Introduction

  • The authors built the high function IBM wrist watch computer prototype to study several areas of mobile computing such as user interfaces [1], high resolution displays [2], 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 [3].

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.

7 Conclusions

  • 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

...read more

Content maybe subject to copyright    Report

Abstract
We recently demonstrated a high function wrist watch
computer prototype that runs the Linux operating system
and also X11 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 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.
1 Introduction
We built the high function IBM wrist watch computer
prototype to study several areas of mobile computing such
as user interfaces [1], high resolution displays [2], system
software, wireless communication, security, and
interaction patterns between various pervasive devices.
We view this watch as a wearable computing platform
rather than a special purpose device. Therefore our goals
differ quite significantly from those posed to the designer
of a traditional wrist watch with just time keeping
functions.
We chose a watch form factor (see Figure 1) because
watches are easily accessible and get misplaced less often
than PDAs and cell phones since they are worn, not
carried. It is also commonly believed that many people
glance at their watches up to forty times a day and this we
think is a good reason to put some additional useful
information, such as upcoming appointments on the watch
face. The watch is also an ideal device for conveying
information alerts to the user, since it is instantly
viewable.
The watch form factor also takes many of the
packaging, user interface, and power problems to the
extreme which appealed to several of us.
Figure 1. Wrist watch prototypes.
Our watch has a touch sensitive screen and a roller
wheel for user interaction. 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. We have two monochrome displays, a 96x120
reflective LCD and a 640x480 Organic LED (OLED)
display [2]. Bluetooth
TM
functionality is provided by an
auxiliary card that connects to the main card in some
watches. The watch is powered by a rechargeable Lithium
polymer batter with 60mAh capacity at a nominal voltage
of 3.7V. Figure 2 shows the hardware block diagram.
We chose the Linux operating system for our watch
because of the availability of source code and a wide
variety of software tools, and programmer familiarity.
Third party software developers are less likely to be
interested in learning new programming interfaces unless
the platform is already widely deployed. For the same
reason we chose the X11 graphics library instead of
defining a new graphics library.
People are often impressed by the amount of function
we have managed to fit into such a small package.
However, a question that often gets asked is how long the
batteries last. Obviously the battery life on a watch like
ours will not compare favorably with conventional
watches that have limited functionality. Notwithstanding,
1
Energy trade-offs in the IBM Wristwatch computer
Noboru Kamijoh, Tadanobu Inoue, C. Michael Olsen
+
, M. T. Raghunath
+
, Chandra Narayanaswami
+
{kamijo,inouet}@jp.ibm.com, {cmolsen,mtr,chandras}@us.ibm.com
IBM Research Division, Tokyo, Japan
+)
IBM Research Division, Yorktown Heights, NY, USA

battery life is an important aspect that we paid attention to,
and is at the heart of many trade-offs in the design of the
entire system [3]. In the rest of this paper, we discuss the
trade-offs we made and the motivations behind these
trade-offs.
Figure 2. Hardware block diagram.
1.1 The Energy Challenge
The holy grail, energy wise, in the design of mobile
devices is to enable them to be self sustaining [4].
Calculators powered by solar cells and self-winding
mechanical watches are examples of devices that have
attained this goal.
Though the energy challenge is often interpreted as
making the device run as long as possible and be as
energy efficient as possible, a more pragmatic viewpoint
is whether battery life can exceed some acceptance
thresholds. 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. Both car buyers and manufacturers do not
agonize excessively and solely over gas mileage and pay
attention to form and function because most people don’t
need to refuel on each trip, and when they do, it is fairly
easy to refuel. The device is likely to get used if it
provides services to the user that outweigh the difficulty
for caring for it. So we have the dual challenge of
providing useful function while minimizing the effort of
caring for it.
Devices that are unable to attain the goal of self
sustenance often use primary cells and attempt to make the
replacement of the batteries easy and less frequent. 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. However, while rechargeable
batteries can be charged a several hundred times, they
generally hold four to five times less energy than
non-rechargeable ones for comparable size and weight.
Devices that operate on rechargeable batteries must also
attempt to reduce the time taken to charge up the battery.
If the recharging can be serendipitous, i.e., combined
with some other benefit that is delivered to the user, such
as receiving information from the Internet, the user may
not perceive recharging as an inconvenience.
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.
The simplest way to increase the battery life is to use a
larger capacity battery which will be larger and heavier,
but the size and weight requirements on a wrist watch
place an upper bound on the capacity of the battery that
can be used to power it. With the best available
rechargeable Lithium polymer batteries today, the
maximum capacity of a battery measuring 3cm x 2cm x
0.5cm, that can be fit into a regular size watch, is about
200 mAh.
Second, replacing batteries on a watch is generally
difficult due to the small size of the watch and the need to
make the watch water resistant. A significant number of
customer complaints with watches directly result from
users trying to replace the batteries. 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. Users are
not accustomed to having to recharge wrist watches, but
may be willing to recharge other devices such as cell
phones and PDAs. 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.
As mentioned earlier, an advantage of the wrist watch
is that it is instantly viewable. A constraint that arises from
this aspect is that the watch should preferably have some
useful information on its display at all times. While saving
energy by turning off the display is an option on many
devices, doing so on a watch may take a significant
advantage away unless it can be done so cleverly that the
display is always on when the user is looking at the watch.
In the following sections we describe the energy
related tradeoffs associated to the device usage model, the
hardware, system level software and application level
software. We end with some suggestions for further
improvement of battery life.
2
DRAM
8MB
Li-Polymer
Battery
Touch
panel
x50
3.6MHz
OLED/LCD IF
x60
Exp. IF
TPC
Flash
8MB
IrDA
AMP
Bluetooth
PCM
PCM
UART
32KHz
Jog Wheel
Buttons
Tilt
Sensor
CL-EP7211
LCD
96x120
OLED
640x480
Buzzer
DC/DC

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 rest of the time, the device sleeps.
It transitions to the active mode in response to some action
by the user or the environment. Depending on how long
the device takes to come out of the sleep mode, there may
also be states in between these two extremes, such as an
idle mode where the device responds more quickly to the
user than if it were in the sleep mode.
As a gross approximation one may characterize the
device using two power metrics: The power consumed in
the active mode (P
active
) and the power consumed in the
sleep mode (P
sleep
). One can also approximate the actual
usage of the device using a single metric: the usage duty
factor (D) which is the fraction of the time the device
spends in the active mode.
Informal surveys reveal that owners of Palm Pilots
TM
use them about ten times a day for about 30 seconds at a
time. This adds up to about 5 minutes per day or a duty
factor of about 0.0035. Users of the ParcTAB [5] reported
that their device was on for less than 100 seconds at a
time. With today’s hardware, the device can periodically
go into an idle mode, unbeknownst to the user, even
when the user is actively interacting because of the
reaction time of the human user and further reduce the
actual duty factor. 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. An example of such a device is an MP3 player
watch where the user only needs to initiate the play
function and cause the watch to actively run and play the
music requested.
Observations of the usage patterns of wristwatches
suggest that the amount of time the user actually spends
interacting with the advanced features on a digital watch is
generally an insignificant fraction of the total time. This is
true for many high function wrist watches as well.
Calculators probably have an even smaller duty factor.
Based on these metrics, the average power consumed
by the device is given by P
sleep
(1-D) + P
active
D. If we
further define the ratio of active power to sleep power as
the power factor ratio: PFR = P
active
/P
sleep
, then the total
power consumed by the device is P
sleep
(1-D) + PFR * P
sleep
D = P
sleep
(1-D + PFR*D).
The PFR for our watch ranges from around 30 to 100
as seen from table in section 3. In comparison, PFR for a
PalmPilot
TM
ranges from 60 to 280 [6,7], the Psion Series
5
TM
PDA ranges from 70 to 240 [8], and the Compaq Itsy
ranges from 30 to 90 [9,10].
The battery life can be approximated as Battery
Capacity (mWh) / Average power consumed. This is an
approximation since battery capacity is not really a
constant but is a function of the precise wave form of the
load as opposed to just the average [11,12]. Nevertheless,
it is useful to examine the effects of the different
parameters on the battery life.
Figure 3 below shows the interplay between the usage
duty factor and the predicted battery life for the watch for
different power factor ratios. The duty factor is shown on
a logarithmic scale. The battery life is normalized to one
when the device is in the sleep mode all of the time. Once
the hardware is built, the PFR is fixed, and the
predominant way of extending the battery life is to
minimize the actual duty factor.
Ideally, both the minimum sleep current and the
maximum current consumption must both be minimized.
But which is more important depends on the duty factor.
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 we are at the left end of the
curves in Figure 3. On the other hand, if the duty factor is
much higher, say two hours a day, then we operate in the
middle of the graph and it is important make the PFR
smaller by reducing the active current consumption very
aggressively.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1min/day
5min/day
30min/day
1hr/day
2hr/day
5hr/day
8hr/day
12 hr/day
always
Relative Battery Life
Usage Duty Factor
PFR=10
PFR=20
PFR=50
PFR=100
PFR=250
Figure 3. Relative battery life versus duty factor.
3 Hardware level energy trade-offs
The upper and lower bounds on the battery life for a
device are determined by hardware. The maximum battery
life depends on the minimum sleep current that can be
achieved. Similarly, the minimum battery life is dictated
by the maximum current consumption when all hardware
components are turned on.
3

We attempted to keep the energy requirement as low
as possible by choosing energy efficient components
whenever possible. However, energy efficiency often
comes with less function, e.g., task specific hardware can
generally operate at a lower energy cost compared to a
programmable processor, and smaller memories consume
less power to refresh than larger ones. Compared to other
wrist watches our design trades off energy efficiency for
greater function, as is evident from the 32-bit processor
and large amount of memory we incorporated.
Fitting all of the components onto a small board,
measuring 27.5 mm x 35.3 mm, was very challenging.
Even when more energy efficient components were
available, we were unable to use them because they were
larger and would have increased the size of the circuit
board. For instance we used a voltage regulator with a
leakage current of 100µA since it was a factor of 8 smaller
than a voltage regulator with a leakage current of 10µA.
Often controls are provided to turn off portions of the
hardware to save energy. For example, in some systems
multiple DRAM banks are used and some banks are
powered off when the software knows that a particular
DRAM bank is not being used. However, we do not have
the room on the main board to be able to fit several
memory modules and hence cannot apply multiple DRAM
banks to mitigate the power problem in the sleep mode.
Likewise we did not have any room to have a battery
backup or a capacitor to preserve DRAM contents if the
main battery was discharged.
In order to drive all of the components in our watch,
except for Bluetooth
TM
, we needed a battery that could
supply currents as high as 50 mA. This constraint ruled
out coin cells and led us to choose a rechargeable Lithium
Polymer battery. A rechargeable battery was also
appropriate since we did not want to open the watch to
replace the battery often.
Within the constraints of function and size, we
designed the hardware to be as energy efficient as
possible. The processor we chose, an EP7211 chip [16]
from Cirrus Logic, supported most of our required
peripherals such on chip ROM, integrated LCD controller,
IrDA controller, UART, serial, PCM and serial bus
interfaces, etc., and we did not require the space or power
for additional glue logic. The processor itself was used in
bare die package instead of the regular package to save
both space and power. We run the processor at 18Mhz
though it can run up to 74 Mhz. The processor supports
two power saving modes called IDLE and STANDBY
which are described below. In addition, we ensured the
input devices on the watch, namely a touch panel, a roller
wheel and a tilt sensor, consumed no power in the standby
mode.
Another significant power saving feature we
incorporated into the OLED display was the ability rapidly
turn the pixels on and off and to control its brightness by
adjusting the ratio of the time that the pixels are on to the
time they are is off. We also have a clear instruction in the
OLED that clears the display without requiring the CPU to
zero all the pixels individually.
Table 1 lists the manufacturer specified power
consumption for various components in operational and
standby state in our system. (Vdd=3.3V in most cases.)
1.82198/132Bluetooth (early hw)
0.003/0.0000.6/0.3DC-DC 2.5V
0.003/0.0000.6/0.3DC-DC 3V
0.0027.2/4.8SPK Amp
0.03127/15Codec
0.017/0.000-/3LCD
0.003/0.00086/66IrDA
0.008/-1.8/-Touchpanel ctrller
-/0.00172/-Flash (8MB)
0.660/-363/-DRAM (8MB)
0.010/-50/-CPU (EP 7211)
max/typ [mW]max/typ [mW]
Component
SleepOperational
Table 1. Manufacturer specified power consumption in
operational mode and in sleep/disable mode.
The range for power quoted by the specifications
sheets for some components is rather large and the actual
consumption is determined by the usage scenario and how
the components are configured and interoperate, e.g., can
the Flash and the DRAM be consuming their peak powers
at the same time due to the bus architecture. Tools are
needed to measure power accurately [13]. Also, measuring
the power consumed by the various components is not
straightforward in many situations because there may be
no way to turn off a particular component explicitly, e.g.,
the DRAM, once Linux is running. In these situations we
devise a set of tests that are similar to power on self test,
and measure the power consumed by various components
before the operating system is loaded. One more issue we
had was that the battery capacity also reduces over time
and some of our current batteries appear to have only
35mAh as opposed to 60mAh when they were fresh.
Furthermore we managed to reduce the operational
voltage to be a little lower, i.e. from 3.3V to 3.0V, by
selecting all other components such as Flash memory,
DRAM, touch panel controller and the IrDA module to be
the same and this reduced the power consumption by an
estimated 17.3%, assuming static CMOS. The voltage
regulators consume 200 A and 45 A is consumed in
bias circuits. Table 2 shows the current consumption in
the watch in the different states of its usage. (Note,
multiply by 3.7V nominal battery voltage to get
corresponding power.)
As a comparison, typical standby currents of the Palm
IIIx
TM
(4 MB of memory) is 300A, that of the Psion
4

Series 5
TM
is 540A (8 MB of RAM). In active modes
(with the backlight off though), the current consumption
in the Palm IIIx
TM
ranges from around 15 mA to 65
mA[6,7], and that for the Psion Series 5
TM
ranges from 35
mA to 130 mA [8]. The backlights on the Palm IIIx add
about 40 mA and on the Psion Series 5 add about 70 mA
to the above numbers.
How far can we go with hardware improvements?
Even with the 200mAh in a state of the art Lithium
polymer battery, if the system designer wants the battery
to last a year, to a first order approximation, ignoring
battery non-linearities and dependence on battery recovery
processes on peak current drained and the self discharge
of the battery, the average current consumption in the
device should be 200/(365*24) = 23A or less. This is an
order of magnitude lower than the Palm IIIx
TM
consumes
with 4MB RAM. We also have to fight about a 5% self
discharge rate per month in Lithium polymer batteries
[14].
565 A
Self Refresh
298 A
Off
0A
STANDBY
22 A
913 A
Self Refresh
298 A
On
348 A
STANDBY
22 A
4.6 mA
Processor
Refresh
> 298 A
On
348 A
IDLE
<3744A
15-55mA
average of
27.5mA
Active
access
0.3-40mA
On
348 A
OPERATION
14mA
Total currentDRAMLCDProcessor
Table 2. Current consumption of main components
in various states (measured at battery
terminal).
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 we 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. In this situation, the kernel switches the processor
into the IDLE mode. Also the kernel relies on a timer to
interrupt it every 10 ms in order to guarantee fair
scheduling amongst the tasks that are ready to run. Every
10 ms when the timer interrupt occurs the processor
switches to the active mode for a short duration when it
updates the kernel time variables and checks the task
queue. If there are no tasks that are runnable, the kernel
puts the processor back into the IDLE mode. The
processor also comes out of the IDLE mode when there is
an external interrupt as would occur if the user wanted to
interact with the watch. Also tasks can request to be
woken up at some point in the future. The kernel
maintains a list of such tasks in a timer list. At each timer
tick the kernel checks to see if sufficient time has elapsed
to wake up one or more sleeping tasks.
As observed earlier, the energy required by the
processor in the IDLE mode is much higher than the
energy required in the STANDBY mode. So we first
focused on trying to get the processor into the STANDBY
mode instead of the IDLE mode when there was no work
to do.
On the ARM processor we used in our watch the 10 ms
timer is not available in the STANDBY mode. However
I/O interrupts work and a real time clock (RTC) which
operates on a one second granularity is available. Also the
processor may take up to 250ms to get out of STANDBY
mode but coming out of the IDLE mode typically takes
only a few clock cycles. From a user perspective, the
250ms delay is perceptible, but not annoyingly so.
In order to take advantage of the more efficient
STANDBY mode, we had to rewrite the Linux timing
methodology for our system. The basic idea is as follows:
Whenever the scheduler found that it could put the
processor in the IDLE mode, we scan the timer list to see
how much time needs to elapse before any of the tasks
need to woken up. If this time-out interval is long enough
we put the processor in STANDBY mode after
programming the real-time clock (RTC) to wake us up
before this time-out. When we come out of the
STANDBY mode either on a RTC interrupt or some other
interrupt, we adjust the kernel time variables so that the
kernel knows how much time has really elapsed. If the
nearest task is too close for the 1 second granularity of the
RTC, we go into IDLE mode instead and program the
10ms timer to wake us up at the time-out period.
Our changes to the Linux kernel seem to work fine
with all of the applications we have tested so far, though
we have not tested this code with a more demanding set of
user workloads.
Figure 4 shows a pseudo code snippet of the changes
we made. This code is from the "main idle loop" in Linux,
and is in the file arch/arm/kernel/process.c. The lines in
bold are the statements we have added. The operation is as
follows. Whenever the current task that is executing in
Linux has run to completion, control is returned to the
main idle loop. At the very top of the loop, the current
task is checked to see if it needs scheduling. If there is no
current task that needs scheduling, work_candidate() is
called to resolve if there are other tasks that are eligible
for scheduling. If there are no tasks, then there's no work
5

Citations
More filters

Journal ArticleDOI
TL;DR: Some future research directions that are aimed at transitioning the concept of energy harvesting for embedded SHM sensing systems from laboratory research to field-deployed engineering prototypes are defined.
Abstract: This paper reviews the development of energy harvesting for low-power embedded structural health monitoring (SHM) sensing systems. A statistical pattern recognition paradigm for SHM is first presented and the concept of energy harvesting for embedded sensing systems is addressed with respect to the data acquisition portion of this paradigm. Next, various existing and emerging sensing modalities used for SHM and their respective power requirements are summarized followed by a discussion of SHM sensor network paradigms, power requirements for these networks, and power optimization strategies. Various approaches to energy harvesting and energy storage are discussed and limitations associated with the current technology are addressed. The paper concludes by defining some future research directions that are aimed at transitioning the concept of energy harvesting for embedded SHM sensing systems from laboratory research to field-deployed engineering prototypes. Finally, it is noted that many of the technologies discussed herein are applicable to powering any type of low-power embedded sensing system regardless of the application.

416 citations


Book ChapterDOI
03 Nov 2003
TL;DR: This work proposes to use multiple acceleration sensors that are distributed over the body, because they are lightweight, small and cheap, because activity can best be measured where it occurs.
Abstract: For wearable computing applications, human activity is a central part of the user’s context. In order to avoid user annoyance it should be acquired automatically using body-worn sensors. We propose to use multiple acceleration sensors that are distributed over the body, because they are lightweight, small and cheap. Furthermore activity can best be measured where it occurs. We present a hardware platform that we developed for the investigation of this issue and results as to where to place the sensors and how to extract the context information.

326 citations


Cites background from "Energy trade-offs in the IBM wristw..."

  • ...Already today, there are devices available that integrate them [1]....

    [...]


Patent
30 Jul 2004
Abstract: The present invention is directed to a session initiation protocol (SIP) infrastructure containing various user devices and the use of this infrastructure to conduct media exchange sessions among the various user devices. Included in the user devices are wearable devices, for example pendants and wrist watches, that provide readily available and accessible devices for use in controlling the media exchange sessions. SIP permits the separation of the control aspects of a session from the actual media exchange aspects to facilitate the use of wearable devices having limited processing resources as control devices. The actual media exchange is directed to user devices suitable for sending, receiving and displaying the exchanged media.

278 citations


Proceedings ArticleDOI
14 Mar 2004
TL;DR: This work describes three main methods for an attacker to drain the battery and proposes a power-secure architecture to thwart these power attacks by employing multi-level authentication and energy signatures.
Abstract: Sleep deprivation attacks are a form of denial of service attack whereby an attacker renders a pervasive computing device inoperable by draining the battery more quickly than it would be drained under normal usage. We describe three main methods for an attacker to drain the battery: (1) service request power attacks, where repeated requests are made to the victim for services, typically over a network - even if the service is not provided the victim must expend energy deciding whether or not to honor the request; (2) benign power attacks, where the victim is made to execute a valid but energy-hungry task repeatedly, and (3) malignant power attacks, where the attacker modifies or creates an executable to make the system consume more energy than it would otherwise. Our initial results demonstrate the increased power consumption due to these attacks, which we believe are the first real examples of these attacks to appear in the literature. We also propose a power-secure architecture to thwart these power attacks by employing multi-level authentication and energy signatures.

194 citations


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 [12], 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....

    [...]


Patent
03 Dec 2001
Abstract: Short duration micro-sleep or nap periods reduce the power consumption of a computing device. In use, the computing device determines a first duration to a next expected event in the computing device, and compares the first duration to a minimum micro-sleep duration. If the first duration is greater than or equal to the minimum duration, then the processor enters a processor sleep state for a sleep duration. The processor then wakes up and returns to a running state at the end of the sleep duration and before the next expected event. This permits the use of a low-power sleep state while giving the appearance that the computing device is functional. As an additional requirement before entering micro-sleep, the current or recent processor load may be evaluated to determine whether a micro-sleep interval is appropriate.

163 citations


References
More filters

Book
30 Aug 2001
Abstract: Part 1 Principles of operation: basic concepts electrochemical principles and reactions factors affecting battery performance standardization of batteries battery design selection and application of batteries. Part 2 Primary batteries: zinc-carbon (Leclanche) cells magnesium and aluminium cells alkaline-manganese dioxide cells mercuric oxide cells silver oxide cells zinc/air cells lithium cells solid electrolyte batteries. Part 3 Reserve batteries: magnesium water-activated batteries spin-dependent reserve batteries liquid ammonia systems lithium anode reserve batteries thermal batteries. Part 4 Secondary batteries: lead acid batteries industrial nickel-cadmium batteries vented nickel-cadmium batteries sealed nickel-cadmium batteries nickel-zinc batteries iron electrode batteries silver-oxide batteries nickel-hydrogen batteries nickel-metal hydride batteries rechargeable alkaline-manganese dioxide batteries. Part 5 Advanced battery systems: ambient temperature lithium batteries zinc/bromine batteries metal/air batteries lithium/iron sulphide batteries sodium beta batteries.

2,184 citations


Journal ArticleDOI
TL;DR: This paper explores the possibility of harnessing the energy expended during the user's everyday actions to generate power for his or her computer, thus eliminating the impediment of batteries.
Abstract: Batteries add size, weight, and inconvenience to present-day mobile computers. This paper explores the possibility of harnessing the energy expended during the user's everyday actions to generate power for his or her computer, thus eliminating the impediment of batteries. An analysis of power generation through leg motion is presented in depth, and a survey of other methods such as generation by breath or blood pressure, body heat, and finger and limb motion is also presented.

846 citations


Proceedings ArticleDOI
25 Feb 1999
TL;DR: Using PowerScope, a tool for profiling energy usage by applications, the approach combines hardware instrumentation to measure current level with kernel software support to perform statistical sampling of system activity.
Abstract: We describe the design and implementation of PowerScope, a tool for profiling energy usage by applications. PowerScope maps energy consumption to program structure, in much the same way that CPU profilers map processor cycles to specific processes and procedures. Our approach combines hardware instrumentation to measure current level with kernel software support to perform statistical sampling of system activity. Postprocessing software maps the sample data to program structure and produces a profile of energy usage by process and procedure. Using PowerScope, we have been able to reduce the energy consumption of an adaptive video playing application by 46%.

543 citations


Book ChapterDOI
01 Jan 1996
TL;DR: The Ubiquitous Computing philosophy, the ParcTab system, user-interface issues for small devices, and the experience developing and testing a variety of mobile applications are described.
Abstract: The ParcTab system integrates a palm-sized mobile computer into an office network This project serves as a preliminary testbed for Ubiquitous Computing, a philosophy originating at Xerox PARC that aims to enrich our computing environment by emphasizing context sensitivity, casual interaction and the spatial arrangement of computers This paper describes the Ubiquitous Computing philosophy, the ParcTab system, user-interface issues for small devices, and our experience developing and testing a variety of mobile applications

305 citations


Journal ArticleDOI
TL;DR: The Compaq Itsy, a prototype pocket computer that has enough processing power and memory capacity to run cycle-hungry applications such as continuous-speech recognition and real-time MPEG-1 movie decoding, has proved to be a useful experimental tool for interesting applications, systems work and power studies.
Abstract: The Compaq Itsy, a prototype pocket computer that has enough processing power and memory capacity to run cycle-hungry applications such as continuous-speech recognition and real-time MPEG-1 movie decoding, has proved to be a useful experimental tool for interesting applications, systems work and power studies.

95 citations


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. 

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.