Practical 1: The Sensor Node Hardware Architecture

Processing unit to transceiver, both ways. The microcontroller hands the radio a packet to send and takes from it the packets it received. The transceiver here is the CC2420, a single chip that implements the radio layer of IEEE 802.15.4, the standard low-rate wireless network used by sensor networks: 2.4 GHz, 250 kilobits a second.

LEDs and a serial port let the node show its state and talk to a PC over a cable. A node plugged into a PC this way is how a base station is made (Practical 2 and Practical 8).

The power unit feeds everything, which is why its dashed lines reach every block. It is the only unit that does no work of its own and the one that decides how long all the others can work.

Step 2: two real sensor nodes

Two motes are used throughout this book. TOSSIM simulates the MICAz, and a real-hardware TinyOS build on Ubuntu 22.04 works for the TelosB (the TinyOS laboratory chapter showed both). They share their radio and differ in their microcontroller.

The sources are the MICAz datasheet for the MICAz column's board figures, the ATmega128L and MSP430F1611 datasheets for each chip's memory and supply range, and TinyOS's own tos/platforms/micaz/hardware.h, whose comment gives the MICAz's clock as "~8MHz".

Four kilobytes of RAM is the number to remember. Every variable, every packet buffer, every queue and the program's stack must fit into 4,096 bytes on a MICAz. That is why TinyOS has no threads, each of which would need a stack of its own, and why Practical 3's scheduler exists.

Step 3: what each unit draws

A unit's current depends on its mode, and every chip here has at least two: working, and asleep.

Three things in that table matter more than the rest.

Receiving costs more than transmitting. 19.7 mA against 17.4 mA on the MICAz. And a radio that is listening for a packet that may never come is receiving: it draws the full receive current whether or not anything arrives. This is called idle listening, and step 4 shows it is what empties a sensor node's battery.

Asleep is a thousand times cheaper than awake. The processor falls from 8 mA to under 15 microamperes, the radio from 19.7 mA to 1 microampere.

Watch the word "idle". The MICAz datasheet lists the radio's "Idle mode, voltage regular on" at 20 microamperes. The CC2420's own datasheet calls that same state power down and uses "idle" for a different one, with the crystal oscillator running, at 426 microamperes. Two datasheets, one chip, one word meaning two things. Always read the condition column, not just the mode's name.

Step 4: the energy budget, computed

The average current of a node that is awake a fraction d of the time, and asleep the rest, is:

and its life on a battery of capacity C is C divided by the average current. The program below does exactly that, for the MICAz, with every figure taken from the tables above. Save it as energy.py:

# energy.py: the energy budget of a MICAz mote, from its datasheets.
# Currents are in milliamperes, and are the MICAz datasheet's own figures.

VOLTS = 3.0             # two AA cells in series
CAPACITY_MAH = 3000.0   # an AA alkaline cell at a 25 mA drain (Energizer E91)

CPU_ACTIVE = 8.0        # processor, active
CPU_SLEEP = 0.015       # processor, sleep ("< 15 uA")
RADIO_RX = 19.7         # radio receiving, which is also what listening costs
RADIO_TX = 17.4         # radio transmitting at 0 dBm
RADIO_SLEEP = 0.001     # radio asleep, voltage regulator off

awake = CPU_ACTIVE + RADIO_RX
asleep = CPU_SLEEP + RADIO_SLEEP
print("Awake, radio listening: %7.3f mA" % awake)
print("Everything asleep:      %7.3f mA" % asleep)
print()
print("Awake for   Average current   Spent asleep      Battery life")
for duty in (1.0, 0.1, 0.01, 0.001):
    average = duty * awake + (1 - duty) * asleep
    share = (1 - duty) * asleep / average * 100
    hours = CAPACITY_MAH / average
    print("%7.1f %%   %12.4f mA   %9.1f %%   %7.0f hours, %5.0f days"
          % (duty * 100, average, share, hours, hours / 24))

