NEST Quarterly Progress and Plans for Wireless Sensor Network at UC Berkeley

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

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

Sensor Board • Light • Temperature • 2D Accelerometer • Acoustic threshold detector NEST Quarterly

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) NEST Quarterly

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) NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

Ad Hoc MCAST: Radio Cells NEST Quarterly

ad hoc MCAST NEST Quarterly

Multihop Network Topology NEST Quarterly

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 NEST Quarterly

Example NEST Quarterly

Surge II viz: sensor field + network NEST Quarterly

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 NEST Quarterly

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, ... NEST Quarterly

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 NEST Quarterly

TOSSIM Performance • Executing for 10 seconds of virtual time NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

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 NEST Quarterly

NEST Quarterly Progress and Plans for Wireless Sensor Network at UC Berkeley