Part II: Platforms, Energy and OS - PowerPoint PPT Presentation

Part ii platforms energy and os l.jpg
Download
1 / 34

Part II: Platforms, Energy and OS Outline Platforms Energy consumptions TinyOs Sensor Platforms (Processing) Crossbow mote family IRIS, MICAz, MICA2 , Imote2, TelosB, Cricket Module Sun Spots UCLA iBadge MIT’s  AMPs Many more others RSC WINS & Hidra Sensoria WINS

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Part II: Platforms, Energy and OS

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Part ii platforms energy and os l.jpg

Part II: Platforms, Energy and OS


Outline l.jpg

Outline

Platforms

Energy consumptions

TinyOs


Sensor platforms processing l.jpg

Sensor Platforms (Processing)

  • Crossbow mote family

    • IRIS, MICAz, MICA2 , Imote2, TelosB, Cricket Module

  • Sun Spots

  • UCLA iBadge

  • MIT’s AMPs

  • Many more others

    • RSC WINS & Hidra Sensoria WINS

    • UCLA’s Medusa MK-II


Platform examples l.jpg

Platform Examples

Cricket

IRIS

MicaZ

Sun Spots

Mica2

TelosB

Imote2


Mica2 characteristics l.jpg

Mica2 Characteristics

Mica2


Micaz l.jpg

MicaZ

MicaZ


Telosb characteristics l.jpg

TelosB Characteristics

TelosB


Imote2 characteristics l.jpg

Imote2 Characteristics

Imote2


Iris characteristics l.jpg

IRIS Characteristics

IRIS


Important differences between platform l.jpg

Important Differences between Platform


Sensor boards l.jpg

Sensor Boards

Ambient light, Temperature

Accelerometer (2 Axis, 3Axis)

Barometric pressure

GPS

Magnetic field

Microphone

Photo-sensitive light

Photoresistor, thermistor sensor

And many others…


Outline12 l.jpg

Outline

Platforms

Energy consumptions

TinyOs


Where does the energy go l.jpg

Where Does the Energy Go?

  • Processing

    • excluding low-level processing for radio, sensors, actuators

  • Radio

  • Sensors

  • Actuators

  • Power supply


Processing l.jpg

Processing

  • Common sensor node processors:

    • Atmel AVR, Intel 8051, StrongARM, XScale, ARM Thumb

  • Power consumption all over the map, e.g.

    • 16.5 mW for ATMega128L @ 4MHz

    • 75 mW for ARM Thumb @ 40 MHz

  • Low-power ≠ energy-efficiency!

    • 242 MIPS/W for ATMega128L @ 4MHz (4nJ/Instruction)

    • 480 MIPS/W for ARM Thumb @ 40 MHz (2.1 nJ/Instruction)

  • Power management to exploit energy efficiency

    • Idle and sleep modes, variable voltage and frequency

II-14


Radio l.jpg

Radio

Energy per bit in radios is a strong function of desired communication performance and choice of modulation

Range and BER for given channel condition (noise, multipath and Doppler fading)

Watch out: different people count energy differently

Mote’s RFM radio is only a transceiver, and a lot of low-level processing takes place in the main CPU

While, typical 802.11b radios do everything up to MAC and link level encryption in the “radio”

Transmit, receive, idle, and sleep modes

Variable modulation, coding

Currently around 150 nJ/bit for short ranges

More later…

II-15


Computation communication l.jpg

Computation & Communication

Radios benefit less from technology improvements than processors

The relative impact of the communication subsystem on the system energy consumption will grow

Energy breakdown for MPEG

Energy breakdown for voice

Decode

Decode

Transmit

Encode

Encode

Receive

Receive

Transmit

Processor: StrongARM SA-1100 at 150 MIPS

Radio: Lucent WaveLAN at 2 Mbps

II-16


Sensing l.jpg

Sensing

Several energy consumption sources

transducer

front-end processing and signal conditioning

analog, digital

ADC conversion

Diversity of sensors: no general conclusions can be drawn

Low-power modalities

Temperature, light, accelerometer

Medium-power modalities

Acoustic, magnetic

High-power modalities

Image, video, beam forming

II-17


Actuation l.jpg

Actuation

  • Emerging sensor platforms

    • Mounted on mobile robots

    • Antennas or sensors that can be actuated

  • Some thoughts:

    • Actuation often done with fuel, which has much higher energy density than batteries

      • E.g. anecdotal evidence that in some UAVs the flight time is longer than the up time of the wireless camera mounted on it

    • Actuation done during boot-up or once in a while may have significant payoffs

      • E.g. mechanically repositioning the antenna once may be better than paying higher communication energy cost for all subsequent packets

      • E.g. moving a few nodes may result in a more uniform distribution of node, and thus longer system lifetime

II-18


Radio energy management l.jpg

Radio Energy Management

During operation, the required performance is often less than the peak performance the radio is designed for

Leading to duty-cycle

Tx

Rx

?

