MASARYK UNIVERSITY

FACULTY OF INFORMATICS

Measurements of energy consumption

and execution time of different operations
on Tmote Sky sensor motes

MASTER THESIS

Moslem Amiri

Brno, 2010

Declaration
Hereby I declare that this paper is my original authorial work, which I have worked out by my own.
All sources, references and literature used or excerpted during elaboration of this work are properly
cited and listed in complete reference to the due source.

Advisor: RNDr. Andriy Stetsko

ii

Acknowledgment
I would like to thank RNDr. Andriy Stetsko, the advisor of my master thesis, for his valuable
comments, suggestions and time he spent helping me with this work.

iii

Abstract
In order to provide WSNs with security, additional energy is required. Since sensor motes usually
have limited source of energy, it is important to balance the level of security and energy consumption.
To find this trade-off, we need to know the amount of energy consumed by different components on
sensor motes while running security algorithms. In this work we perform some measurements to
estimate the energy consumption and execution time of different operations on a Tmote Sky sensor
mote. This device is equipped with CC2420 radio transceiver, MSP430 microcontroller, and ST
M25P80 flash memory. To make the measurements, first we explore different methods to that end,
and then set up the best possible configuration in order to perform precise measurements.
For the transceiver, since CC2420 is an IEEE 802.15.4 compliant radio, we investigate different
frame structures and CSMA/CA medium access mechanism of this standard to discover the overhead
of channel acquisition, header and footer of data frame, and transfer reliability during packet
transmission. Next, the implementation of this standard in TinyOS, a popular operating system widely
used in WSNs, is taken into consideration. Then we measure time and energy needed to send and
receive a 1-byte data payload, an 11-byte acknowledgment frame, and an 18-byte header and footer of
the data frame in TinyOS. We also compute the energy consumed during channel acquisition and
listening operations. This data makes the fixed and incremental components of a linear equation to
estimate the power consumed during every packet transmission. Finally, we input this per-packet
power consumption in a mathematical model which estimates the lower and upper bounds of routings
in the network.
We categorize different simulators currently available in order to propose the function and
structure of a new potential simulator. Due to the fact that radio operations are the most expensive
ones in sensor motes, this proposed simulator focuses on radio rather than internal operations.
The microcontroller of Tmote Sky, MSP430, has several power states with varying power draws.
We measure energy consumptions in different power states of this microcontroller.
We also compute the energy consumption and time needed to write/read one byte of data from/to
ST M25P80, the external flash memory of Tmote Sky.

iv

Keywords
CC2420 radio, execution time, IEEE 802.15.4, lifetime bounds, measurements, MSP430
microcontroller, power consumption, simulator, ST M25P80 flash memory, Tmote Sky sensor mote,
wireless sensor network

Contents
Chapter 1: Categorizing simulators for wireless sensor networks..........................................................2
1.1 General-purpose simulators.........................................................................................................2
1.1.1 Taxonomy based on the level of accuracy...........................................................................2
1.1.2 Taxonomy based on the internal structure............................................................................4
1.2 Simulators for power consumption evaluation............................................................................7
1.2.1 Overall power usage approximation.....................................................................................7
1.2.2 Instruction level simulation..................................................................................................7
1.2.3 Logging power state transitions............................................................................................7
Chapter 2: Experimental measurements of the power consumption for WSNs....................................11
2.1 Using a shunt resistor................................................................................................................11
2.2 Using a clamp-on current probe................................................................................................12
2.3 Improved clamp-on current probe method................................................................................12
2.4 Using GoldCap capacitor for lifetime bounds...........................................................................13
Chapter 3: Measurement Setup.............................................................................................................15
Chapter 4: Experiments using Tmote Sky sensor motes.......................................................................18
4.1 TinyOS......................................................................................................................................18
4.2 Power States of MSP430 microcontroller.................................................................................19
4.3 CC2420 Radio...........................................................................................................................22
4.3.1 IEEE 802.15.4....................................................................................................................23
4.3.2 RSSI/Energy Detection......................................................................................................24
4.3.3 Clear Channel Assessment.................................................................................................24
4.3.4 The CSMA/CA algorithm..................................................................................................24
4.3.5 CCA and Sending...............................................................................................................25
4.3.6 Low power listening...........................................................................................................28
4.3.7 Listening and Receiving.....................................................................................................28
4.4 External Flash............................................................................................................................29
4.4.1 Writing to external flash.....................................................................................................30
4.4.2 Reading from external flash...............................................................................................30

vi

Chapter 5: Evaluation of lifetime bounds of WSNs..............................................................................31

5.1 A Mathematical Model of Energy Consumption of Routings...................................................31
5.2 Modeling Per-packet Energy Consumption..............................................................................33
5.3 Measurement of Bounds Using Tmote Sky Sensor Motes........................................................34
5.4 Proposing a new simulator for WSNs.......................................................................................35
Chapter 6: Conclusion...........................................................................................................................37
References.............................................................................................................................................38

vii

Introduction
A Wireless Sensor Network can be composed of tens to thousands of sensor motes spread in a wide
area and communicating with each other either directly or through the other nodes. One or more of the
nodes are the base station with more or unlimited power supply than the other nodes. The user either
has direct access to the base station or through a wired network. The motes have limited power
supply, very often without the possibility to be recharged. WSNs are vulnerable to attacks; therefore it
is important to provide security services like integrity, confidentiality and authenticity for them.
Applying security to the sensor nodes requires additional energy. Thus we need to make trade-off
between the level of security and energy consumption of WSNs. To find such trade-off, the energy
consumed while running different security algorithms must be known. This requires us to provide a
precise simulator which is able to simulate energy consumption as well. To this aim, it is necessary to
find the power consumption model of sensor motes. To provide this power model, we go through a
series of measurements in this work and estimate the power consumed while running different
operations on sensor motes.
This text is organized as follows. In chapter 1, we discuss different structures for simulators in
order to propose a new simulator for power consumption of wireless sensor networks later in this text.
In chapter 2, we discuss different experimental methods currently available in order to measure the
power consumption of sensor motes. In chapter 3, we explain our measurement setup based on the
methods explained in chapter 2. Then in chapter 4, we provide precise measurements of energy
consumed during different operations on Tmote Sky sensor motes. In chapter 5, we represent a
mathematical model of lifetime bounds of a network in brief. Also, a model for per-packet energy
consumption of routings, using the results from chapter 4, is represented in this chapter, and finally
combining these two existing models, evaluation of lifetime bounds of a network is suggested. Later
in this chapter, we propose the structure of a new simulator. Chapter 6 presents the conclusion.

Chapter 1: Categorizing simulators for

wireless sensor networks
In this chapter, we discuss different structures of simulators currently available in order to propose a
new simulator for power consumption of wireless sensor networks. First, methods of constructing
general-purpose simulators are explored, and then the state-of-the-art methods used to construct
simulators considering power consumption are explained.

1.1 General-purpose simulators

1.1.1 Taxonomy based on the level of accuracy
One approach to categorizing different simulators can be the goal for simulation environment; in
some cases, the goal is to work at a very abstract level, while in others, the goal is to accurately
simulate the behavior of the target system. Simulation cost typically increases quickly with the level
of detail, so a tradeoff must be considered between the level of accuracy needed and the cost. Several
different structures have been implemented so far to achieve the intended goals:
1) Simulation via direct execution [4][6]
2) Simulation via direct execution with code augmentation [6]
3) Simulation via binary translation [4]
4) Simulation via detailed software interpretation [4]
Now we go through each of these methods.
1.1.1.1 Simulation via direct execution
This method can be used when the host and target architectures are similar. This similarity can be
exploited by directly using the underlying machines hardware (of host system) to support the
operating system and applications under investigation (of target system).
Every operating system needs to have access to the underlying hardware and resources. Since the
host system on which we want to run the target operating system (along with its applications), has an
operating system for itself, so the target operating system cannot be loaded on another operating
system. So in this method the simulator creates a user-level environment that looks like raw hardware,
so the target operating system can run on top of it.
To overcome the problem of not having direct access to the hardware (simulator provides hardware
in user-level for target system), each target machine feature (like CPU, memory, I/O) is implemented
in user-level application in a different way on host machine to provide direct hardware access for
target operating system. For example, CPU is simulated by using process abstraction provided by
host operating system. This strategy limits the target instruction to be binary-compatible with the host
instruction set [4]. Instead of this limitation of target instructions, another technique is to directly
2