# One IEEE 802.15.4 frame as the CC2420 sends it (CC2420 datasheet, section 16):
# 4 preamble bytes, 1 start-of-frame byte and 1 length byte, then TinyOS's
# 11-byte header (tos/chips/cc2420/CC2420.h), the payload and a 2-byte checksum.
RATE = 250000           # bits per second
print()
for payload in (2, 28):
    frame = 4 + 1 + 1 + 11 + payload + 2
    seconds = frame * 8 / RATE
    microjoules = VOLTS * RADIO_TX * seconds * 1000   # V x mA x s = mJ
    cpu_ms = microjoules / (VOLTS * CPU_ACTIVE)       # uJ / mW = ms
    print("Payload %2d bytes: %2d bytes on air, %.3f ms, %4.1f uJ,"
          " as much as %.2f ms of processing, %5.0f cycles at 8 MHz"
          % (payload, frame, seconds * 1000, microjoules, cpu_ms, cpu_ms * 8000))
listening = VOLTS * RADIO_RX * 1.0 * 1000          # one second, in uJ
print("One second of listening: %.0f uJ, the energy of %.0f full packets"
      % (listening, listening / microjoules))

$ python3 energy.py
Awake, radio listening:  27.700 mA
Everything asleep:        0.016 mA

Awake for   Average current   Spent asleep      Battery life
  100.0 %        27.7000 mA         0.0 %       108 hours,     5 days
   10.0 %         2.7844 mA         0.5 %      1077 hours,    45 days
    1.0 %         0.2928 mA         5.4 %     10245 hours,   427 days
    0.1 %         0.0437 mA        36.6 %     68675 hours,  2861 days

Payload  2 bytes: 21 bytes on air, 0.672 ms, 35.1 uJ, as much as 1.46 ms of processing, 11693 cycles at 8 MHz
Payload 28 bytes: 47 bytes on air, 1.504 ms, 78.5 uJ, as much as 3.27 ms of processing, 26170 cycles at 8 MHz
One second of listening: 59100 uJ, the energy of 753 full packets

Read the first table from the top.

Awake all the time, the node lasts about five days. 27.7 mA is the processor and the listening radio together, and a 3,000 mAh battery at 27.7 mA gives about 108 hours. That is what a sensor node with no power management would do, and it is useless: nobody deploys a network that must be visited every five days.

Awake 1 per cent of the time, it lasts over a year. The average falls from 27.7 mA to under 0.3 mA, and the life rises nearly a hundredfold, because nearly all the energy was being spent awake. This is what duty cycling means: the node sleeps, wakes briefly to sense and to talk, and sleeps again. The duty cycle is the fraction of the time it is awake.

But at 0.1 per cent the gain is not tenfold. Cutting the time awake by ten again only raises the life from 427 days to 2,861, about 6.7 times. The third column says why: at 0.1 per cent, 36.6 per cent of the average current is being spent asleep. Once a node is asleep nearly all the time, its sleep current, which was negligible at high duty cycles, becomes a large part of the budget, and only a better sleep current (the MSP430's 1.1 microampere standby against the ATmega128L's 15) can push the life further.

Treat the lives as upper limits, and compare them with each other rather than believing them one by one. The battery's 3,000 mAh is measured down to 0.8 V a cell, and the ATmega128L stops working below 2.7 V, which is 1.35 V a cell for two cells in series, so a real MICAz uses less of the battery than the program assumes. The shape of the result does not change: every factor of ten in the duty cycle is worth nearly a factor of ten in life, until the sleep current takes over.

Step 5: one packet against one second of listening

The second part of the output compares what the radio costs with what the processor costs.

A frame is what actually goes on the air, and it is longer than the data in it. The CC2420 datasheet gives the IEEE 802.15.4 frame as a 4-byte preamble, a 1-byte start-of-frame delimiter and a 1-byte length, then the frame itself; TinyOS's header for the CC2420 (tos/chips/cc2420/CC2420.h) adds 11 bytes before the data, and a 2-byte checksum follows it. So a packet carrying 2 bytes of data puts 21 bytes on the air, and one carrying TinyOS's largest default payload, 28 bytes, puts 47.

At 250 kilobits a second a 21-byte frame takes 0.672 milliseconds to send. At 3 V and 17.4 mA that is 35.1 microjoules, the same energy as the processor spends in 1.46 milliseconds of work, which the program counts as 11,693 clock cycles at 8 MHz. Sending a short packet costs as much energy as thousands of instructions, which is why a node should process data locally and send less of it. Practical 2 does exactly that with data aggregation.

