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

Download Report

Transcript 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 OEP 9/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 9/11/2001 2

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

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/2001 NEST Quarterly 4

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 2xAA form factor Cost-effective power source NEST Quarterly 9/11/2001 5

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

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

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

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

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

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 added two PWM lines

(were unknown)

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)

– – –

9/11/2001 lose most sensor capability address lines share with lowest priority devices (LEDS, Flash ctrl) still allows radio, flash, and programming NEST Quarterly 11

Sensor Board

• • • •

Light Temperature 2D Accelerometer Acoustic threshold detector 9/11/2001 NEST Quarterly 12

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

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/2001 NEST Quarterly 14

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

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

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

Ad Hoc MCAST: Radio Cells

9/11/2001 NEST Quarterly 18

ad hoc MCAST

9/11/2001 NEST Quarterly 19

Multihop Network Topology

9/11/2001 NEST Quarterly 20

Robust network command mcast

• • •

Higher-level middleware component

– –

rooted at any node novel primitives

»

squelch retransmission

»

amorphous mcast if (new mcast) then take action retransmit modified request

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

Example

9/11/2001 NEST Quarterly 22

Surge II viz: sensor field + network

9/11/2001 NEST Quarterly 23

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

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/2001 NEST Quarterly 25

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

TOSSIM Performance

Executing for 10 seconds of virtual time

Periodic Broadcast Motes 1 10 100 1000 Time(sec) 0.22

3.11

34.08

185.77

6 5 4 3 2 1 0 1 10

Motes

100 1000

NEST Quarterly 9/11/2001

Periodic Broadcast

27

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

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/2001 NEST Quarterly 29

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

Component Challenge: localization

• •

given

– – –

graph of localized measurements C ij and locations of certain marker nodes P i to within some tolerance = x i ,y i ,z i 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/2001 NEST Quarterly 31

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

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

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/2001 NEST Quarterly 34

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