execute the compatible instructions on the host machine and simulate non-compatible ones via
procedure calls [6]. Since there are CPU features unavailable to user level processes (like trap
architecture or the execution of privileged instructions), simulator needs to handle them explicitly by
methods like CPU process notification by host OS or signaling by host OS. Simulation time increases
by handling such challenges. Likewise, the other target machine features are created in user-level
environment via different methods; physical memory via a single file representing the physical
memory of the target machine, and I/O device interrupts via sending signals of the host operating
system to the target CPU processes by simulated devices, and so on.
The direct execution mode often executes an operating system and target applications only two
times slower than they would run on the host hardware. Thus it is considered a fast simulation
method. Although it is quick, it does not model any aspect of the simulated systems timing.
Furthermore, it requires compatibility between the host platform and the architecture under
investigation.
1.1.1.2 Simulation via direct execution with code augmentation
Although direct execution provides the correct functionality of local instructions, it ignores the time
required to execute them. Code augmentation can be used to count the cycles required by the
instructions. For each basic block of instructions, code is added to increment a cycle counter by the
number of cycles required to execute that block.
This counter can be used in nonintrusive monitoring and debugging. Adding the monitoring code
may cause the behavior which we are monitoring to be affected, so we add non-cycle-counted code to
ensure no change in the behavior. To do so, we need to first turn off cycle counting, then add the extra
code (code for monitoring and debugging) and then turn on the counting.
1.1.1.3 Simulation via binary translation
This approach provides accuracy and does not have the defects mentioned for the previous methods.
This mode uses on-the-fly object code translation to dynamically convert target application and
operating system code into new code that simulates the original code running on a particular hardware
configuration.
To reduce the time spent on runtime code generation, simulator stores the code block translations
in a large translation cache. After receiving every basic block, the simulator searches the cache to see
if a translation of this code already exists. Basic block translations present in the cache are re-executed
without imposing translation costs.
The strongpoint of this method is that depending on the level of detail we need, it is possible to
adopt a different translation policy. We can have a fast binary translation mode by just counting the
number of instructions executed, and obviously for obtaining more details, more complete translation
is needed. Another strongpoint is that by simulating each target machine by a separate process, we can
benefit from concurrency and gain more speed.

Figure 1.1: Binary translation mechanics. Binary translation converts an instruction sequence from a block of
code in the target machines instruction set into a code sequence that runs on the host. Above, simRegs is an
array that holds the state of the target CPUs registers. The translated code uses simRegs to perform operations
on the target machines registers and memory. MMU is the Memory Management Unit of CPU responsible to
relocate virtual addresses to a location in physical memory. The MMU address translation and cycle-counting
annotations support the operating system. Adding a cache simulation entails adding two instructions to the
MMU translation. All instruction counts are for the hit case. Misses necessitate calling support functions. [4]

1.1.1.4 Simulation via detailed software interpretation

The previous method is fast and provides detailed information about memory system behavior.
However, for detailed multiprocessor studies, it is not accurate; simulating a separate user process for
each CPU in the target machine reduces the accuracy of instruction and memory reference
interleaving but it allows the simulated processors to run concurrently on a multiprocessor host.
To address this deficiency, all target CPUs are simulated in a single process, and instructions are
interpreted using a straightforward fetch, decode, and execute loop. This way we provide precise,
cycle-by-cycle interleavings of all CPUs. Precise cycle interleavings allow device interrupts to occur
with precise timing and allow more accurate cache simulation. The simulator includes a pipeline
model that records more detailed performance information at the cost of longer simulation time. The
additional accuracy of this mode and its inability to exploit parallelism on a multiprocessor host result
in a tremendous slowdown in simulation.

1.1.2 Taxonomy based on the internal structure

1) Use of multiple languages [5]
2) Use of modular structure [6]
3) Use of actual implementation of algorithms along with event queue [7]

1.1.2.1 Use of multiple languages

The best example for such approach is Network Simulator Version 2 (ns-2), a discrete event simulator
for networking research. This simulator is used when the real features are not available yet and its
disadvantage is that the real systems are too complex to model. It provides substantial support to
simulate a bunch of protocols like TCP, UDP, FTP, HTTP, and is used for simulating both wired and
wireless networks. Furthermore it provides different routing algorithms, traffic models, error models,
radio propagation, mobility models, and energy models, along with topology generation tools and
visualization tools and tracing.
This simulator maintains a list of events and executes one event after another. There is a single
thread of control; hence there is no locking or race condition. The most important factor of this
simulator is use of two different programming languages in its construction. In the back end C++
language is used which provides implementations for protocols, since it is fast to run and there is no
need for change at this part of the simulator. In the front end oTCL is used which is good for creating
different scenarios and is fast to write and change.
1.1.2.2 Use of modular structure
In this approach, every part of the target architecture is implemented in a separate module. It provides
two important abilities: first, it simplifies customizing the target architecture, since it is easy to work
with one part of the architecture while keeping the rest unchanged. Second, through the modular
structure, we can provide multiple implementations of a given module. It allows users to switch
between very accurate versions and very fast versions based on what they need.
1.1.2.3 Use of actual implementation of algorithms along with event queue
TOSSIM, a discrete event simulator for TinyOS wireless sensor networks, has been implemented
using this approach. This simulator allows studying entire applications including the operating system
and the network stack for very large number of nodes. It only replaces a few low-level TinyOS
systems that touch hardware. Since TinyOS uses an event-driven execution, hence TOSSIM
implements a simple discrete event method. The whole program compilation process is re-targeted for
the simulators storage model and native instruction set; component variables are replaced with an
array of them, one copy for each simulated mote. As individual mote resources are very small, we can
simulate many of them within the simulators address space. The static component memory model of
TinyOS simplifies state management for these large collections.
The TOSSIM architecture is composed of five parts: support for compiling TinyOS component
graphs into the simulation infrastructure, a discrete event queue, a small number of re-implemented
TinyOS hardware abstraction components, mechanisms for extensible radio and ADC models, and
communication services for external programs to interact with a simulation.
The network in TOSSIM is a directed graph in which vertices are nodes and edges have bit error
probability.

Figure 1.2: TOSSIM Architecture

By replacing a few low-level components (those shaded in figure 1.2), TOSSIM translates
hardware interrupts into discrete simulator events; the simulator event queue delivers the interrupts
that drive the execution of a TinyOS application. When the core loop executes a simulator event, it
sets global state to indicate which mote is currently running. A simulator event calls an interrupt
handler in hardware abstraction components. The interrupt handler signals TinyOS events and calls
TinyOS commands, just as it would on a mote. The remainder of TinyOS code runs unchanged.
TOSSIM keeps time at 4 MHz. All simulator events are timestamped and processed in global time
order.

Figure 1.3: Sample execution

The program in the figure 1.3 has a 1 Hz timer that samples the light sensor and displays the three
high order bits of the reading on the mote LEDs. Since simulator time is kept in 4 MHz clock, the
timer events are four million ticks apart, and the 50 s ADC capture takes 200 ticks between request
and interrupt.

1.2 Simulators for power consumption evaluation

When we need to work with the behavior of different hardware components and in a special case, the
power consumed by each sensor mote, another taxonomy is needed:
1) Overall power usage approximation
2) Instruction level simulation [8]
3) Estimating the number of CPU cycles [9]

1.2.1 Overall power usage approximation

In this method, we estimate every nodes duty cycle, i.e. the fraction of time each node is busy, and
communication rates and time, to simply approximate the overall power usage. Knowing the power
model of a sensor mote, i.e. the power consumed during its every components operations, and the
fraction of time each component is active for a specific task, we can estimate the overall power
consumption of the sensor mote for a given time period. This method often fails to capture the
detailed, low level energy requirements of different target features.

1.2.2 Instruction level simulation

In this method, the simulator uses the same binary that is loaded onto the sensor node and uses its
target processor emulation engine to very accurately model the execution of code on each sensor
node. This way it can provide detailed information of power consumption for different features of
target system. This method is too expensive and often fails to simulate large numbers of instances of
target system, e.g. a bunch of sensor nodes.

1.2.3 Logging power state transitions

PowerTOSSIM is a scalable simulation environment based on TOSSIM for wireless sensor networks
that provides an accurate, per-node estimate of power consumption.
The first challenge in simulating the power consumption of sensor motes is obtaining an accurate,
detailed model of a typical nodes power consumption. As for PowerTOSSIM, the power
consumption model for Mica2 sensor node (developed by UC Berkeley) is measured. This power
model is seen in figure 1.4.

