Spring 2000, 4/27/00 Power evaluation of SmartDust remote sensors CS 252 Project Presentation Robert Szewczyk Andras Ferencz

Spring 2000, 4/27/00 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

Spring 2000, 4/27/00 Platform: SmartDust Low-power wireless communication –RFM TR1000 transceiver, bit-level interface Range of digital and analog sensors –Light sensor - photo resistor –Temperature sensor - I 2 C interface Low-power microcontroller –ATMEL AVR 90LS8535, Harvard architecture, 8KB program, 512 byte data

Spring 2000, 4/27/00 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

Spring 2000, 4/27/00 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

Spring 2000, 4/27/00 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%

Spring 2000, 4/27/00 Measurements Instruction type Energy per cycle (nJ) Energy per instr (nJ) idle1.70 noop3.39 arithmetic/ logic 3.41 memory read* memory write* DeviceEnergy per CPU cycle Energy per quantum LED1.89 nJ/cycle Photo nJ/cycle ADC nJ/conversion RMF send 100 μs pulse nJ/bit RFM receive nJ/bit AVR 90LS8535, 2.84 *memory instructions take 2 cycles

Spring 2000, 4/27/00 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

Spring 2000, 4/27/00 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

Spring 2000, 4/27/00 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)

Spring 2000, 4/27/00 Acknowledgments SmartDust members –Kris Pister, Seth Hollar TinyOS (ASPLOS 2000 submission) –David Culler, Jason Hill, Rob Szewczyk, Alec Woo