Berkeley NEST Wireless OEP 9/01 Progress and Plans David Culler Eric Brewer Dave Wagner Shankar Sastry Kris Pister University of California, Berkeley

Berkeley NEST Wireless OEP9/01 Progress and Plans

David Culler

Eric Brewer Dave Wagner

Shankar Sastry Kris Pister

University of California, Berkeley

9/11/2001 NEST Quarterly 2

Outline

• OEP v1 requirements

• OEP v1 hardware design

• Key OEP Software Developments– experience at scale

– network programming

– robust bcast/multicast action

– large-scale simulator

• Working across abstractions– signal strength info

– time synchronization support

– power-efficient wake up

• Plans


Design Requirements

• Deliver complete kits in Jan 02• More storage, • More storage, • More ...• More communication bandwidth• More capability available to sensor boards• stable voltage reference• retain “cubic inch” form factor and AA/year

power budget• allow opportunities for new approaches

– time synchronization– other algorithms


Major features

• 16x program memory size (128 KB)• 8x data memory size (4 KB)• 16x secondary storage (512 KB)• 5x radio bandwidth (50 Kb/s)• 6 ADC channels available • Same processor performance• Allows for external SRAM expansion• Provides sub microsecond RF synchronization

primitive• Provides unique serial ID’s• On-board DC booster• Remains Compatible with Rene Hardware and

current tool chain


In a nutshell

• Atmel ATMEGA103 – 4 Mhz 8-bit CPU

– 128KB Instruction Memory

– 4KB RAM

• 4 Mbit flash (AT45DB041B)– SPI interface

– 1-4 uj/bit r/w

• RFM TR1000 radio– 50 kb/s

• Network programming

• Same 51-pin connector– Analog compare + interrupts

• Same tool chain Cost-effective power source

2xAA form factor


Microcontroller

• Conducted extensive comparison of alternatives– narrowed list based on availability and design size

• Deep study of prime candidates– ATmega 163 – same pinout as 8535, 2x mem, reprog– ARM Thumb – greater perf, poor integration, slow radio– TI MSP340 – Low power, HW *, 2-buffered SPI tx, no gcc– ATMEGA 103 – storage!, integration, compatibility

• Selected Atmel ATMEGA103 – 4 Mhz 8-bit CPU– 128KB Instruction Memory (16x increase from Rene)– 4KB RAM (8x increase from Rene)– Compatible with “Rene” CPU and tools– able to support high bandwidth radio techniques– Re-programmable over Radio or Connector


Radio

• Retained RFM TR1000 916 Mhz radio• Developed circuit able to operate in OOK (10 kb/s) to ASK

(115 kb/s) mode– smaller prate resistor, race-conditional work-around– pwidth res. tied to vcc to push to maximum sample rate– decrease baseband capacitor to increase RF sensitivity

• Design SPI-based circuit to drive radio at full speed– current bit-level edge detect on 10 kb/s preamble– analog comparator to find high speed edge– SPI synch. serializer to drive/receive bits– resynch on every byte– full speed on TI MSP, 50 kb/s on ATMEGA

• Improved Digitally controlled TX strength DS1804 – 1 ft to 300 ft transmission range, 100 steps

• Input timing capture +/- .5 us on RX pin.• Receive signal strength detector

– software integration


Network Programming and Storage

• ATMEGA103 in-circuit, but external reprog.– retain secondary co-processor – AT90LS2343 only small device with internal clock and in-

circuit programming

• 4 Mbit flash (AT45DB041B)– Store code images, Sensor Readings and Calibration tables

– 16x increase in prog. mem too large for EEPROM solution

– forced to use FLASH option

– SPI Protocol instead of I2C!

» radio is using HW SPI support

• Novel multiplexing of 6 I/O pins on 2343 to drive 7 signals to interface to Flash SPI and 103– relies on remembering a previous control bit


Power