Mode
CPU
Active
Idle
ADC Noise Reduce
Power-down
Power-save
Standby
Extended Standby
Internal Oscillator
LEDs
Sensor board
EEPROM access
Read
Read Time
Write
Write Time

Current Mode
8.0 mA
3.2 mA
1.0 mA
103 A
110 A
216 A
223 A
0.93 mA
2.2 mA
0.7 mA

Radio
Rx
Tx (-20 dBm)
Tx (-19 dBm)
Tx (-15 dBm)
Tx (-8 dBm)
Tx (-5 dBm)
Tx (0 dBm)
Tx (+4 dBm)
Tx (+6 dBm)
Tx (+8 dBm)
Tx (+10 dBm)

Current
7.0 mA
3.7 mA
5.2 mA
5.4 mA
6.5 mA
7.1 mA
8.5 mA
11.6 mA
13.8 mA
17.4 mA
21.5 mA

6.2 mA
565 s
18.4 mA
12.9 ms

Figure 1.4: Power model for Mica2 (with 3 V power supply)

PowerTOSSIM tracks the power state of each hardware component of the simulated motes by
generating specific power state transition messages that are logged during the simulation run. This
is done by instrumenting the TOSSIM simulated hardware components with calls to a new
component, PowerState, which tracks hardware power states for each mote and logs them to a file
during the run. This file, which contains power state transition calls, can be combined with the power
model (figure 1.4) to generate detailed power consumption data or visualization. The process of
generating power usage can be performed using offline tools (actually the generation and processing
of power state transition data are decoupled).
The challenge is estimating the CPU power usage; since PowerTOSSIM runs the mote software as
a native binary of the host machine (in fact TOSSIM and PowerTOSSIM retarget compilation
process to host machines binary code instead of the motes binary), it has no information on the
length of time that a given mote spends using the CPU (active state or idle state or the other states).
The amount of time that a node spends in idle mode depends on external factors, such as the timing of
clock interrupts, which are already modeled by TOSSIM. However, the amount of time spent
executing CPU instructions is not captured by TOSSIM.
To capture CPU execution time, PowerTOSSIM behaves as follows:
1) Instrument the PowerTOSSIM binary to obtain an execution count for each basic block (run
of instructions with no branches) executed by the simulated CPU.
2) Map each basic block to its corresponding assembly instructions in the AVR binary (AVR is a
single chip microcontroller developed by Atmel and used in Mica2 sensor node).
3) Determine the number of CPU cycles for each basic block using simple instruction analysis.
4) Combine the simulation basic block execution counts with their corresponding cycle counts to
obtain the total CPU cycle count for each simulated mote.
At the end of the simulation run, PowerTOSSIM logs basic block execution counters that are
processed offline in the manner described above to obtain CPU cycle count totals. The power
consumptions for active and idle states are computed in the power model (figure 1.4), and the cycle
8

time for each instruction is well-documented, so using this information we can compute the power
consumption for the CPU.

Figure 1.5: PowerTOSSIM architecture

To implement the four steps described above in capturing CPU execution time, the used method is
as follows: the NesC compiler inputs the entire TinyOS component graph and outputs a single C
source code, and then a back-end compiler compiles this C code to the target platform. In
implementing PowerTOSSIM, this intermediate C source file is instrumented with basic block
execution counters with the help of C Intermediate Language (CIL). Using CIL, a set of source
transformation rules are written to the C source code that insert an execution counter into each basic
block of the program. Moreover, this transformation code records the line number of the original
NesC source code corresponding to each basic block. This way we can map basic blocks back to their
original source code line number. The next step is mapping each basic block to the appropriate
number of CPU instructions as executed by the sensor mote. To do so, the TinyOS application is
compiled to a mote binary and then with the help of a disassembler, the set of AVR instructions for
each source code line is obtained. This is then correlated with the basic block line number information
9

to obtain the set of assembly instructions corresponding to each basic block. Then using the datasheet
of the sensor mote, the CPU cycle counts for each instruction is obtained and summed up. After the
simulation, the basic block execution counts are recorded and using the method above, the CPU cycle
counts for each mote is achieved.

10

Chapter 2: Experimental measurements

of the power consumption for WSNs
In this chapter, we discuss different experimental methods currently available in order to measure the
power consumption of wireless sensor networks.
There are commonly four different experimental ways to determine the power consumption of a
system under test, three of which provide runtime monitoring and one lifetime bounds. These methods
are:
1) Using a shunt resistor [1]
2) Using a clamp-on current probe [1]
3) Improved clamp-on current probe method [2]
4) Using GoldCap capacitor for lifetime bounds [3]

2.1 Using a shunt resistor

The most commonly used approach toward the measurement of power consumption utilizes a shunt
resistor. A shunt is a high precision resistor.

+
Figure 2.1: Power measurements with shunt resistor; SUT System Under Test.

(2.1)

The drawback of this approach is that the shunt resistor interferes with the operation of the system
under test which is not suitable when there are large variations of current, while the advantage of this
method is that it is less susceptible to noise.

11

2.2 Using a clamp-on current probe

This simple and widely used approach utilizes a current probe. Current probes provide voltage as
output which is typically a linear function of the current through the clamp.
+

Figure 2.2: Power measurements with current probe; SUT System Under Test.

. ,

(2.2)

Contrary to the previous approach, the advantage of this method is that it is unobtrusive while its
drawback is that it is more susceptible to noise.

2.3 Improved clamp-on current probe method

Figure 2.3: Block diagram of the environment for run-time power monitoring for wireless sensor platforms.
Description: DMM Digital Multimeter, DAQ Data Acquisition Card, SUT System Under Test.

12

In this approach, the current probe approach is advanced to provide more precise measurement.
As mentioned before, the current probe, which is clamped directly around the power supply line,
produces an output voltage that is proportional to the current in the line. Now in this approach, the
linear dependency of current on the voltage of current probe is calibrated using a simple circuit with
and the power supply
are measured for a
the power supply and a resistor. Both the current
range of resistors with resistances from 70 to 3 K using the digital multimeter.

Figure 2.4: Current probe calibration

The results show that a second order polynomial can better approximate the current from the
voltage of the current probe (instead of linear dependency on the voltage of the current probe).
Current in milliamps is calculated from voltage in volts as the following formula:
20.

99.1 .

0.1576

(2.3)

2.4 Using GoldCap capacitor for lifetime bounds

This method is for measuring the experimental lifetime of sensor networks. If we use batteries to
provide sensors with the required energy, lifetime can be weeks to months. For short term
experiments and comparisons, this is problematic, as for technical reasons the remaining capacity of a
battery cannot be measured with sufficient precision. A solution for this problem is using GoldCaps.
GoldCaps are a special kind of capacitors that come with very high capacity, e.g. 1 Farad. These
devices can be charged very quickly and power a sensor node for a reasonable amount of time. In
general, the time t that a sensor node can be powered with a GoldCap of capacity C follows:
/
where
is the max voltage of GoldCap,
is the threshold voltage (no operation below
possible), and the current consumption of the sensor node.

13

(2.4)

Figure 2.5: Sensor board with GoldCap attached on top

14

Chapter 3: Measurement Setup

In chapter 2, four methods were explored to measure the power consumption of sensor motes. One of
them (GoldCap capacitor method) which is used to measure lifetime bounds, is not appropriate for our
purpose since we need runtime monitoring of power consumption. Two of them use clamp-on current
probe. Unfortunately, this device was not available in our laboratory and we had to drop these two
methods. The only remaining method is using shunt resistor. As mentioned in chapter 2, this method
has one drawback: the resistance interferes with the operation of the system under test. To decrease
this interference, a very low resistor along with an instrumentation amplifier needs to be used.
In our experiments, a 1.7 test resistance was inserted in series between the power supply and the
mote. The two ends of the resistor were connected to the inputs of an instrumentation amplifier. An
AD620AN instrumentation amplifier [11] with the gain of 98 was used to amplify the voltage across
the resistor. Finally the output of the amplifier was input to an oscilloscope. The oscilloscope Tek
TDS2012B [13] was chosen to measure current with the highest possible resolution in order to reveal
all power transitions. This model of oscilloscope has a USB port in order to record data digitally.
Instrumentation Amplifier: an instrumentation amplifier is a closed-loop gain block that has a
differential input and an output that is single-ended with respect to a reference terminal. Commonmode rejection, the property of cancelling out any signals that are common (the same potential on
both inputs), while amplifying any signals that are differential (a potential difference between the
inputs), is the most important function an instrumentation amplifier provides. The differential gain
( ) is the gain between input and output for voltages applied differentially across the two inputs.
Normally, a single resistor is used to program the in-amp for the desired gain. The user can calculate
the required value of resistance for a given gain ( ), using the gain equation listed in the in-amps
spec sheet [10].
We used AD620AN which is a complete monolithic instrumentation amplifier introduced by
Analog Devices [11].

