1 / 34

TinyOS: Radio, Concurrent Execution, and P ower control

TinyOS: Radio, Concurrent Execution, and P ower control. Class 7. Announcements. Please email TA with group members It is necessary to distribute sensors to the groups Phase 1 for your group projects due on October 12 th . Requirements posted on the course webpage. Agenda. Review Quiz

zizi
Télécharger la présentation

TinyOS: Radio, Concurrent Execution, and P ower control

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. TinyOS: Radio, Concurrent Execution, and Power control Class 7

  2. Announcements • Please email TA with group members • It is necessary to distribute sensors to the groups • Phase 1 for your group projects due on October 12 th. • Requirements posted on the course webpage

  3. Agenda • Review Quiz • Implement a three bit counter • Radio module of TinyOS: Zigbee and Bluetooth • Concurrent execution: tasks and events • Power management • Communication scheduling

  4. Implementing a Radio in TinyOS • Different interfaces for Zigbee and bluetooth • In Zigbee – packet formation, radio buffer management has to be done by the user • More flexibility of design • In Bluetooth – The HPL abstraction for bluetooth abstracts out the packet details • Can create an array and send it via radio

  5. Zigbee interface #include "RadioSenseToLeds.h" module RadioSenseToLedsC { uses { interface Receive; interface AMSend; interface Packet; interface SplitControl as RadioControl; } } Declare the packet format Interface to Recieve Interface to Send Interface to build the packet Interface to start and stop a radio

  6. Packet Format #ifndef RADIO_SENSE_TO_LEDS_H #define RADIO_SENSE_TO_LEDS_H typedefnx_structradio_sense_msg { nx_uint16_t error; nx_uint16_t data; } radio_sense_msg_t; enum { AM_RADIO_SENSE_MSG = 7, }; #endif Structure of the packet with two variables Maximum Number of bytes in the packet

  7. Implementation implementation { message_t packet; bool locked = FALSE; event void Read.readDone(error_t result, uint16_t data) { if (locked) { return; } else { radio_sense_msg_t* rsm; rsm = (radio_sense_msg_t*)call Packet.getPayload(&packet, NULL); if (call Packet.maxPayloadLength() < sizeof(radio_sense_msg_t)) { return; } rsm->error = result; rsm->data = data; if (call AMSend.send(AM_BROADCAST_ADDR, &packet, sizeof(radio_sense_msg_t)) == SUCCESS) { locked = TRUE; } } } } TinyOS internal packet format Send command issues a SendDone event To check whether the radio is busy event void AMSend.sendDone(message_t* bufPtr, error_t error) { if (&packet == bufPtr) { locked = FALSE; } } Create your own packet Broadcast to everybody

  8. Reception of a packet event message_t* Receive.receive(message_t* bufPtr, void* payload, uint8_t len) { call Leds.led1Toggle(); if (len != sizeof(radio_sense_msg_t)) {return bufPtr;} else { radio_sense_msg_t* rsm = (radio_sense_msg_t*)payload; uint16_t val = rsm->data; return bufPtr; } } Cast it into your own packet format Use data for computation

  9. ZigBEE Wiring configuration RadioSenseToLedsAppC {} implementation { components ActiveMessageC; components new AMSenderC(AM_RADIO_SENSE_MSG); components new AMReceiverC(AM_RADIO_SENSE_MSG); App.Receive -> AMReceiverC; App.AMSend -> AMSenderC; App.RadioControl -> ActiveMessageC; App.Packet -> AMSenderC; } HPL for the radio Send and Receive components

  10. Bluetooth module RadioSenseToLedsC{ uses { interface Init as BluetoothInit; interface StdControl as BTStdControl; interface Bluetooth; } } Initiate bluetooth radio Starting and stopping Sending and recieving event void Boot.booted() { call BluetoothInit.init(); call Bluetooth.resetDefaults(); call Bluetooth.setRadioMode(SLAVE_MODE); call Bluetooth.setName("testUnit"); call BTStdControl.start(); } Master Slave Architecture

  11. Bluetooth Send and Recieve async event void Bluetooth.connectionMade(uint8_t status) { post startSensing(); } call Bluetooth.write(SendArray, 8); async event void Bluetooth.connectionClosed(uint8_t reason){ } async event void Bluetooth.dataAvailable(uint8_t data){ } event void Bluetooth.writeDone(){ } async event void Bluetooth.commandModeEnded() { } After bluetooth hand shaking This event is fired Send an array Closing of a bluetooth connection When data is available from The master On completion of a send When master has no more Data to transmit

  12. Bluetooth wiring components RovingNetworksC; AccelECGC.BluetoothInit -> RovingNetworksC.Init; AccelECGC.BTStdControl -> RovingNetworksC.StdControl; AccelECGC.Bluetooth -> RovingNetworksC;

  13. Concurrent execution • uint16_t Samples[SAMPLES]; • Uint16_t i = 0; • event void ReadStream.readDone(error_t ok, uint32_t SensedVal) { • if (ok == SUCCESS){ • i++; • Samples[i] = Val; • if(i == SAMPLES-1){ • i = 0; • post calculateAvg(); • } • } • } • task void calculateAvg() { • uint16_t i, avg, var; • for (avg = 0, i = 0; i < SAMPLES; i++) • avg += Samples[i]; • avg /= SAMPLES; • for (var = 0, i = 0; i < SAMPLES; i++) • { • int16_t diff = Samples[i] - avg; • var += diff * diff; • } • } In readDone, we need to compute the variance of the sample. We defer this “computationally-intensive” operation to a separate task, using post. We then compute the variance

  14. Exercise to understand concurrency Lets have a loop in a task Increment a counter Have a timer fired event where at each fired event we send the counter value to the base station What values do we see at the base station ?

  15. Using Low-power Listening module RadioSenseToLeds... uses interface RadioControl; uses interface LowPowerListening; ... event void RadioControl.startDone(error_t ok) { if (ok == SUCCESS) { call CollectionControl.start(); call LowPowerListening.setLocalDutyCycle(200); } } TinyOS supports power control of the Radio What is power management ? Why is it required ? We request that the radio use a 2% duty-cycle low-power listening strategy We wire the interface to the actual radio (not shown)

  16. Power Management

  17. Sources of Power Dissipation Often more than computation Least Power consuming Most Power consuming Power consumption depends on the type of processing Sending < Receiving Communication energy more than 100 times greater than computation energy Sensing + Computation + Communication

  18. Communication Duty Cycling Ayushman Workload Frequency Throttling during security phase Sensing Phase Enables Sleep Scheduling Transmission Phase Sleep Cycle Sensor CPU Utilization Security Phase Time • Low power listening for Radio • Radio turn off • Such strategies are however application dependent • Cannot turn off radio when the sensor needs to send • When an event occurs the radio has to wake up from low power state • Example: Ayushman health monitoring application is considered as the workload • Sensing Phase – Sensing of physiological values (Plethysmogram signals) from the sensors and storing it in the local memory • Transmission Phase – Send the stored data to the base station in a single burst • Security Phase – Perform network wide key agreement for secure inter-sensor. • The Security phase occurs once in a day • The Sensing phase and Transmission phase alternate forming a sleep cycle

  19. Effects of Power Management Power Profile (Radio-ON) 0.06 0.05 Receiver(Radio ON) 0.04 Sender(Radio ON) 0.03 0.02 0.01 1 2 3 4 5 6 7 Lagrangian 8 9 Poly Gen + Vault Tx/Rx FFT Peak + Quant Ackn Tx/Rx Sensing Add Chaff Interpolation Eval Power Profile (Radio-OFF) 0.06 Receiver(Radio OFF) 0.05 Sender(Radio OFF) 0.04 Power (mW) 0.03 0.02 0.01 0 1 2 3 4 5 6 7 8 9 FFT Peak + Quant Sensing Add Chaff Vault Tx/Rx Lagrangian Poly Gen + Ackn Tx/Rx Interpolation Eval • Periodic sensing and computation application in Ayushman • Sender Side: Sensing + FFT + peak detection + quantization + polynomial evaluation + random number (chaff) generation + data transmission + acknowledgement of transmission • Receiver Side: Sensing + FFT + peak detection + quantization + listen for packet + interpolation + transmit acknowledgement

  20. Reduction of data transmission • To further reduce communication power we may avoid data transmission • Event based data transmission • Example: • Physiological data transmission (ECG) • When ECG is normal and not changing don’t send samples • On any expected change, send only the changed feature • When an unexpected change occurs, default to periodic sending of data • How to know what is normal ? • What are expected changes ? • What is an unexpected behavior ?

  21. Electrocardiogram (ECG) • Represents electrical activity of the heart • Consists of P, Q, R, S, T waves • The beat morphology and R-R intervals in an ECG are considered important for diagnosis • Visual representation is preferred by physicians

  22. Diagnostic Features of ECG R-R interval hR hQ hS • Beat Morphology: • Refers to visual appearance of an ECG beat • Includes height, width, location and shape of peaks • R-R intervals: • Heart rate (HR) = 1/(R-R interval) • HR varies over time, and is characterized using mean(HR), std(HR) and frequency domain parameter LF/HF ratio. • These are called inter-beat features.

  23. Normal, Expected and Unexpected Normal Expected Change Unexpected Change Morphology and inter beat features do not change Both morphology and inter beat features change Only inter beat features change No communication Use a generative model to represent ECG Send inter beat feature updates Send every sample

  24. Generative Models G Input Parameters Output signal Time Mathematical model to generate data from given input parameters Used in music, machine learning, wireless sensor networks and other areas Input parameters can be trained on given data Used for generating ECG in GeM-REM.

  25. ECGSYN Model for ECG When using models exact sample to sample match is not possible We aim for diagnostic equivalence • Generative model for ECG, proposed by McSharry et al. • Each of P, Q, R, S, and T waves are represented by Gaussians • Input parameters: • Inter-beat: {hrmean, hrstd, lfhfratio} • Correspond to mean heart rate, standard deviation of heart rate and LF/HF ratio respectively. • Morphology: {aQ, bQ, ƟQ,aR, bR, ƟR, aS, bS, ƟS} • ai, bi, Ɵidetermine the height, width and location of peak i. • Require curve fitting to learn from a given raw ECG.

  26. Diagnostically Equivalent ECG ECG from MIT-BIH database Synthetic ECG waveform from ECGSYN • Two ECGs are diagnostically equivalent if: • Beat morphologies match • Inter-beat features are equal

  27. GeM-REM: Initialization Model Learner G ECG Leads Sensed ECG G Sensor Platform Base Station Base Station Module MBS Mobile phone gateway Sensor Module MLITE • Architecture: Sensor module (MLITE) and Base station module (MBS) • Initialization: • Train G using Model Learner function in MBS • Use patient’s real ECG as training data • Store trained G in MBS and MLITE

  28. GeM-REM: Regular Operation Feature updates Sensed ECG G Output ECG Match? Compare Align Raw ECG samples G Raw signal updates MLITE MBS • Two types of updates: • Feature update: Single parameter value corresponding to feature of sensed ECG • Raw Signal update: Samples of sensed ECG signal • Sensor compares sensed ECG to output of G • If (Signals match within threshold) Store signal in terms of model parameters Else Send updates to base station

  29. Sensor Module MLITE Sensed ECG Inter-beat feature comparison Diff > threshold Transmit value Pre- process Generated ECG MSE > threshold Transmit raw data G Direct signal comparison Pre-processing includes filtering, scaling and peak detection Morphology compared through mean squared error (MSE) between sensed and model-generated ECG Threshold values set by physician a priori or during regular operation

  30. Base Station Module MBS Raw signal updates Feature updates Sensed ECG G Model Learner Raw ECG samples G Temporal alignment Output ECG Align Model-generated ECG Compare Match? G Feature updates Raw ECG samples Final Output Raw signal updates MLITE MBS Feature updates used to update inputs of G Raw signal updates used as true ECG of patient Signals aligned using timestamps Raw signal used to re-train G.

  31. Experimental Results • Evaluation Criteria: • Feasibility of GeM-REM: TelosB, SHIMMER • Diagnostic Accuracy of reported ECG • Energy and memory savings • Data: • MIT-BIH database • 30 patients’ data, sampled at 250 Hz • Implementation: • MLITE in TinyOS, MBS in MATLAB

  32. Performance of GeM-REM Raw Signal Updates Feature Updates (Results for all schemes are based on data from MIT-BIH database) • Compression Ratio: • Performance vs. thresholds • Comparison to state of the art • Memory savings of 37.3:1 • Criticialevent detection • Detected within 5 sec. through morphology comparison.

  33. Demo Video http://www.youtube.com/watch?v=NGBq-oyPhGI&feature=channel_video_title

  34. Lessons Learned • Communication more expensive than computation • Communication duty cycling is an useful tool • Application dependent duty cycling • Event based communication enables lot of energy savings • Can only be applied to cases where the sensed signal has a definite pattern • Next Class – • Energy savings in computation

More Related