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

9/11/2001NEST Quarterly2 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

9/11/2001NEST Quarterly3 Design Requirements Deliver complete kits in Jan 02 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

9/11/2001NEST Quarterly4 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

9/11/2001NEST Quarterly5 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

9/11/2001NEST Quarterly6 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

9/11/2001NEST Quarterly7 Radio Retained RFM TR 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

9/11/2001NEST Quarterly8 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

9/11/2001NEST Quarterly9 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

9/11/2001NEST Quarterly10 Timing, Identity, and Output Retain Dual Oscillator Design High Accuracy 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

9/11/2001NEST Quarterly11 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

9/11/2001NEST Quarterly12 Sensor Board Light Temperature 2D Accelerometer Acoustic threshold detector

9/11/2001NEST Quarterly13 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)

9/11/2001NEST Quarterly14 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)

9/11/2001NEST Quarterly15 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

9/11/2001NEST Quarterly16 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

9/11/2001NEST Quarterly17 Network programming Suite of handlers to support NP –start new program upload –write fragment i to 2 nd 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

9/11/2001NEST Quarterly18 Ad Hoc MCAST: Radio Cells

9/11/2001NEST Quarterly19 ad hoc MCAST

9/11/2001NEST Quarterly20 Multihop Network Topology

9/11/2001NEST Quarterly21 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

9/11/2001NEST Quarterly22 Example

9/11/2001NEST Quarterly23 Surge II viz: sensor field + network

9/11/2001NEST Quarterly24 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

9/11/2001NEST Quarterly25 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,...

9/11/2001NEST Quarterly26 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

9/11/2001NEST Quarterly27 TOSSIM Performance Executing for 10 seconds of virtual time

9/11/2001NEST Quarterly28 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

9/11/2001NEST Quarterly29 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

9/11/2001NEST Quarterly30 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

9/11/2001NEST Quarterly31 Component Challenge: localization given –graph of localized measurements C ij –and locations of certain marker nodes P i = x i,y i,z i –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

9/11/2001NEST Quarterly32 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

9/11/2001NEST Quarterly33 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

9/11/2001NEST Quarterly34 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

9/11/2001NEST Quarterly35 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