Figure 3.1: AD620 connection diagram

User-supplied power supplies connect

,
(based on [12], 15 ) and ground to pins of the
IC. The differential signal is applied to the +IN and IN pins of the in-amp, while the signal output
appears at the OUTPUT pin of the in-amp. The user can program any desired gain from 1 to 10000 by
pins. The gain equation in AD620AN is [12]:
placing a single external resistor ( ) between
15

49.4

(3.1)

To reveal all power transitions, the gain of 98 was enough for our measurements. Hence a 510
pins of the in-amp.
resistor was placed between
While working with instrumentation amplifiers, there can be voltage offset error which should be
),
calculated in order to have precision measurements. There are two offset errors; Input Offset (
and Output Offset (
). For AD620AN, the datasheet indicates that
is 30 (typical) and
is 400 (typical). So referred to input, the total voltage offset will be:
30

400

(3.2)

and referred to output, the total voltage offset will be:

30

400

(3.3)

Practically, to adjust the offset of the in-amp, we should ground both inputs and measure the output
voltage, the result should be accounted for all the measurements. Grounding both inputs, we detected
no voltage offset error in our measurements.

Figure 3.2: Instrumentation amplifier setup [14]

Other challenges with instrumentation amplifiers are Input Bias and Offset Currents. Input bias
currents are those currents, flowing into, or out of, the input terminals of the in-amp [10]. Input bias
currents can be considered as a source of voltage offset error (i.e. input current flowing through a
source resistance causes a voltage offset). Input offset current is the difference between the two input
bias currents and this leads to offset errors in in-amps when source resistances in the two input
terminals are unequal. The solution for these problems is to provide a return path for bias currents to
flow to ground. A high value resistor of 1 M to 10 M connected between each input and ground
will normally be all that is needed to correct this condition. We connected a 1 M resistor between
each input and the ground to solve this problem.

16

Figure 3.3: Our circuit board

Our measurement setup is depicted in Figure 3.4.

Figure 3.4: Our hardware measurement configuration

In the rest of this document, some screenshots of the scope while measuring different operations
are depicted. The x-coordinate is time. The y-coordinate of the shots is the voltage (with 98 gain)
across the 1.7 resistor placed between power supply (3 ) and the mote. The precise data is gained
digitally from oscilloscope. To calculate the consumed power, we do the following calculations:
(3.4)

98
1.7
3

17

(3.5)

Chapter 4: Experiments using Tmote Sky

sensor motes
Tmote Sky is an ultra low power wireless module for use in sensor networks, monitoring applications,
and rapid application prototyping. Tmote Sky leverages industry standards like USB and IEEE
802.15.4 to interoperate seamlessly with other devices. By using industry standards, integrating
humidity, temperature, and light sensors, and providing flexible interconnection with peripherals,
Tmote Sky enables a wide range of mesh network applications. It features 250 kbps 2.4 GHz IEEE
802.15.4 Chipcon Wireless Transceiver and 8 MHz Texas Instrument MSP430 microcontroller [15].
In this chapter, we will precisely measure energy consumed during different operations on Tmote
Sky Sensor motes. First the energy consumed at different power states of MSP430, the
microcontroller of Tmote Sky, will be computed. Then different frame structures of IEEE 802.15.4
along with CSMA/CA medium access mechanism are investigated to discover the overhead of
channel acquisition, transmission of header and footer of data frame and acknowledgment frame. We
will also implement a series of measurements on CC2420 radio used in a wide range of sensor motes
to find the specific overheads of transmission for this radio. And finally the power consumptions of
reading and writing operations on ST M25P80, the external flash of Tmote Sky, are computed.
We program our tests using TinyOS version 2.1.0 and nesC language. We repeat these
measurements over 30 times and the average of the results is considered.

4.1 TinyOS
TinyOS is a tiny microthreading operating system designed to meet these requirements for networked
sensors: small physical size and low power consumption, concurrency-intensive operation, limited
physical parallelism and controller hierarchy, diversity in design and usage, and robust operation [16].
TinyOS is a component-oriented, event-driven operating system for sensor networks which consists of
a simple FIFO task scheduler and some software components for doing different operations in sensor
motes.
A three-tier Hardware Abstraction Architecture (HAA) for TinyOS 2.0 is proposed that
combines the strengths of component model with an effective organization in form of three different
levels of abstraction. The top level of abstraction raises portability by providing a platformindependent hardware interface (HIL: Hardware Interface Layer), the middle layer promotes
efficiency through rich hardware-specific interfaces (HAL: Hardware Adaptation Layer), and the
lowest layer structures access to hardware registers and interrupts (HPL: Hardware Presentation
Layer) [17].
The first challenge while working with Tmote Sky sensor motes is that it is never defined in
TinyOS; in the directory tinyos-2.1.0/tos/platforms, Tmote Sky platform is not included.
In TinyOS 2.0, a platform is a collection of chips and some glue code that connects them

18

together [18]. Due to the lack of such implementation, every compilation (make) of code targeting the
Tmote Sky is retargeted to Telosb.
tinyos-2.1.0/support/make/tmote.target:
ifeq ($(TMOTE_REV) ,SKY)
TMOTE_TARGET = telosb.target
Endif

But comparing the two sensor motes, Moteiv Tmote Sky and Crossbow TelosB, we see that they
have rather the same features. The differences are: Tmote Sky has better RF performance, lower
power consumption, and faster startup times. Since none of these differences will lead into a different
binary code translation for Tmote Sky platform, there is no problem compiling the Tmote Sky code by
TelosB platform. Even if a different hardware component is used in Tmote Sky than TelosB, TinyOS
2.0 has provided a solution to it: horizontal decomposition [17]. A horizontal decomposition can
promote reuse of the hardware resource abstractions that are common on different platforms. To this
aim, TinyOS 2.0 introduces the concept of chips, the self-contained abstraction of a given hardware
chip: microcontroller, radio-chip, flash-chip, etc. Each chip decomposition follows the HAA model,
providing HIL implementations as the topmost components. Platforms are then built as
compositions of different chip components with the help of glue components that perform the
mapping.

4.2 Power States of MSP430 microcontroller

Microcontrollers often have several power states, with varying power draws, wakeup latencies, and
peripheral support. The microcontroller should always be in the lowest possible power state that can
satisfy application requirements. Determining this state accurately requires knowing a great deal about
the power state of many subsystems and their peripherals. Additionally, state transitions are common.
Every time a microcontroller handles an interrupt, it moves from a low power state to an active state,
and whenever the TinyOS scheduler finds the task queue empty, it returns the microcontroller to a low
power state.
Tmote Sky sensor motes feature Texas Instrument MSP430 microcontroller. This is an ultra low
power microcontroller featuring 10 kB of RAM, 48 kB of flash, and 128 B of information storage.
This 16-bit RISC processor features extremely low active and sleep current consumption that permits
Tmote to run for years on a single pair of AA batteries [15].
Processors can have a spectrum of power states. The MSP430 has one active mode (issuing
instructions) and five low power modes. The low power modes range from LPM0, which disables
only the CPU and main systems clock, to LPM4, which disables the CPU, all clocks, and the
oscillator, expecting to be woken by an external interrupt source.
MSP430 based platforms compute the low power state every time the scheduler tells the system to
go to sleep. This approach is simple, in that the system will always enter the right power state without
any external prompting, contrary to the Mica platforms which have a command for enabling and

19

disabling low power modes. However the approach used in MSP430 based platforms is costly,
introducing 40-60 cycles of overhead to every interrupt that wakes the system up, which can be a
bottleneck on the rate at which the system can handle interrupts.
This approach assumes that TinyOS can determine the correct low power state by examining
control and status registers. MSP430 defaults to low power mode 3 (LPM3) unless it detects that
Timer A, the USARTs, or the ADC is active, in which case it uses low power mode 1 (LPM1).
TinyOS 2.x uses three basic mechanisms to manage and control microcontroller power states: a
dirty bit, a chip-specific low power state calculation function, and a power state override function.
The dirty bit tells TinyOS when it needs to calculate a new low power state, the function performs the
calculation, and the override allows higher level components to introduce additional requirements, if
needed.
TinyOS exports one interface for the handling of the microcontroller, namely McuSleep, which
exposes a single asynchronous command, sleep(), that is called inside the TinyOS scheduler when
the FIFO task queue is empty. The job of the sleep() command is to calculate the correct power
state in which to put the microcontroller. The task requires analysis of the state of different registers
[19].
<tos/chips/msp430/McuSleepC.nc>
[]
const uint16_t msp430PowerBits[MSP430_POWER_LPM4 +
0,
//
SR_CPUOFF,
//
SR_SCG0+SR_CPUOFF,
//
SR_SCG1+SR_CPUOFF,
//
SR_SCG1+SR_SCG0+SR_CPUOFF,
//
SR_SCG1+SR_SCG0+SR_OSCOFF+SR_CPUOFF,
//
};
[]

1] = {
ACTIVE
LPM0
LPM1
LPM2
LPM3
LPM4

Depending on the power mode in which TinyOS puts the microcontroller, different clocks and
other resources of the microcontroller are adjusted. The MSP430 clock system is designed specifically
for battery-powered applications [20]. Multiple oscillators are utilized to support event-driven burst
activity. A low-frequency Auxiliary Clock (ACLK) is driven directly from a common 32-kHz watch
crystal or the internal very low-power oscillator (VLO) with no additional external components. The
ACLK can be used for a background real-time clock self wake-up function. An integrated high-speed
digitally controlled oscillator (DCO) can source the master clock (MCLK) used by the CPU and submain clock (SMCLK) used by the high-speed peripherals.
There are five low-power modes of operation, but two (LPM1 and LPM2) are rarely employed in
current devices [21]:
Active mode: CPU, all clocks, and enabled modules are active. The MSP430 starts up in this mode,
which must be used when the CPU is required. An interrupt automatically switches the device to
active mode.

20

LPM0: CPU and MCLK are disabled, SMCLK and ACLK remain active. This is used when the CPU
is not required but some modules require a fast clock from SMCLK and the DCO.
LPM3: CPU, MCLK, SMCLK, and DCO are disabled; only ACLK remains active. This is the
standard low-power mode when the device must wake itself at regular intervals and therefore needs a
(slow) clock. It is also required if the MSP430 must maintain a real-time clock.
LPM4: CPU and all clocks are disabled. The device can be wakened only by an external signal. This
is also called RAM retention mode.
MSP430 is put into low-power modes through the four bits: SCG0, SCG1, CPUOFF, and
OSCOFF in the status register. All these are clear in the active mode and particular combinations are
set for each low-power mode. For example setting only CPUOFF disables the CPU and MCLK,
putting the MSP430 into LPM0.
Since some external peripherals may require the microcontroller to not go below a given power
state (for example if it will require the CPU soon and the tradeoff between the time spent in a lowpower state and wake-up latency is not favorable), TinyOS allows them to specify the lowest
acceptable power state through the McuPowerOverride.lowestState() command [19].
As mentioned before, there are three mechanisms to control microcontroller in TinyOS. We used
power state override function method to force the microcontroller to stay in different power states in
our measurements. The trick we used was to let the microcontroller do no operation so that it would
go to the lowest state LPM4. Then using the command McuPowerOverride.lowestState(),
we could set the lowest state the microcontroller was allowed to go (source codes of the tasks done in
this document are available on the CD attached to it).
Here are the results we obtained:
272
, so
1.633
and
4.898
.
Active mode:

Figure 4.1: Active mode

Almost the same results were obtained for both LPM0 and LPM1.
28
, so
0.168
and
0.504
LPM0 and LPM1:

21

Figure 4.2: LPM0 and LPM1

LPM2, LPM3, and LPM4 consume approximately the same amount of power based on our
experiments:
8
, so
0.048
and
0.144
.
LPM2, LPM3, LPM4:

Figure 4.3: LPM2, LPM3, LPM4

4.3 CC2420 Radio

Tmote Sky features the Chipcon CC2420 radio for wireless communications. The CC2420 is an IEEE
802.15.4 compliant radio providing the PHY and some MAC functions. With sensitivity exceeding
the IEEE 802.15.4 specification and low power operation, the CC2420 provides reliable wireless
communication. The CC2420 is highly configurable for many applications with the default radio
settings providing IEEE 802.15.4 compliance. The CC2420 is controlled by the TI MSP430

22

microcontroller through the SPI port and a series of digital I/O lines and interrupts. The radio may be
shut off by the microcontroller for low power duty cycled operation [15].

4.3.1 IEEE 802.15.4

The IEEE 802.15.4 standard defines the protocol and interconnection of devices via radio
communication in a personal area network (PAN) called LR-WPAN (Low-Rate Wireless Personal
Area Network). The standard uses carrier sense multiple access with a collision avoidance
(CSMA/CA) medium access mechanism and supports star as well as peer-to-peer topologies.
The LR-WPAN defines four frame structures:
1) A beacon frame, used by a coordinator to transmit beacons
2) A data frame, used for all transfers of data
3) An acknowledgment frame, used for confirming successful frame reception
4) A MAC command frame, used for handling all MAC peer entity control transfers
Beacon frames and MAC command frames are used for management and control purposes. For
simplicity we dont consider these two frames and focus our efforts on the other two frames.
Figure 4.4 [23] shows the structure of the data frame, which originates from the upper layers.
2