?

time

II-19


Energy in radio the deeper story l.jpg

Energy in Radio: the Deeper Story….

Wireless communication subsystem consists of three components with substantially different characteristics

Their relative importance depends on the transmission range of the radio

Tx: Sender

Rx: Receiver

Incoming

information

Outgoing

information

Channel

Power amplifier

Transmit electronics

Receive electronics

II-20


Examples l.jpg

Examples

Nokia C021 Wireless LAN

Medusa Sensor Node (UCLA)

GSM

nJ/bit

nJ/bit

nJ/bit

~ 50 m

~ 10 m

~ 1 km

  • The RF energy increases with transmission range

  • The electronics energy for transmit and receive are typically comparable

II-21


Energy consumption of the sender l.jpg

Energy Consumption of the Sender

Parameter of interest:

energy consumption per bit

Tx: Sender

Incoming

information

RFDominates

Electronics Dominates

Energy

Energy

Energy

Transmission time

Transmission time

Transmission time

II-22


Outline23 l.jpg

Outline

Platforms

Energy consumptions

TinyOs


Tinyos overview l.jpg

TinyOS Overview

Application = scheduler + graph of components

Compiled into one executable

Event-driven architecture

Single shared stack

No kernel/user space differentiation

Main (includes Scheduler)

Application (User Components)

Actuating

Sensing

Communication

Communication

Hardware Abstractions


Tinyos component model l.jpg

TinyOS Component Model

Component has:

Frame (storage)

Tasks: computation

Interface:

Command

Event

Frame: static storage model - compile time memory allocation (efficiency)

Command and events are function calls (efficiency)

Messaging Component

Internal State

Internal Tasks

Commands

Events


Tinyos two level scheduling l.jpg

TinyOS Two-level Scheduling

Tasks do computations

Unpreemptable FIFO scheduling

Bounded number of pending tasks

Events handle concurrent dataflows

Interrupts trigger lowest level events

Events prempt tasks, tasks do not

Events can signal events, call commands, or post tasks

Tasks

Preempt

POST

FIFO

events

commands

commands

Interrupts

Time

Hardware


How to handle multiple data flows l.jpg

How to Handle Multiple Data Flows?

Data are handled by

A sequence of non-blocking event/command (function calls) through the component graph

Post tasks for computations that are not “emergent”

Preempting tasks to handle new data

http://tinyos.millennium.berkeley.edu


A complete application l.jpg

A Complete Application

sensing application

application

Routing Layer

routing

Messaging Layer

messaging

Radio Packet

packet

Radio byte (MAC)

Temp

byte

photo

SW

HW

RFM

ADC

i2c

bit

clocks


Receiving a message l.jpg

Receiving a Message

Timing diagram of event propagation

How to make sure all the events/tasks are processed in time?


Handling network messages l.jpg

Handling Network Messages

Socket/TCP/IP?

Too much memory for buffering and threads

Data are buffered in network stack until application threads read it

Application threads blocked until data is available

Transmit too many bits (sequence #, ack, re-transmission)

Tied with multi-threaded architecture

TinyOS solution: active messages

http://tinyos.millennium.berkeley.edu


Active message l.jpg

Active Message

Every message contains the name of an event handler

Sender

Declaring buffer storage in a frame

Naming a handler

Requesting Transmission

Done completion signal

Receiver

The event handler is fired automatically in a target node

No blocked or waiting threads on the receiver

Behaves like any other events

Single buffering

http://tinyos.millennium.berkeley.edu


Power breakdown l.jpg

Power Breakdown…

Lithium Battery runs for 35 hours at peak load and years at minimum load!

That’s three orders of magnitude difference!

A one byte transmission uses the same energy as approx 11000 cycles of computation.

Panasonic CR2354 560 mAh

http://tinyos.millennium.berkeley.edu


Time breakdown l.jpg

Time Breakdown…

50 cycle thread overhead (6 byte copies)

10 cycle event overhead (1.25 byte copes)

Components

Packet reception work breakdown

CPU Utilization

Energy (nj/Bit)

AM

0.05%

0.20%

0.33

Packet

1.12%

0.51%

7.58

Ratio handler

26.87%

12.16%

182.38

Radio decode thread

5.48%

2.48%

37.2

RFM

66.48%

30.08%

451.17

Radio Reception

-

-

1350

Idle

-

54.75%

-

Total

100.00%

100.00%

2028.66

http://tinyos.millennium.berkeley.edu


Grading tinyos l.jpg

Grading TinyOS

Small memory footprint

Non-preemptable FIFO task scheduling

Power efficient 

Put microcontroller and radio to sleep

Efficient modularity 

Function call (event, command) interface between components

Concurrency-intensive operations 

Event-driven architecture

Efficient interrupts/events handling (function calls, no user/kernel boundary)

Real-time 

Non-preemptable FIFO task scheduling

NO real-time guarantees or overload protection

http://tinyos.millennium.berkeley.edu


  • Login