• Developed Energy-harvesting design with solar cells, superCaps, and DC booster

• Built components for Intel power regulator board

• Studied wake-up transients

• Incorporated On-board Voltage Regulation (Maxim1678)– Boost Converter provides stable 3V supply

– Stabilizes RF performance

– Allows variety of power sources

– Can run on batteries down to 1.1 V

• Incorporated power supply sensor– Can measure battery health

– used to adjust wake-up threshold for unregulated design

• added line to disable vcc to pot – reduce standby current


Timing, Identity, and Output

• Retain Dual Oscillator Design

• High Accuracy 32.768 crystal for real-time measurement and synchronization

• 4 MHz oscillator– developed design with resonator

– required software recalibration

• Electronic 64-bit serial number (DS2401)– one-wire protocol

• 3 LEDs


Expansion Capabilities

• Backwards compatible to existing sensor boards– eliminated i2c-2 (was for EEPROM, which is now ext. SPI)– eliminated UART2

• added two analog compare lines• added five interrupt lines (were unknown)• added two PWM lines• 6 ADC channels

– 10 bits/sample – 10K samples/second

• I2C Expansion Bus (i2c-1)• SPI Expansion Bus• 8 Digital I/O or Power Control Lines (was 4)• Can connect external SRAM for CPU data memory (up to 64KB)

– lose most sensor capability– address lines share with lowest priority devices (LEDS, Flash ctrl)– still allows radio, flash, and programming


Sensor Board

• Light

• Temperature

• 2D Accelerometer

• Acoustic threshold detector


Why not ARM Thumb ?

• CPU switch requires establishing a new tool chain (compiler, linker, programmer) that would be untested

• Peripheral support around Atmel AT91 does not allow for high bit rate RF communication

• Power consumption of high clock rates is still prohibitively high

• Very interesting to pursue in integrated core design– see SYCHIP (arm thumb + gps)


Why Not Faster/Different Radio?

• RFM TR1000 is the lowest power RF Transceiver on the market

• High speed radios usually come with digital protocol logic forcing users into set communication regimes

• Raw interface to the RF transmission allows for exploration of new communication paradigms (Proximity Mode and Sleep)


Key TinyOS developments

• Initial visualization

• Network programming

• RF Localization support

• Robust command broadcast

• Aggregation

• Query by schema

• Calibration

• Breaking boundaries– power efficient wake up

– robust sample-based proximity


Testing at Scale

• In collaboration with Intel produced 1,000 compressed node

– size of quarter, stack 4 high with battery

– used ATMEGA 163 (2x rene)

• Stressed software components, manufacturing, testing

• Goal was live demonstration of network discovery in realistic setting

– many people in a large space


Network programming

• Suite of handlers to support NP– start new program upload

– write fragment i to 2nd store (EEPROM) – incl. checksum

– read fragment map i

– initiate reload

» including verification

• Boot loader on “little guy”– transfers complete, check-summed fragment set to main controller

– reset

• Demonstrated up 113 nodes in single cell mode

• Multihop version preliminary operation– disseminate fragments

– aggregate verifications

• Integrated into generic_comm


Ad Hoc MCAST: Radio Cells


ad hoc MCAST


Multihop Network Topology


Robust network command mcast

• Higher-level middleware component– rooted at any node– novel primitives

» squelch retransmission» amorphous mcast

– many applications» discovery, act, acquire data

• Huge potential redundancy at scale– traditional: elect and maintain cluster heads– alternative: probabilistic forwarding

• Many factors influence propagation dynamics– early retransmit have many children– fast, turbulent wavefront– later collisions reduce redundancy

if (new mcast) then

take action

retransmit modified request


Example


Surge II viz: sensor field + network


Aggregation

• process data across set of nodes within the network

– vector logical, sum, ave, median, percentile, ...

• Dynamic physical structure

• View as time series aggregation rooted at a node

• Each level pushes request deeper then streams partial results