Bytes:
MAC
Layer

Frame
Data Sequence
Control Field
Number

20

Addressing
Fields

MAC Header
Bytes: 4

1
PHY
Start of Frame
Preamble Sequence
Layer
Delimiter
Synchronization Header

1
Frame
Length
PHY
Header

102

Data Payload

Frame Check
Sequence

MAC Payload

MAC Footer

20

MAC Protocol Data Unit

PHY Service Data Unit
11
0 20
PHY Protocol Data Unit (PPDU)

Figure 4.4: Schematic view of the data frame [23]

The length of the physical data packet (PPDU) is 11

0 20
bytes. The addressing fields
shall comprise the destination address fields and/or the source address fields, dependent on the
settings in the frame control field.
0/2 bytes
Destination
PAN
identifier

0/2/8 bytes

0/2 bytes

0/2/8 bytes

Destination
address

Source PAN
identifier

Source
address

Figure 4.5: Addressing fields

Practically 16-bit (2-byte) addresses i.e. short addresses are assigned to the sensor motes, source
PAN identifier is left empty, and 2-byte destination PAN identifier is assigned (see figure 4.5). In
802.15.4, a PAN identifier is chosen for every network which operates independently from the other
23

networks. Altogether 6 bytes is needed for addressing purposes, hence the length of the data packet
gets 17 n bytes.
Figure 4.6 [23] shows the structure of the acknowledgment frame.
4 bytes
1 byte
Preamble Start of Frame
Sequence
Delimiter
Synchronization Header

1 byte
Frame Length
PHY Header

2 bytes
1 byte
Frame Control Data Sequence
Field
Number
MAC Header

2 bytes
Frame Check
Sequence
MAC Footer

Figure 4.6: Schematic view of the acknowledgment frame [23]

The length of the acknowledgment packet is 11 bytes. Although use of acknowledgment frames is
optional, we will consider them in our computations for transfer reliability.
Altogether to transmit an n-byte packet, we need to send 17 n bytes (data frame) and receive 11
bytes (acknowledgment frame). To receive an n-byte packet, we need to receive 17 n bytes (data
frame) and send 11 bytes (acknowledgment frame).

4.3.2 RSSI/Energy Detection

CC2420 has a built-in RSSI (Received Signal Strength Indicator) giving a digital value that can be
read from an 8-bit register (RSSI.RSSI_VAL). The RSSI value is always averaged over 8 symbol
periods i.e. 128 s (each symbol is 4 bits). The RSSI_VALID status bit indicates when the RSSI
value is valid, meaning that the receiver has been enabled for at least 8 symbol periods. The RSSI
register value RSSI.RSSI_VAL is calculated and continuously updated for each symbol after RSSI
has become valid [22].

4.3.3 Clear Channel Assessment

The clear channel assessment (CCA) signal is based on the measured RSSI value and a programmable
threshold. The clear channel assessment function is used to implement the CSMA/CA functionality.
CCA is valid when the receiver has been enabled for at least 8 symbol periods.
There are 3 CCA modes [22]:
1) Clear channel when received energy is below threshold.
2) Clear channel when not receiving valid IEEE 802.15.4 data.
3) Clear channel when energy is below threshold and not receiving valid IEEE 802.15.4 data.
Implementing CSMA/CA may easiest be done by using the STXONCCA command strobe.
Transmission will then only start if the channel is clear.

4.3.4 The CSMA/CA algorithm

