Berkeley NEST Wireless OEP 9/01 Progress and Plans David Culler Eric Brewer Dave Wagner Shankar Sastry Kris Pister University of California, Berkeley.
Download ReportTranscript 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