berkeley nest wireless oep 9/01 progress and plans david culler eric brewer dave wagner shankar...
Post on 21-Dec-2015
217 views
TRANSCRIPT
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
9/11/2001 NEST Quarterly 3
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
9/11/2001 NEST Quarterly 4
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 5
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/2001 NEST Quarterly 6
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/2001 NEST Quarterly 7
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 8
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/2001 NEST Quarterly 9
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/2001 NEST Quarterly 10
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
9/11/2001 NEST Quarterly 11
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/2001 NEST Quarterly 12
Sensor Board
• Light
• Temperature
• 2D Accelerometer
• Acoustic threshold detector
9/11/2001 NEST Quarterly 13
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/2001 NEST Quarterly 14
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 15
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/2001 NEST Quarterly 16
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/2001 NEST Quarterly 17
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
9/11/2001 NEST Quarterly 18
Ad Hoc MCAST: Radio Cells
9/11/2001 NEST Quarterly 19
ad hoc MCAST
9/11/2001 NEST Quarterly 20
Multihop Network Topology
9/11/2001 NEST Quarterly 21
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/2001 NEST Quarterly 22
Example
9/11/2001 NEST Quarterly 23
Surge II viz: sensor field + network
9/11/2001 NEST Quarterly 24
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/2001 NEST Quarterly 25
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 26
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/2001 NEST Quarterly 27
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
9/11/2001 NEST Quarterly 28
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/2001 NEST Quarterly 29
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 30
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/2001 NEST Quarterly 31
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
9/11/2001 NEST Quarterly 32
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/2001 NEST Quarterly 33
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/2001 NEST Quarterly 34
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 35
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