Übung zu Drahtlose Kommunikation

(1)

Übung zu

Drahtlose Kommunikation

11. Übung

21.01.2012

(2)

Organisation

• Klausurtermin:

Dienstag, 05.02.2013, 16 (c.t.) Uhr, Raum E 314

(zur Vorlesungszeit):

• Anmeldung über

KLIPS-Prüfungsverwaltungsmenü

• bis nächsten Montag, 28.01.2013

• Rücktritt bis 04.02.2013

(3)

Aufgabe 1

a) Gegeben ist eine Mignon-Batterie mit 1,5 V und 2400 mAh.

Berechnen Sie wie lange mit dieser Batterie ein Gerät betrieben werden, das 1,2 Watt benötigt?

Verbrauch: 1,5 V x 2,4 Ah = 3,6 Wh Laufzeit: 3,6Wh/1,2 W = 3h

11. Übung – Drahtlose Kommunikation 3

(4)

Aufgabe 1

b) Gegeben ist ein Tmote Sky Knoten mit folgenden Eigenschaften:

• 60 μA im idle-Modus

• 1800 μA wenn Microcontroller Unit (MCU) aktiv, aber ohne senden

• 19,5 mA für das Senden von Daten

• 21,8 mA für den Empfang von Daten

• Knoten wird mit 2 in Serie geschalteten Mignon-Batterien AA betrieben.

• Jede Batterie besitzt 1,5 V und 2400 mAh.

Wie lange können die Batterien den Knoten in Betrieb halten, wenn er

• in 60% der Laufzeit im idle-Modus ist

• in der Hälfte der restlichen Zeit zu gleichen Teilen Daten gesendet und empfangen werden?

(5)

Aufgabe 1

b) Tmote Sky Knoten (Datasheet)

The module was designed to fit the two AA battery form factor. AA cells may be used in the operating range of 2.1 to 3.6V DC,

however the voltage must be at least 2.7V when programming the microcontroller flash or external flash.

The mote operating voltage when attached to USB is 3V.

The 16-pin expansion connector (described in the Section on page 17) can provide power to the module. Any of the battery terminal connections may also provide power to the module.

At no point should the input voltage exceed 3.6V—doing so may damage the microcontroller, radio, or other components.

http://www.snm.ethz.ch/snmwiki/pub/uploads/Projects/tmote_sky_datasheet.pdf

(6)

Aufgabe 1

Serieschaltung von vier Zellen

Das Zuschalten von Zellen in einer Kette erhöht die Spannung,

aber der Strom bleibt gleich.

Serieschaltung mit einer fehlerhaften Zelle Die fehlerhafte Zelle Nr. 3 führt zu einer kleineren Gesamt-spannung von 4,2V, was zum Abschalten des Gerätes führt.

http://batteryuniversity.com/partone-24-german.htm

(7)

Aufgabe 1

• idle-Modus 60 μA

• MCU (ohne Transmitter) 1800 μA,

• Senden 19,5 mA

• Empfangen 21,8 mA

• 2x Batterien à 1,5 V und 2400 mAh

-> in Serie geschaltet 3 V und 2400 mAh

Laufzeit bei 60% idle Modus + 20% MCU aktiv + 10% Senden + 10% Empfangen!

Verbrauch = 0,6 x0,06mA + 0,2x1,8mA + 0,1x19,5mA + 0,1x21,8mA = 4,526mA

Laufzeit = 2400mAh / 4,526 mA = 530h => 22 Tage + 2 Stunden

(8)

Aufgabe 1

Parallelschaltung von vier Zellen

Mit parallelen Zellen bleibt die Spannung dieselbe, aber der abgegebene Strom und die Einsatzzeit sind größer.

Parallelschaltung mit einer fehlerhaften Zelle

Eine schwache Zelle beeinflusst die Spannung nicht, ergibt aber eine kürzere Einsatzzeit. Eine

kurzgeschlossene Zelle kann eine zu starke Erhitzung bewirken; die Batterie kann sich entzünden

http://batteryuniversity.com/partone-24-german.htm

(9)

Aufgabe 1

• idle-Modus 60 μA

• MCU (ohne transmitter) 1800 μA,

• Senden 19,5 mA

• Empfangen 21,8 mA

• 2x Batterien à 1,5 V und 2400 mAh

-> parallel geschaltet 1,5 V und 4800 mAh

Laufzeit bei 60% idle Modus + 20% MCU aktiv + 10% Senden + 10% Empfangen!

Verbrauch = 0,6 x 0,06mA + 0,2 x1,8mA + 0,1 x 19,5mA + 0,1 x 21,8mA Verbrauch = 4,526 mA

Laufzeit = 4800mAh / 4,526 mA = 1061 => 44 Tage + 5 Stunden (!!! Bei Tmote Sky Knoten -> supply voltage -> min 2,1 V)