When more than one station attempts to transmit a frame at the same time, a collision occurs, and
subsequently all frames get corrupted. The standard mechanism for contention resolution in computer

24

networks is called carrier-sense multiple access (CSMA). CSMA algorithms attempt to break
symmetries of failing transmissions being restarted at almost the same time by using randomized
binary exponential backoff procedures. While wired devices can listen during their own transmissions
and employ CSMA with collision detection (CSMA/CD), stations in wireless networks usually cannot
listen to their own transmissions, and consequently colliding transmissions can only be detected after
they have been completed. Thus wireless devices use CSMA with collision avoidance (CSMA/CA).
If beacons (beacons are transmitted by the coordinator to provide synchronization services) are
being used in the PAN, the MAC sub-layer shall employ the slotted version of the CSMA/CA
algorithm for the transmission. Conversely, if beacons are not being used in the PAN or if a beacon
could not be located in a beacon-enabled PAN, the MAC sub-layer shall transmit using the unslotted
version of the CSMA/CA algorithm. Here we only focus on unslotted CSMA/CA algorithm. It works
as follows [23]:
1. Initialization: if a device wishes to transmit a frame using CSMA/CA, it first initializes the local
variables BE:=macMinBE (0-3, default 3) for the backoff exponent and NB:=0 for the number
of successive backoffs before the current transmission.
2. Backoff: before a station attempts to send a frame, it waits for a random integer number between 0
and 2BE 1 complete backoff periods of length aUnitBackoffPeriod (20 symbol periods).
In unslotted CSMA/CA the backoff starts immediately.
3. Clear Channel Assessment: after completing its backoff, the station performs a clear channel
assessment (CCA). If, after eight symbol periods, the channel is assessed to be busy, both BE and
NB are incremented by one, up to a maximum of aMaxBE (=5) for BE and
macMaxCSMABackoffs+1 (macMaxCSMABackoffs=0-5, default 4) for NB. If NB exceeds
macMaxCSMABackoffs, the protocol terminates with a channel access failure; if not, the
protocol returns to the backoff step. If the channel is assessed to be free, the data frame can be
transmitted.
4. Starting the transmission
5. Acknowledgement: if the originator has not requested an acknowledgement, the transmission is
assumed to have been successful. If an acknowledgement has been requested, the sender needs
aTurnaroundTime (12 symbol periods) to switch from sending to receiving mode and vice
versa. The recipient starts the transmission of the acknowledgement aTurnaroundTime after
the reception of the last symbol of the data. If the originator receives an acknowledgement from the
recipient within a time of macAckWaitDuration (120 or 54 symbol periods), the data transfer
has been successful. If no acknowledge is received within that time, the frame will be retransmitted
up to a maximum of aMaxFrameRetries (=3) times, after which the protocol terminates and a
communications failure is issued.

4.3.5 CCA and Sending

The CC2420 has programmable output power. Common CC2420 register values and their
corresponding power consumption and output power based on the information in [15] are shown in
figure 4.7.
25

PA_LEVEL
31
27
23
19
15
11
7
3

TXCTRL register
0xA0FF
0xA0FB
0xA0F7
0xA0F3
0xA0EF
0xA0EB
0xA0E7
0xA0E3

Output Power [dBm]

0
-1
-3
-5
-7
-10
-15
-25

Current Consumption [mA]

17.4
16.5
15.2
13.9
12.5
11.2
9.9
8.5

Figure 4.7: Output power configuration for the CC2420

In TinyOS 2.x, we can set the global radio power of CC2420 by defining the
CC2420_DEF_RFPOWER to a different value or we can change it dynamically on a per-packet basis
using the setPower command from the CC2420Packet interface. There are 32 (0 to 31) valid
transmission power states for a given packet.
After compiling the applications for radio power measurements, we need to program Tmote Sky
with the following command:
make tmote reinstall.x

where x is the 16-bit address assigned to the mote.

There is one byte difference between the packet size of TinyOS and the standard 802.15.4. TinyOS
adds the field TinyOS_IP which is not defined in 802.15.4. Thus the length of the data frame is
18 n bytes in TinyOS. It is also worth mentioning that in TinyOS, data payload length is set by
TOSH_DATA_LENGTH (by default 28 bytes) in Makefile, regardless of our definitions inside
the code.
In 802.15.4, the synchronization header (SHR) consists of the preamble sequence (4 bytes of 0x00)
followed by the start of the frame delimiter (SFD) (1 byte set to 0xA7). In CC2420, the preamble
length and SFD is configurable. The default values are compliant with IEEE 802.15.4. Changing these
values will make the system non-compliant to this standard.
To measure the power needed for sending operation, a 46-byte packet (28 bytes data payload and
18 bytes header and footer) with the maximum output power on CC2420 (0 dBm) was sent. The scope
trace is seen in figure 4.8. In TinyOS, calling setRxSleepInterval() with a specific sleep
interval allows the correct number of preambles to be sent for the message specified in its parameter
list. Since the duration of the time sending these preamble bits is variable, we consider the ideal case
when there is no such extra preamble bits.

26

Figure 4.8: Sending operation

Voltage for CCA operation is 3.2 V and time is 1.4 ms, hence P 0.08 mJ.
As noted before, we ignore extra preamble bits and only consider the 4-byte preamble sequence at
IEEE 802.15.4 standard data frame. These 4 bytes are among the extra ones in the area marked
Preamble bits in figure 4.8. It takes 96 ms with the voltage 2.92 V to send 42 bytes (46 4). Thus,
power consumption to send 1 byte, 11 bytes and 18 bytes are 0.12 mJ, 1.32 mJ and 2.16 mJ,
respectively.
We repeated this experiment with output power set to different values and surprisingly no change
was made in the power consumption of sending operation. The only change was in the power
consumption used in sending the preamble bits; the less output power was set, the more deviation
from the main course of power consumption was seen. For example setting the output power to 3 (-25
dBm) led to the following trace:

Figure 4.9: Sending operation with -25 dBm output power

27

We did this experiment setting different output power through both the methods mentioned before, i.e.
setting globally and dynamically. Still the power consumption was the same for all the output power
settings. Our conjecture is that TinyOS does not control the output power of CC2420 correctly.

4.3.6 Low power listening

While a CC2420 radio is turned on and listening, it can actively consume anywhere between 7.4 to
18.8 mA on top of the power consumed by other components in the system. This can rapidly deplete
the batteries. In the interest of extending battery lifetime, it is best to duty cycle the radio on and off to
prevent this idle waste of energy. In an asynchronous low power message delivery scheme, the duty
cycling receiver node saves the most energy by performing short, periodic receive checks. The power
consumption burden is then placed on the transmitter node, which must modulate the radio channel
long enough for the recipients receive check to detect an incoming message. A synchronous low
power message delivery scheme takes this idea a step further by allowing the transmitter to only
transmit when it knows the destination node is performing a receive check [24].
Unlike sending, there is only one fixed power state for listening, and Low Power Listening setting
adjusts the time intervals, not the power state for listening. Regarding the measurement for energy
model, there is no need to estimate energy consumption for different time intervals; this is the job of
the simulator. We only need to know how much energy is consumed while listening. The scope trace
of running the command LowPowerListening.setLocalSleepInterval(1000) is
depicted in figure 4.10.

Figure 4.10: Low power listening

4.3.7 Listening and Receiving

To measure receiving power consumption, a 46-byte packet is received. The scope trace is depicted in
figure 4.11.
28

Figure 4.11: Receiving operation

There is listening for the duration of 10 ms before the data is received. This is one of those short
periodic receive checks shown in figure 4.10. As it is seen, less power is used in receiving mode than
listening mode. Voltage for listening operation is 3.2 V, hence P 0.58 mJ.
The time for receiving operation is roughly the same as sending operation for transmission of a
packet, but the voltage decreases to 2.88 V. Therefore, the power consumption to receive 1 byte, 11
bytes and 18 bytes are 0.12 mJ, 1.3 mJ and 2.13 mJ, respectively.

4.4 External Flash

Flash is a permanent (non-volatile) memory. Tmote Sky uses the ST M25P80 40MHz Serial code
flash for external data and code storage. The flash holds 1024 kB of data and is decomposed into 16
segments, each 64 kB in size. The flash shares SPI communication lines with the CC2420 transceiver.
Care must be taken when reading or writing to flash such that it is interleaved with radio
communication, typically implemented as a software arbitration protocol for the SPI bus on the
microcontroller [15].
TinyOS 2.x provides three basic storage abstractions: small objects, circular logs, and large objects
[25]. TinyOS 2.x divides the flash chip into one or more fixed-size volumes using an XML file. This
file allows the user to specify the name, size, and optionally the base address of each volume in the
flash. Each volume provides a single type of storage abstraction (e.g. configuration, log, or block
storage). The abstraction type defines the physical layout of data on flash memory. We used
LogStorage abstraction to write and read data.

