Power evaluation of SmartDust remote sensors

1. Power evaluation of SmartDust remote sensors CS 252 Project Presentation Robert Szewczyk Andras Ferencz

2. Application: remote sensor • Periodic measurements • light, temperature, humidity • Data processed in the infrastructure • thin client model • communication is necessary • Participation in routing protocols • Unattended mode of operation

3. Platform: SmartDust • Low-power wireless communication • RFM TR1000 transceiver, bit-level interface • Range of digital and analog sensors • Light sensor - photo resistor • Temperature sensor - I2C interface • Low-power microcontroller • ATMEL AVR 90LS8535, Harvard architecture, 8KB program, 512 byte data

4. Mapping • TinyOS framework • software modules consisting of • event handlers • threads to perform arbitrary computation asynchronously • hardware abstraction or replacement • RFM bit-level interface • byte-level radio interface, similar to UART • active message-like communication scheme and execution model • Crucial resource: energy

5. Initial evaluation • Methodology: • logic analyzer timing diagrams • processor power consumption from datasheets • RFM power measurements • Wireless communication costs • 2.0 μJ/bit radio cost • software costs, going from bits to bytes: 690 nJ/bit • longest path through the time-critical code: 40 μs • communicating processor at 4MHz idle 50% of the time • radio draws constant power regardless of data rates

6. Experimental setup • Tools • HP 16550A logic analyzer • HP 16532A digital oscilloscope • 2.84V DC power supply • Current measurements • 10 Ohm 5% tolerance in series with mote • data point extraction from oscilloscope images • typical settings: 1 ms total interval analyzed, dynamic range: 160 mV • differential analysis to extract contributions of individual components • typical variation of successive experiments: 5%

7. Measurements AVR 90LS8535, 2.84 V@4MHz *memory instructions take 2 cycles

8. Exploration • Implications • current configuration: data rates up to 25Kbps or can reduce clock speed by a factor of 2 • dedicate a more sophisticated interface to the radio • speed up the transmission rate: transmit and turn off • Research question: • should we dedicate a separate microcontroller to each IO device? • Evaluate 2 processor system: • a processor dedicated to the radio • a processor dedicated to other sensors • UART communication between subsystems • scale frequency and voltage to minimize power usage

9. Methodology: Power aware simulator • ATMEL AVR instruction-set simulator • power-aware • incorporate the measurements from the real system • IO device simulation • timers, pins, and UART • use per cycle energy data from the real measurements • thread safe (need to simulate a multiprocessor system) • Communication system • Initially a UART evaluation • Shared memory models • TinyOS application • TinyOS naturally supports a multiprocessing environment • split the application at the byte-level radio

10. Results and conclusions • Simulator status • tested single processor configuration, agreement with empirical measurements • dual processor configuration in progress • Estimates • RFM processor - run at 2MHz, 5% idle, require 3mA current • Master processor - can run as slow as 200kHz, in order to handle peripherals • Inter-processor communication costs related to interconnect are small (cf. UART data) • Inter-processor communication costs related to software overhead are significant (interrupt handling, busy waiting or inability to power-down)

11. Acknowledgments • SmartDust members • Kris Pister, Seth Hollar • TinyOS (ASPLOS 2000 submission) • David Culler, Jason Hill, Rob Szewczyk, Alec Woo