(10)

Aufgabe 2

a) Was ist der Hauptunterschied zwischen einer „Component“ in TinyOS und einem Prozess in Linux?

Traditionelle OS: Prozess/Threads

- Basieren auf interrupts, Kontextwechsel - Aber: nicht verfügbar –

Speicheroverhead, Zeitoverhead

Aber: Nebenläufigkeit

- Ein Prozess pro Protokoll führt zu vielen Kontextwechsel.

- Viele Aufgaben sind zu klein im Verhältnis zum Overhead beim Kontextwechsel.

Und: Speicherschutz zwischen verschiedenen Prozessen wird nicht benötigt -> Es läuft nur eine Anwendung

Handle sensor process

Handle packet process

OS-mediated process switching

(11)

11

Aufgabe 2 - ereignisgesteuerte Nebenläufigkeit

• Alternativ: event-based programming model

– reguläre Verarbeitung oder Leerlauf (nichts Verarbeiten) – sofortige Reaktion auf Ereignisse wenn sie auftreten.

-> Interrupt Handler

• Problem: nicht zu lange im Interrupt Handler verharren

– Gefahr des Verlustes von Ereignissen

– Daten speichern -> weitergeben von Informationen des Ereignisses -> return – ! Run-to-completion Prinzip

– Wechsel zwischen zwei Kontexten: Handler + reguläre Ausführung

I d l e / R e g u l a r p r o c e s s i n g

R a d i o e v e n t

R a d i o e v e n t h a n d l e r S e n s o r

e v e n t

S e n s o r e v e n t h a n d l e r

(12)

Aufgabe 2

a) Was ist der Hauptunterschied zwischen einer „Component“ in TinyOS und einem Prozess in Linux?

Eine Abstraktion wird benötigt um Funktionalität zu gruppieren:

- Zu diesem Zweck wird der Prozess ersetzt

- z.B. Individuelle Funktionen eines Netzwerk Protokolls

Ein Möglichkeit: „Component“

- im Sinne von TinyOS:

- Nur eine einzige, wohl-definierte Funktion ausführen.

- Hauptunterschied zu Prozessen:

- Eine „Component“ wird nicht ausgeführt.

- Components greifen auf den selben Adressraum zu, - kein Schutz gegeneinander

- (Nicht zu verwechseln mit „component-based“ programming!)

(13)

Aufgabe 2

Was ist der Hauptunterschied zwischen einer „Component“ in TinyOS und einer Klasse in Java (Object)?

• Von einer „Component“ existiert genau eine Instance. Selbst wenn sie mehrfach benutzt wird.

• Ein Klasse kann eine beliebig viele Instanzen existieren.

• Die Philosophie von TinyOS ist, dass eine „Component“ gewöhnlich existierende Hardware repräsentiert (z.B. sollte es eine

„Component“ für den Zugriff auf einen Sensor geben).

• Umgekehrt sollte Hardware genau eine „Component“ besitzen.

• Für Fälle in denen mehrere Instanzen benötigt werden gibt es die

„generic component“

(14)

Aufgabe 2

b) Welche Typen von „Components“ sind in nesC/TinyOS definiert?

Module -> enthalten den implementierten Code

Configuration -> verbinden verschiedene „Components“ (wire)

Eine Anwendung ist mit einer einzigen Top-Level Configuration definiert.

module TimerM { provides {

interface StdControl;

interface Timer;

}

uses interface Clock;

}

implementation {

command result_t Timer.start(char type, uint32_t interval){

...

}

command result_t Timer.stop() { ... } event void Clock.tick() { ... }

}

(15)

15

Aufgabe 2

b) Welche Typen von „Components“ sind in nesC/TinyOS definiert?

• Components

– Frame – state information

– Tasks – normal execution program – Command handlers

– Event handlers

• Handlers

– Must run to completion

– Form a component’s interface – Understand and emits

commands & events

• Hierarchically arranged

– Events pass upward from

hardware to higher-level components – Commands are passed downward

TimerComponent

setRate fire

init start stop fired

Event handlers Command

handlers Frame

Tasks

(16)

Aufgabe 2

„Compenents“ können zu „Supercomponents“ zusammengefasst werden.

configuration TimerC { provides {

interface StdControl;

interface Timer;

} }

implementation {

components TimerM, HWClock;

// Pass-through: Connect our "provides" to TimerM "provides"

StdControl = TimerM.StdControl;

Timer = TimerM.Timer;

// Normal wiring: Connect "requires" to "provides"

TimerM.Clock -> HWClock.Clock;

}

(17)

Aufgabe 2

c) Was ist der Hauptunterschied zwischen einer „task“ in TinyOS und einem „handler“?

•

Handlers und Events müssen komplett bearbeitet werden (run-to-completion)

–