29

4.4.1 Writing to external flash

We wrote 1 byte to flash. Scope trace is shown in figure 4.12.
On average 432 mV for the duration of 4.49 ms was consumed to write one byte to the external
flash. Hence P 0.0349 mJ.

Figure 4.12: Writing 1 byte to flash

4.4.2 Reading from external flash

Reading one byte from flash has the following trace:

Figure 4.13: Reading 1 byte from flash

On average 174 mV for the duration of 2.61 ms was consumed to read one byte from the flash.
Hence P 0.0082 mJ.
30

Chapter 5: Evaluation of lifetime bounds

of WSNs
In this chapter we estimate lifetime bounds of a network of motes which communicate with each other
using IEEE 802.15.4 standard. The overhead of channel acquisition, transmission of header and footer
of data frame and acknowledgment frame, computed in chapter 4, are used here. This overhead makes
the fixed component, and the data payload makes the incremental component of a linear equation to
estimate the power consumed during every packet transmission. Finally we input this per-packet
power consumption in a mathematical model which estimates the lower and upper bounds of routings
in the network.
Sensor motes in WSNs have limited power supply, usually without the possibility to be recharged.
Most of their power supply is consumed for their transmission purposes and a small fraction is used
up during internal processing or sensing operation. For example, according to our measurements in
chapter 4:
CC2420: power needed to send 1 bit = 15 J
MSP430: Mater Clock is up to 25 MHz, which means it can run 25 MIPS (million instructions per
second). In Active Mode, P = 4898 W. So power needed to run 1 instruction =

0.2 nJ

Comparing these two results, we see that one bit transmitted by radio consumes about as much power
as executing 75,000 instructions. Thus, power consumption of routings is large enough to overshadow
the power consumed by the other operations. We focus on the power consumption of routings to
decide the lifetime of a WSN.

5.1 A Mathematical Model of Energy Consumption of Routings

