What’s New with Tiny Devices

What’s New with Tiny Devices

David CullerU.C. Berkeley

Endeavour MiniRetreat1/9/2001

1/9/2001 Endeavour Retreat 2

Ready for “Prime Time”

• Hardware Platform suited for Experimentation

• TinyOS well exercised and ready for release

• Several Exciting Studies digging in deeper

• Time for applications and serious tools


“Rene” wireless networked sensor platform

• 1” x 1.5” motherboard– ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8K pgm flash

– 900Mhz Radio (RF Monolithics) 10-100 ft. range

– ATMEL network pgming assist

– Radio Signal strength control and sensing

– I2C EPROM (logging)

– Base-station ready

– stackable expansion connector (all ports, i2c, pwr, clock…)


“Rene”simple sensor card proto

• 1” x 1.5”sensorboard– Stackable connector

– Thermistor (temp, analog)

– Proto

– Breadboard area


“Rene” motion sensor card

• 1” x 1.5” sensorboard– Accelerometers

– Magnetrometers

– Humidity, light, temp, sound, …


Laptop “lab kit”

Parallel Portfor programming

serial Portfor basestation

“Sensor stacks”on central connector


Lab analysis board

• Logical analyzer connectors

• Serial port

• Device bay


Power Breakdown…

• But what does this mean?– Lithium Battery runs for 35 hours at peak load and years at

minimum load!

» That’s three orders of magnitude difference!

– A one byte transmission uses the same energy as approx 11000 cycles of computation.

– Idleness is not enough, sleep!

Active Idle Sleep

CPU 5 mA 2 mA 5 μA

Radio 7 mA (TX) 4.5 mA (RX) 5 μA

EE-Prom 3 mA 0 0

LED’s 4 mA 0 0

Photo Diode 200 μA 0 0

Temperature 200 μA 0 0

Panasonic CR2354

560 mAh


TinyOS

• Extremely small code & data

• Address two appln behavior modes– Bursts of high concurrency (multiple streams)

– Long periods of no important activity

• Efficient fine-grain multithreading– Bit-by-bit processing in software

» hard real-time requirements

– Percolate events through multiple levels

• Power control on every interface– Shut it all down when idle

• Simple two-level scheduler

• Modularity for robustness & specialization


TinyOS Program Structure

• Application = graph of components + schedule

RFM

Radio byte

i2c

Tempphoto

Messaging Layer

clocksbit

byte

packet Radio Packet

Routing Layer

sensing applicationapplication

HW

SW

ADC

messaging

routing

UART Packet

UART byte


Application Demo

Code size for ad hoc networkingapplication

0

500

1000

1500

2000

2500

3000

3500

Byt

es

InterruptsMessage DispatchInitilizationC-RuntimeLight SensorClockSchedulerLed ControlMessaging LayerPacket LayerRadio InterfaceRouting ApplicationRadio Byte Encoder

Scheduler: 144 Bytes codeTotals: 3430 Bytes code

226 Bytes data


Program Representation: component

• Component = foo.comp + foo.c

• .comp defines interface– Commands it accepts

– Events it signals

– Commands it uses

– Events it handler

• .c file is the implementation– TOS_COMMAND - interface

– TOS_SIGNAL_EVENT

– TOS_CALL_COMMAND

– TOS_EVENT

– TOS_FRAME - internal state

– TOS_TASK - internal concurrency

– TOS_POST_TASK

• Only refer to internal and interface names

• All commands/events may return “No”

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events


Example Component

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events

//AM.comp//TOS_MODULE AM;ACCEPTS{ char AM_SEND_MSG(char addr, char type,

char* data); void AM_POWER(char mode); char AM_INIT();};SIGNALS{ char AM_MSG_REC(char type,

char* data); char AM_MSG_SEND_DONE(char success);};HANDLES{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet);};USES{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT();};


Component graph

• Application described by .desc file

• List of components

• “wiring” on interface ports

• Including “dispatch” ports– Active message demux

– ADC (shared resource) demux

• May “name” connections or not

• Descriptions may be hierarchical

• Tools translate names across component interfaces

• Structured wiring => optimize across component boundaries

• Can interpose or exchange components


Example descriptioninclude modules{

MAIN;

CHIRP;

GENERIC_COMM;

PHOTO;

CLOCK;

LEDS;

};

MAIN:MAIN_SUB_INIT CHIRP:CHIRP_INIT

MAIN:MAIN_SUB_SEND_MSG DUMMY:vSTART

CHIRP:CHIRP_START DUMMY:vSTART

…

CHIRP:CHIRP_CLOCK_INIT CLOCK:CLOCK_INIT

CHIRP:CHIRP_CLOCK_EVENT CLOCK:CLOCK_FIRE_EVENT

…

CHIRP:CHIRP_SUB_SEND_MSG GENERIC_COMM:GENERIC_COMM_SEND_MSG

CHIRP:CHIRP_SUB_MSG_SEND_DONE GENERIC_COMM:GENERIC_COMM_MSG_SEND_DONE

…


Example (cont)