müssen bearbeitet werden, wenn sie auftreten

–

nur eine Anfrage um die Handlung durchzuführen

• Tasks dürfen eine willkürliche lange Rechenzeit benötigen.

–

Unterliegen ebenfalls dem run-to-completion Prinzip, da kein kooperatives Multi-tasking implementiert ist.

–

Task können aber durch Handler unterbrochen werden.

–

Tasks sind atomar gegenüber anderen Tasks, aber nicht gegenüber Hardware Event Handler.

(18)

Aufgabe 2

d) Sind die „event handler“ der Timer synchron oder asynchron? Welche Auswirkungen hat die Laufzeit eines „task“ auf die Timer?

• Commands and event handlers normally run in synchronous context

• Thus, while a task is running, no timers can be fired. If a task blocks the CPU for a long time, all timers that are due during the execution will be fired late.

• TinyOS provides a two-level scheduling hierarchy consisting of tasks/event handler and hardware event handlers (interrupt handlers)!

• the keyword async declares a command or event that can be executed by a hardware event handler.

• Means -> it could be executed at any time (preempting other code),

-> So async commands and events should do small amounts of work and complete quickly.

• you should pay attention to the possibility of data races on all shared data accessed by an async command or event.

• Tasks are used to perform longer processing operations, such as background data processing, and can be preempted by hardware event handler.

(19)

Aufgabe 3

a) Im BlinkToRadio Beispiel wird ein busy-Flag genutzt um zu signalisieren, dass das Sende-Interface beschäftigt ist. Wieso

genügt dieser Mechanismus ohne auf wechselseitigen Ausschluss („mutual exclusion“) achten zu müssen?

TinyOS unterbricht für gewöhnlich keine laufenden Event-Handler -> run-to-completion Prinzip

Tasks könnten durch Handler unterbrochen werden, aber nicht durch andere Tasks.

(20)

Aufgabe 3

busy will be set if the radio interface is currently active and no further packet can be sent.

event void Timer0.fired() { counter++;

if (!busy) {

BlinkToRadioMsg* btrpkt =(BlinkToRadioMsg*)

(call Packet.getPayload(&pkt,sizeof(BlinkToRadioMsg)));

if (btrpkt == NULL) { return; }

btrpkt->nodeid = TOS_NODE_ID;

btrpkt->counter = counter;

if (call AMSend.send(AM_BROADCAST_ADDR, &pkt,

sizeof(BlinkToRadioMsg)) == SUCCESS) { busy = TRUE;

} }

}

event void AMSend.sendDone(message_t* msg, error_t err) { if (&pkt == msg) {

busy = FALSE; } }

(21)

Aufgabe 3

b) Broadcast & Unicast-Messages

Gegenwärtig werden Broadcast Nachrichten an alle Knoten in Reichweite verschickt.

Erweitern Sie das BlinkToRadio Beispiel um Unicast-Nachrichten, die nur vom Nachbarn mit der entsprechenden ID empfangen werden können.

make telosb reinstall.NODE_ID bsl,/dev/tty/USB0

call AMSend.send(AM_BROADCAST_ADDR, &pkt, sizeof(BlinkToRadioMsg)) call AMSend.send(NODE_ID, &pkt, sizeof(BlinkToRadioMsg))

(22)

TinyOS – TmoteSky – Power Management

Makefile:

COMPONENT=BlinkToRadioAppC CFAGS+=-DCC2420_DEF_RFPOWER=1 include $(MAKERULES)

Set the Power-Level:

CFAGS+=-DCC2420_DEF_RFPOWER=3 -> -25 dBM CFAGS+=-DCC2420_DEF_RFPOWER=31 -> 0 dBM

http://inst.eecs.berkeley.edu/~cs150/Documents/CC2420.pdf

(23)

Tmote Sky & Tiny OS

Überprüfen der Systemumgebung:

$ tos-check-env

$ printenv MAKERULES

/opt/tinyos-2.x/support/make/Makerules

$ motelist

wcu@wcu-desktop:~$ motelist

Reference Device Description

--- --- --- M4AMMD4W /dev/ttyUSB0 Moteiv tmote sky

wcu@wcu-desktop:~$

23 10. Übung – Drahtlose Kommunikation

(24)

Tiny OS – einfaches Programm

$ motelist

wcu@wcu-desktop:~$ motelist

Reference Device Description

--- --- --- M4AMMD4W /dev/ttyUSB0 Moteiv tmote sky

wcu@wcu-desktop:~$

$ make telosb reinstall bsl,/dev/ttyUSB0

(25)

Tmote Sky & Tiny OS

Receiving a Message over the Radio 8. Test your application!

$ motelist

$ make telosb reinstall bsl,/dev/ttyUSB0

$ make telosb reinstall bsl,/dev/tty/USB1

25 10. Übung – Drahtlose Kommunikation