In order to measure the lower and upper bounds of the energy consumption of routings, we use a
mathematical model suggested by Alonso et al. [26]. This model considers continuous sensor
networks [27] in which the sensors communicate their data continuously at a pre-specified rate. In
such a network, sensor nodes read sensor values, send them in a multi-hop fashion to a base station
and sleep until the next iteration. The leaf sensors send only their own values, while the inner nodes
send their own values along with the packets originating from the outer nodes. Received packets are
retransmitted unchanged to the base station i.e. nodes do not aggregate the data payload of a received
packet with that of another received packet or with their own data payload. The nodes iterate this
process till the end of the lifetime of the network. By the term lifetime of the network, we mean the
duration of the time from the initialization of the network till at least one of the nodes dies.
In this model, the set of all nodes (V) is partitioned into different subsets (called spheres),
S
S and S S
for all i j and no S is empty. S is the
S , S , , S such that V S
B ), but not less than
set of nodes that can be reached from the base station (B) in i hops (thus S

31

hops. Figure 5.1 shows an example of such network. This model assumes that all nodes transmit at the
same constant power.

Figure 5.1: A sensor network partitioned in spheres.

The term balls of radius i denoted B is introduced in this model such that B
S
S . Some
|S |, b
|B |, N |V|. Using these definitions, a lower bound on the
other definitions are: s
energy consumption for a node in is:
(5.1)

where r is the energy consumed for receiving one packet and t is the energy consumed for
transmitting one packet. In the equation above, N b is the total number of nodes outside B and thus
the total number of packets that the set of nodes in sphere S receive in each iteration. The nodes in S
must transmit all the packets they receive plus their own packets. The minimum energy consumption
is when the total number of packets received and transmitted is equally divided among the nodes in S .
If we find minimum energy consumption for nodes in different spheres, the lower bound on the
energy consumption of a node in the whole network will be:
(5.2)

,,

The total number of packets received at each iteration at a node cannot exceed N s
1.
Likewise, the total number of packets transmitted cannot exceed N s . Thus, the upper bound on the
energy consumption of a node in the whole network will be:
.

(5.3)

Suppose each node has the exact same amount of energy EE. So the maximum number of
iterations, T , a sensor network can perform within its lifetime is as follows:

32

(5.4)
.

,,

5.2 Modeling Per-packet Energy Consumption

The energy consumed by a sensor node while sending, receiving (and even discarding) a packet can
be described using a linear equation proposed in [28]:
(5.5)
The idea of this per-packet modeling is that there is a fixed component associated with device state
changes and channel acquisition overhead (b), and an incremental component which is proportional to
the size of the packet (m size . Experimental results confirm the accuracy of this equation. For
various applications we can find the specific coefficients m and b.
This model does not consider energy consumed in unsuccessful attempts to acquire the channel, or
in messages lost due to collision, bit error or loss of wireless connectivity.
In this work, we only focus on unicast traffic. While working in unicast mode, a sensor mote
overhears all traffic sent by nearby motes. Thus it is important to consider the energy consumption
when a node determines that it is not the intended destination of received unicast traffic and discards
the received packet. Since such computation is application specific (depends on the distance between
sensor motes and their radio sphere of influence, etc.), we ignore this case, but the load of this energy
can easily be added to the computation to provide more precise results.
Having unicast transmission in mind, per-packet energy consumption to send and receive, based on
the linear equation, will be as follows (E operation x means the energy needed to do the operation
x):
(5.6)
(5.7)
As mentioned in chapter 4, in our computations we ignore beacons in the PAN and only take the
unslotted version of the CSMA/CA algorithm into consideration. Briefly, the unslotted CSMA/CA
algorithm has the following steps:
1. Initialization of local variables related to backoff
2. Random backoff period
3. Clear Channel Assessment (CCA)
4. Transmission
5. Acknowledgment
The first two steps are internal operations and as noted before consume negligible amount of energy
compared to communication operations. Thus, we do not include these two steps in the measurements.
Also, an ideal network with complete symmetry is assumed without the need for extra prepended
33

preambles or consecutive packet repetition in the senders side or long listening period in the
receivers side.
In order to measure the lower and upper bounds of the energy consumption of routings based on
the framework of IEEE 802.15.4 for a network in which every node transmits a packet with size n at
each iteration, we proceed as follows:
(5.8)

1
17

(5.9)

11

(5.10)

1
17

(5.11)

11

(An important note is that there is no listening before receiving the acknowledgment frame by the
transmitter of the data frame, and no CCA before sending the acknowledgment frame by the receiver
of the data frame.)
(5.12)
(5.13)
(5.14)

,,

(5.15)

(Definition of variables in equations 5.14 and 5.15 can be found in section 5.1.)

5.3 Measurement of Bounds Using Tmote Sky Sensor Motes

In this section, we will measure the lower and upper bounds of energy consumption for a network
composed of Tmote Sky Sensor motes. To do so, we need to input the precise power measurements of
different operations done by CC2420 in sections 4.3.5 and 4.3.7 into the equations in section 5.2. We
need to pay attention to the one byte difference between the packet size in TinyOS and the standard
802.15.4. Rewriting the equations 5.12 and 5.13 results in the following equations:
0.12
0.12
34

3.54
4.03

(5.16)
(5.17)

Tmote Sky sensor motes use 2 AA batteries with the total amount of 30780 Joules.
Example: Consider a network consisted of 29 nodes as depicted in figure 5.1. The nodes are
Tmote Sky sensor motes (with CC2420 radios), and in the intervals of 10 seconds send packets with
2-byte data payload. In each iteration, every node transfers its own data plus the data coming from the
outer spheres (but leaves that only transfer their own data) to the inner spheres, and finally all the
packets are collected at the base station. To calculate the lifetime bounds, we work as follows:
E send
0.12 2 3.54 3.78 mJ
E receive
0.12 2 4.03 4.27 mJ
s
4, b
5, m
52.08
mJ
6, b
11, m
27.93
mJ
s
s
10, b
21, m
10.22
mJ
s
8, b
29, m
3.78
mJ
max m , , m
52.08
mJ
30780
30780
T
139194
52.08 10
221.13 10

591014

Considering the 10-second intervals, the lower lifetime bound will be about 387 hours and the upper
lifetime bound 1642 hours.
In this example, the bottle neck is S , the sphere which in fact determines the upper bound. By
better positioning the nodes, it is possible to spread the load of packet transmissions approximately
equally on all the nodes and improve the upper bound.
In case the base station does not need hard real-time evaluation of the data sent by the nodes, it is
possible for the nodes to aggregate their data and send it in longer intervals. This way we can improve
the bounds significantly. Imagine in the previous example the nodes instead of sending packets
consisting 2-byte data payload every 10 s, aggregate data and send packets with 6-byte data payload
every 30 s. The lower bound will be 1036 hours and the upper bound 4398 hours. Comparing with the
previous result, the bounds are now about 3 times more. The reason is obvious; the fixed component
of the linear equation, which determines the power consumed to acquire the channel, and to send and
receive acknowledgment frame and header and footer of the packet, is much higher than the
incremental component for CC2420.

5.4 Proposing a new simulator for WSNs

The new method presented in chapter 5 for evaluating the lifetime bounds of WSNs, can be a good
basis to develop a new simulator for assessing the behavior of the motes and the whole network. As
noted before, internal operations of sensor motes consume such less amount of energy that we can
ignore them and only take radio operations into account. This reduces the level of accuracy but
increases the speed of simulation. The weak point of most of the simulation structures discussed in
chapter 1 is that even their fastest ones take several hours to process a normal task.

35

In this potential simulator, there is no need to do direct execution or binary translation. In fact, we
don't need to handle the code of the tasks and go through all the commands of a large number of
sensor motes and run them. Instead, the pre-specified radio operations of the motes along with some
extra information like the positioning of the motes and their radio sphere of influence are input into
the simulator. The simulator then provides the information like the order of the nodes dying, or
suggests the best possible positioning of the nodes. We can check the results of different possible
implementations of the same task in this simulator and choose the most efficient one regarding power
consumption. This method can work well with synchronous applications. Since most of the
applications in WSNs are synchronous, this can be of great benefit to the developers. However, it can
be extended to address the asynchronous applications too.
This potential method is rather close to the method explained in section 1.2.1, overall power usage
approximation. But our proposed method goes a step further and instead of challenging with the
duration of the time the radio is operating, it works with the size of the packets transmitted between
the nodes and the intervals between transmissions.

36

Chapter 6: Conclusion
In this work, we investigated different experimental methods to measure the power consumption of
sensor motes. At the end, we decided the best measurement setup for this purpose is to insert a small
resistance between the power supply and the mote to decrease the effect of measurement interference.
Using an instrumentation amplifier, we magnified the traces and could precisely track the changes in
the amount of energy supplied to the mote during different operations.
Using this measurement setup, we went through a series of experiments to obtain the power
consumption of different components of Tmote Sky sensor mote while doing specific operations. We
estimated the power consumed at different power states of the microcontroller MSP430. Also the
power consumed to write/read 1 byte of data into/from external flash memory of Tmote Sky was
measured. Then, after exploring IEEE 802.15.4 standard, we did some measurements on CC2420
radio, which is compliant with this standard. Power consumption to send and receive 1 byte of data
payload, header and footer of the data frame, acknowledgment frame, and clear channel assessment
and listening operations was computed. Summary of our measurements is shown in figure 6.1.
Mode

Power

Radio
CCA
Sending 1 byte
Sending acknowledgment frame
Sending header and footer of data frame
Listening (periodic receive check)
Receiving 1 byte
Receiving acknowledgment frame
Receiving header and footer of data frame

0.08 mJ
0.12 mJ
1.32 mJ
2.16 mJ
0.58 mJ
0.12 mJ
1.3 mJ
2.13 mJ

Mode
CPU
Active mode
LPM0 and LPM1
LPM2 and LPM3 and LPM4
External Flash
Reading 1 byte
Writing 1 byte

Power
4.898 mW
0.504 mW
0.144 mW
0.0082 mJ
0.0349 mJ

Figure 6.1: Summary of measurements for Tmote Sky

Later, we presented how to compute the lower and upper lifetime bounds of WSNs using the
results from our radio operation measurements. Also categorizing different simulators, we proposed a
new simulator based on the method devised to compute the bounds. For future work, we plan to
implement this simulator.
Computing the lifetime bounds, although we concentrated on IEEE 802.15.4 frames, this method
can be extended to any type of frame used in the other standards for wireless data transmission. We
did not discuss the effect of different Network topologies supported in 802.15.4 (star or peer-to-peer)
in our measurements. Also we did not take into consideration the presence of coordinators and
beacons and superframe structures. Adding them will lower the lifetime bounds. However to provide
more precise bounds, it is desirable to work on these concepts in future work.

37

References
1. D. Raskovic, Energy-efficient Hierarchical Processing in the Network of Wireless Intelligent
Sensors (WISE), Ph.D. Thesis, ECE Dept., University of Alabama in Huntsville, 2004.
2. A. Milenkovic, M. Milenkovic, E. Jovanov, D. Hite, D. Raskovic, An Environment for Runtime
Power Monitoring of Wireless Sensor Network Platforms, 2005.
3. H. Ritter, J. Schiller, T. Voigt, A. Dunkels, J. Alonso, Experimental Evaluation of Lifetime
Bounds for Wireless Sensor Networks.
4. M. Rosenblum, S. Herrod, E. Witchel, and A. Gupta, Complete Computer System Simulation:
The SimOS Approach, IEEE Parallel and Distributed Technology, 3(4), Winter 1995.
5. The network simulator:
http://www.isi.edu/nsnam/ns/
6. E.A. Brewer, C.N. Dellarocas, A. Colbrook, and W. E. Weihl, PROTEUS: A High-Performance
Parallel-Architecture Simulator, MIT Technical Report MIT/LCS/TR-516, Sept. 1991.
7. P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: Accurate and scalable simulation of entire
TinyOS applications, In Proceedings of the first ACM Conference on Embedded Networked
Sensor Systems (SenSys) 2003, Nov. 2003.
8. M. Karir. atemu Sensor Network Emulator / Simulator / Debugger.
http://www.isr.umd.edu/CSHCN/research/atemu/
9. V. Shnayder, M. Hempstead, B. Chen, G. W. Allen, and M. Welsh, Simulating the Power
Consumption of Large-Scale Sensor Network Applications.
10. Book: A designers guide to instrumentation amplifiers, by C. Kitchin and L. Counts.
11. Analog Devices AD620 Instrumentation Amplifier:
http://www.analog.com
12. AD620: Low Cost Low Power Instrumentation Amplifier:
http://www.analog.com/static/imported-files/data_sheets/AD620.pdf
13. Tektronix TDS2012B Oscilloscope:
http://www.tek.com
14. Analog devices: Evaluation Boards for the AD620 Series and the AD8220 Series Instrumentation
Amplifiers.
15. Tmote Sky Datasheet:
http://sentilla.com/files/pdf/eol/tmote-sky-datasheet.pdf
16. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, K. Pister, System Architecture Directions for
Networked Sensors.
17. TEP 2 Hardware Abstraction Architecture:
http://www.tinyos.net/tinyos-2.x/doc/txt/tep2.txt
18. TinyOS 2.0 Overview:
http://www.tinyos.net/tinyos-2.x/doc/txt/overview.txt
19. TEP 112 Microcontroller Power Management:
http://www.tinyos.net/tinyos-2.x/doc/txt/tep112.txt
20. MSP430 16-bit Ultra-Low Power MCUs:

38

http://www.ti.com/msp430
21. Book: MSP430 Microcontroller Basics, by J. Davies - Page: 198.
22. CC2420 datasheet:
http://focus.ti.com/lit/ds/symlink/cc2420.pdf
23. IEEE Std. 802.15.4 2003: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
specifications for Low Rate Wireless Personal Area Networks (LR-WPANs):
http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf
24. TEP 105 Low Power Listening:
http://www.tinyos.net/tinyos-2.x/doc/txt/tep105.txt
25. Storage TinyOS Documentation Wiki:
http://docs.tinyos.net/index.php/Storage
26. J. Alonso, A. Dunkels, T. Voigt, Bounds on the Energy Consumption of Routings in Wireless
Sensor Networks, In Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks,
Cambridge, UK, March 2004.
27. S. Tilak, N. Abu-Ghazaleh, W. Heinzelman, A Taxonomy of Wireless Micro-sensor Networks,
ACM Mobile Computing and Communications Review, 6(2), 2002.
28. L.M. Feeney, M. Nilsson, Investigating the Energy Consumption of a Wireless Network
Interface in an Ad Hoc Networking Environment.

39