1 / 35

Berkeley NEST Wireless OEP 9/01 Progress and Plans

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

kirstie
Download Presentation

Berkeley NEST Wireless OEP 9/01 Progress and Plans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  12. Sensor Board • Light • Temperature • 2D Accelerometer • Acoustic threshold detector 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) 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) 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 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 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 NEST Quarterly

  18. Ad Hoc MCAST: Radio Cells NEST Quarterly

  19. ad hoc MCAST NEST Quarterly

  20. Multihop Network Topology 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 NEST Quarterly

  22. Example NEST Quarterly

  23. Surge II viz: sensor field + network 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 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, ... 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 NEST Quarterly

  27. TOSSIM Performance • Executing for 10 seconds of virtual time 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 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 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 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 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 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 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 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 NEST Quarterly

More Related