GENERIC_COMM.desc

include modules{

AM;

RED_PACKETOBJ;

FOUR_B_RADIO_BYTE;

RFM;

};

….

TOS_MODULE GENERIC_COMM;

IMPLEMENTED_BY GENERIC_COMM;

ACCEPTS{

char GENERIC_COMM_INIT();

void GENERIC_COMM_POWER(char mode);

char GENERIC_COMM_SEND_MSG(char addr, char type, char* data);

};

SIGNALS{

char GENERIC_COMM_MSG_REC(char type, char* data);

char GENERIC_COMM_MSG_SEND_DONE(char success);

};


Real time operating systems

• QNX context switch = 2400 cycles on x86

• pOSEK context switch > 40 µs

• Creem -> no preemption

Name Code Size Target CPUpOSEK 2K MicrocontrollerspSOSystem PII->ARM ThumbVxWorks 286K Pentium -> Strong ARMQNX Nutrino >100K Pentium II -> NECQNX RealTime 100K Pentium II -> SH4OS-9 Pentium -> SH4Chorus OS 10K Pentium -> Strong ARMARIEL 19K SH2, ARM ThumbCreem 560 bytes ATMEL 8051


Thoughts about robust Algorithms

• Active Dynamic Route Determination– When route_beacon handler fires with M(hops) < hops

» UP = M(source); hops = M(hops)++; M(source) = self; send;

– Periodically increase hops

• Radio cell structure very unpredictable• Builds and maintains good breadth-first forest• Each node only records own state and parent(s)• Fundamental operation pruning retransmission

– Monotonic variables– Message signature caches

• Exercise: no beacons, just piggyback on data


Low-Power Listening (J. Hill)

• Costs about as much to listen as to xmit, even when nothing is received

• Only way to save power is to turn radio off when there is nothing to hear.

• Can turn radio on/of in about 1 bit– Can detect transmission at cost of ~2 bit times

Small sub-msg recv sampling

Application-level synchronization rendezvous to determine when to sample

Xmit:

Recv:

preamble messagesleep

b

Optimal Preamble = (2/3 Sxb)1/2


Packet Encoding / Layers

• Radio requires rough DC balance– No more than three ones between zeros

• Manchester encoding

• 4b/6b

• Bit error rate significant and increases with distance

• CRC, 3-redundant

• …or SECDED with DC-balanced coding

Radio byte components

Radio packet components


Channel Utilization (A. Woo)• Per-cell channel utilization important near base• MAC studies revealed subtle TinyOS jitter bug• Simple CSMA algorithm proved effective

– Listen random delay (16 bit LFB SR)– On busy, wait till idle

1. Aggregate Util

2. Detected collisions

3. Fraction of attempted BW delivered


Bandwidth Management

• Hidden nodes between each pair of “levels”– CSMA is not enough

• RTS/CTS acks too costly (power & BW)• P[msg-to-base] drops rapidly with hops

– Investment in packet increases with distance

Local rate control to approx. fairness Priority to forwarding, adjust own data rate Additive increase, multiplicative decrease

Listen for retransmission as ack~ ½ of packets get through 4 levels out


Proximity / Location detection

• Signal strength sensing– Circuit works, falls off cleanly in good environment

– Incredibly sensitive to obstructions!

• Error rates a useful proximity metric– Bit errors vs. packet errors

• Klemmer,Waterson, Whitehouse study => signal strength + Kalman filter provides good position detection


Authentication / Security (Szewczyk, et al)

mote <-> basestation authentication and confidentiality– stream cipher RC5 encryption => no extra bits transmitted on

encryped data– 8 byte MAC, based on RC5– authenticated basestation broadcast based on TESLA

» protocol based on delayed key disclosure and time synch.» distribute routing beacons using authenticated broadcast =>

authenticated routing– additional protocols to guarantee freshness

• Implementation of above consumes about 1/3 of the mote resources (code space, RAM, processing)

• Shared key cryptography based on RC5– public key cryptography is much too expensive– heavy code reuse - RC5 used for a variety of tasks– a key shared between mote and basestation programmed into the

mote at initial programming time– first computationally expensive application on the motes


Application-Specific Virtual Machine

• Small byte-code interpreter component– Code, static data, stack

• Accepts clock-event capsules– Other events too

• Hides split-phase operations below interpreter

• HW + collection of components defines space of applications

– Allows very efficient coding within this space

• Capsules define specific query / logic


Application Deployment• Light sensing + location

inference based on landmarks

• 16 motes deployed on 4th floor Soda Hall

• 10 round motes as office landmarks

• 2 base stations around corners of the building

• 4 Rene motes as active badges for location tracking

• AA batteries (3 weeks)

• Tracking precision +/- one office

http://nighthawk.cs.berkeley.edu:8080/tracking


Open Projects / Problems

• Ambient-power devices

• Debugging

• Many-mote simulator

• Logging component + trace analysis

• Message fragmentation

• Query processing

• Visualization

• Static critcal-path, jitter analysis

• REAL APPLICATIONS

Documents

What’s New with Tiny Devices