• Often can allow child to push result to multiple parents


Query by schema

• Nodes contain schema of what data they contain– id, hw config, version, temp*, light*, ...

• Can request the schema

• Can request elements of schema

• Requests may be one time, periodic, on threshold, ...


TOSSIM

• Discrete event simulation for large sensor networks

• Provides implementation of hardware abstractions

– Individual rf modulation events, sensor events, clock events

– existing applications work

• Exploits TinyOS event driven structure– host emulation down to HW abstraction

– redefine TOS macros and scheduler

• Allows debugging of distributed algorithms

• Proper execution verified up to 1000 motes

• Currently Static error-free connection topology


TOSSIM Performance

• Executing for 10 seconds of virtual time

Periodic Broadcast

0

1

2

3

4

5

6

1 10 100 1000

Motes

log

(tim

e)

PeriodicBroadcast

Motes Time(sec)1 0.2210 3.11

100 34.081000 185.77


Power Efficient Wake up

• minimize listening in communicating event to many nodes

• via messages- must transmit for 1.e x sleep interval- may have to wait (actively) for n neighbors- receiver must lock onto message, may get many– for all nodes awake after <= 2 rounds

» listen 1 sec with 8 sec asleep, 16 sec announce

• via sampling base-band “tone”– detect “any” send

» does not matter that “rx = 0”– short listen

» 200 us listen with 4 sec sleep, 10 sec announce» density independent


Sample-based Proximity Count

• minimize listening in communicating small amount of data to many nodes

• extend “tone” approach with sampling

• sequence of events, each node transmits with known probability

• infer count based on frequency of null events

• density independent


Challenge Application Series

• Sensing and Updates of the Environment in Response to Events and Queries.

– monitor the environment of a building and use this to instigate control actions such as lighting, HVAC, air-conditioning, alarms, locks, isolation, etc.

– monitor and protect space from environmental attack

• Distributed Map Building– classic “art gallery” problem is provably hard– many agents with simple proximity sensors to detect

obstacles– exchange info => dense collaborative map building

• Pursuit Evasion Games– combination of map building and intent determination by

both teams using networks of motes with possible information attacks and mis-information from the two teams


Component Challenge: localization

• given – graph of localized measurements Cij

– and locations of certain marker nodes Pi = xi,yi,zi

– to within some tolerance

• compute locations of remaining nodes using the communication available among the nodes

=> distributed constraint solving • goodness metrics

– location estimation error– size and shape of marker set– complexity (time, proc, communication, energy)– robustness– rate of convergence

• variations– small subset of more powerful nodes with more comm


RF localization support

• RFM baseband output provided to ADC

• Signal strength component collects samples – computes average over well-define preamble

– traditional solution would build HW integration circuit

• Provided to application components as part of packet envelope

– accessible to packet handler

• Signal strength control to change cell size

• Preliminary studies of range of localization algorithms


Closing the loop more

• detect and track “plume”– moving node

– moving light/hot region

• network actively adapts to expend energy sensing in region surrounding plume

• actively adapts to convey packets through rest of network

• time synchronization: – correlate multiple readings

– orchestrate multihop transfer schedule


Component challenge: time synch

• Synchronize local clocks to specified tolerance

• Need means of verifying success– use high precision clocks at edges and fast network between

• Novel system support– to communicate over the radio, transmitter and receive are

synchronized to fraction of a bit

– +- .5 us

– can timestamp particular bit in message to this accuracy

=> message carries info on time and place of origin


Conclusions

• HW platform development on schedule

• SW platform exercised in many distinct dimensions

• Demonstrates possibility of working across traditional layers in distributed system

• Novel algorithmic basis

• Formulating well-define subproblems for determination of “best of breed” algorithms

Documents

Berkeley NEST Wireless OEP 9/01 Progress and Plans David Culler Eric Brewer Dave Wagner Shankar Sastry Kris Pister University of California, Berkeley