And then the last line. One second of listening costs 59,100 microjoules, the energy of 753 full-size packets. A radio left on to wait for messages burns in one second what the node would spend sending its data for weeks. That single comparison is why sensor network MAC protocols, S-MAC in Practical 17 among them, exist at all: their whole purpose is to keep the radio off without missing the packets that matter.

Step 6: memory, measured by the compiler

The processor's other constraint is memory, and here the compiler measures it for you. The awk script below reads the two lines make telosb prints and turns each into a share of the TelosB's 48 KB of flash and 10 KB of RAM:

/bytes in ROM/ { printf "ROM %6d of 49152 bytes, %4.1f per cent\n", $1, $1 * 100 / 49152 }
/bytes in RAM/ { printf "RAM %6d of 10240 bytes, %4.1f per cent\n", $1, $1 * 100 / 10240 }

Two applications, the smallest and one with a radio. Each is copied out of TinyOS and given the book's Makefile:

COMPONENT=BlinkAppC
override GCC = gcc-10
export GCC
PFLAGS += -fgnu89-inline -fsigned-char
include $(MAKERULES)

COMPONENT=RadioCountToLedsAppC
override GCC = gcc-10
export GCC
PFLAGS += -fgnu89-inline -fsigned-char
include $(MAKERULES)

$ cp -r $TOSROOT/apps/Blink ~/Blink && cp Makefile.blink ~/Blink/Makefile
$ cp -r $TOSROOT/apps/RadioCountToLeds ~/Radio && cp Makefile.radio ~/Radio/Makefile
$ cd ~/Blink && make telosb 2>&1 | awk -f ~/memory.awk
ROM   2538 of 49152 bytes,  5.2 per cent
RAM     56 of 10240 bytes,  0.5 per cent
$ cd ~/Radio && make telosb 2>&1 | awk -f ~/memory.awk
ROM  11346 of 49152 bytes, 23.1 per cent
RAM    356 of 10240 bytes,  3.5 per cent

The numbers are the compiler's own, and they say three things.

RAM is the scarce one. Blink needs 56 bytes of RAM, RadioCountToLeds 356, which includes a buffer for one packet and the radio stack's own state. On a TelosB's 10 KB that is little; on a MICAz's 4 KB it would already be nearly a tenth, and a real application with routing tables and queues fills it quickly.

The radio stack is most of a radio application. RadioCountToLeds is not much more code than Blink, yet its ROM is 11,346 bytes against 2,538. The difference is the CC2420 driver and the active-message layer compiled into it: in TinyOS the operating system you use is compiled into your application.

Memory costs energy too. RAM keeps its contents only while powered, so a sleeping node keeps its RAM supplied, which is part of its sleep current, and data that must survive a restart has to be written to flash, which takes time and energy of its own.

Step 7: the role of each unit in an energy-constrained environment

This is the analysis MU asks for, one unit at a time, with the figures from the steps above.

The table has a pattern. Every unit's energy is decided by how long it stays on, not by how hard it works while on. That is why the microcontroller's most important job is not computing but switching things off, and why the next nine practicals are about an operating system built around sleeping until an event arrives.

Procedure

1. Draw the block diagram of a sensor node with its five units and label every arrow as data or power.
2. Tabulate the parts of two real nodes, the MICAz and the TelosB, from their datasheets.
3. Tabulate the current each unit draws in each mode, with the source of every figure.
4. Write energy.py and run it: the average current and battery life at four duty cycles, the energy of one packet, and the energy of one second of listening.
5. Build two TinyOS applications for a TelosB and measure their memory against the chip's capacity.
6. For each unit, state its role, its largest energy cost and how that cost is reduced.

Observations

Result

A conceptual block diagram of a wireless sensor node was drawn with its sensing unit, processing unit (microcontroller and memory), transceiver and power unit, and made concrete with the parts of the MICAz and the TelosB taken from their datasheets. The energy analysis showed that a MICAz awake all the time lasts about 5 days on two AA cells, and about 427 days awake 1 per cent of the time; that at 0.1 per cent the sleep current becomes over a third of the budget; that one short packet costs as much energy as about 1.5 milliseconds of processing; and that one second of listening costs as much as 753 full-size packets. The compiler measured RAM as the scarcer memory. In an energy-constrained environment the role of every unit is decided by how long it is kept on, and the microcontroller's most important job is to keep the others asleep.

Where marks are lost

Four boxes and no arrows. A block diagram without its data and power connections is a list. Label what flows along each line.

Leaving out the power unit, or drawing it as one more box in the chain. It feeds every other unit, and the diagram must show that.

Quoting a battery life without a duty cycle. "The mote lasts a year" means nothing until you say how much of the time it is awake.

Believing transmitting is the expensive part. On the MICAz, receiving draws more than transmitting, and a radio that listens is receiving.

Mixing the datasheets' names for modes. The MICAz's "idle" is the CC2420's "power down". Quote the current with its condition.

Writing currents without units, or microamperes as milliamperes. 15 microamperes is 0.015 mA. A factor of a thousand wrong makes every conclusion wrong.

Taking the lives as exact. They are upper limits; say so, and why.

For the journal

Aim; the five units of a sensor node, each in two lines; the block diagram with its arrows labelled; the table of the two real nodes; the table of currents with their sources; the formula for the average current; energy.py with its output; the frame-length working for a 2-byte and a 28-byte payload; the memory measurements with memory.awk; the table of each unit's role, largest cost and how the cost is cut; the observation table; the result.

Quick revision

• Five units: sensing unit, microcontroller, memory, transceiver, power supply.
• MICAz: ATmega128L (128 KB flash, 4 KB RAM, 4 KB EEPROM), CC2420 radio, two AA cells.
• TelosB: MSP430F1611 (48 KB flash, 10 KB RAM), the same CC2420.
• CC2420: IEEE 802.15.4, 2.4 GHz, 250 kbps; receive 19.7 mA, transmit 17.4 mA at 0 dBm on the MICAz board.
• Average current = d × awake + (1 - d) × asleep; life = capacity divided by average current.
• MICAz: 5 days always awake, 427 days at 1 per cent.
• At very low duty cycles the sleep current dominates.
• One second of listening costs as much as 753 full-size packets: idle listening is the enemy.
• Sending a short packet costs as much as about 1.5 ms of processing.
• RAM, not flash, is the scarce memory.

Questions you must be able to answer

1. Name the units of a wireless sensor node and what each does. The sensing unit turns a physical quantity into a number, the microcontroller runs the application and controls every other unit, the memory holds the program, its data and stored readings, the transceiver sends and receives packets, and the power supply feeds all of them.

2. Why is energy the central constraint of a sensor node? Nodes run on batteries and are left where they are placed, often in large numbers, so replacing batteries is impractical. The node's useful life is its battery life.

3. Which draws more on a MICAz, receiving or transmitting? Receiving: 19.7 mA against 17.4 mA at 0 dBm. Listening for a packet is receiving, so a radio left listening is the largest drain on a node.

4. What is a duty cycle, and what does it do to battery life? The fraction of the time a node is awake. On a MICAz, 100 per cent gives about 5 days and 1 per cent about 427 days on the same two AA cells.

5. Why does cutting the duty cycle from 1 per cent to 0.1 per cent not give ten times the life? Because the sleep current stays. At 0.1 per cent, 36.6 per cent of the average current is spent asleep, so the life rises only about 6.7 times.

6. How many bytes does a 2-byte payload put on the air, and why so many? 21: a 4-byte preamble, a start-of-frame byte and a length byte from IEEE 802.15.4, an 11-byte TinyOS header, the 2 bytes of data and a 2-byte checksum.

7. Why should a node process data before sending it? Because sending costs far more than computing: one short packet costs as much energy as about 1.5 milliseconds of processing, 11,693 clock cycles at 8 MHz.

8. The MICAz datasheet says the radio's idle mode draws 20 microamperes and the CC2420 datasheet says 426. Which is right? Both. The MICAz datasheet's "idle, voltage regulator on" is the state the CC2420 datasheet calls power down, 20 microamperes; the CC2420's own "idle" keeps the crystal oscillator running and draws 426.

9. Which memory is scarcer on a MICAz, and what follows from it? RAM, 4 KB against 128 KB of flash. It is why TinyOS has no threads, each of which would need its own stack, and why buffers and tables are kept small.

10. What is the most important job of a sensor node's microcontroller? Deciding when every unit, itself included, may sleep. The node's life is set by how long things stay on.