Sensor Network Programming - PowerPoint PPT Presentation


PPT – Sensor Network Programming PowerPoint presentation | free to view - id: 98670-MzUyZ


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Sensor Network Programming


Serial 'gateway' used to program and communicate with the motes. Cost $95. MPR400 ... Basic sensor board that plugs into the mote ... – PowerPoint PPT presentation

Number of Views:116
Avg rating:3.0/5.0
Slides: 26
Provided by: bib7


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Sensor Network Programming

Sensor Network Programming
  • Bibudh Lahiri

Todays Menu
  • Starter/ Beverages
  • What are sensor networks?
  • Applications
  • Main course
  • Characteristics
  • Platforms
  • Event-Driven Sensor Acquisition
  • Tasks and Hardware Event Handler
  • Dessert
  • What are we doing at Iowa State?

What is a Sensor Network?
  • A computer network consisting of spatially
    distributed autonomous devices using sensors to
    cooperatively monitor physical or environmental
    conditions, such as temperature, sound,
    vibration, pressure, motion or pollutants, at
    different locations

  • military applications such as battlefield
  • environment and habitat monitoring
  • home automation
  • traffic control

  • Limited power
  • Harsh environmental conditions
  • Node failures
  • Dynamic network topology
  • Large scale of deployment
  • Unattended operation

  • Hardware
  • MIB510
  • Serial "gateway" used to program and communicate
    with the motes
  • Cost 95
  • MPR400
  • More commonly known as the MICA2 Mote
  • 433 MHz motes get better range. Best for outdoor
  • Cost 150
  • MTS300
  • Basic sensor board that plugs into the mote
  • Contains light sensor, temperature sensor,
    microphone and sounder
  • Cost 120

Platforms (contd.)
  • Operating systems - TinyOS
  • An open-source, event-driven, component-based OS
    and platform targeting WSN
  • Written in the nesC programming language
  • A set of cooperating tasks and processes
  • Can operate within the severe memory constraints
    inherent in sensor networks

Platforms (contd.)
  • Software
  • nesC
  • primarily intended for embedded systems such as
    sensor networks
  • C-like syntax
  • supports the TinyOS concurrency model, as well as
    mechanisms for structuring, naming, and linking
    together software components into robust network
    embedded systems
  • applications are built out of components
  • Components
  • A component provides and uses interfaces
  • Two types of components - modules and

Platforms (contd.)
  • Interfaces
  • Commands
  • A set of functions declared by an interface
  • Interface provider must implement them
  • Events
  • a callback function that the implementation of an
    interface will invoke
  • A module that uses an interface must implement
    the events that this interface uses
  • Example
  • interface Timer
  • command result_t start (char type, uint32_t
  • command result_t stop()
  • event result_t fired()

Platforms (contd.)
  • Configuration
  • used to assemble other components together,
    connecting interfaces used by components to
    interfaces provided by others
  • Example
  • configuration Blink
  • implementation
  • components Main, BlinkM, SingleTimer, LedsC
  • Main.StdControl -gt SingleTimer.StdControl
  • Main.StdControl -gt BlinkM.StdControl
  • BlinkM.Timer -gt SingleTimer.Timer
  • BlinkM.Leds -gt LedsC

Platforms (contd.)
  • Configuration (contd.)
  • a configuration itself can use and provide
  • Example
  • configuration GenericComm
  • provides
  • interface StdControl as Control
  • // The interface are as parameterised by the
    active message id
  • interface SendMsguint8_t id
  • interface ReceiveMsguint8_t id
  • // How many packets were received in the past
  • command uint16_t activity()

Platforms (contd.)
  • Configuration (contd.)
  • uses
  • // signaled after every send
    completion for components which wish to
  • // retry failed sends
  • event result_t sendDone()
  • implementation
  • components AMStandard,…
  • Control AMStandard.Control
  • SendMsg AMStandard.SendMsg
  • ReceiveMsg AMStandard.ReceiveMsg
  • activity AMStandard.activity
  • sendDone AMStandard.sendDone

Platforms (contd.)
  • Modules
  • actually provides the implementation of the
  • module BlinkM
  • provides
  • interface StdControl
  • uses
  • interface Timer
  • interface Leds

Platforms (contd.)
  • Modules (contd.)
  • implementation
  • command result_t StdControl.init()
  • call Leds.init() //initializes
    variables in LedsC
  • return SUCCESS
  • command result_t StdControl.start()
  • return call Timer.start (TIMER_REPEAT,
  • command result_t StdControl.stop()
  • return call Timer.stop()

Platforms (contd.)
  • Modules (contd.)
  • event result_t Timer.fired()
  • call Leds.redToggle()
  • return SUCCESS

Event-Driven Sensor Acquisition
  • A simple sensor application that takes light
    intensity readings and displays
  • configuration Sense
  • implementation
  • components Main, SenseM, LedsC, TimerC, Photo
  • Main.StdControl -gt SenseM
  • Main.StdControl -gt TimerC
  • SenseM.ADC -gt Photo
  • SenseM.ADCControl -gt Photo
  • SenseM.Leds -gt LedsC
  • SenseM.Timer -gt TimerC.Timerunique("Timer")

Event-Driven Sensor Acquisition (contd.)
  • module SenseM
  • provides
  • interface StdControl
  • uses
  • interface Timer
  • interface ADC
  • interface StdControl as ADCControl
  • interface Leds
  • …

Event-Driven Sensor Acquisition (contd.)
  • implementation
  • …
  • event result_t Timer.fired()
  • return call ADC.getData()
  • async event result_t ADC.dataReady(uint16_t data)
  • //run in response to a hardware interrupt
  • display(7-((datagtgt7) 0x7)) //takes bits at
    position 7,8,9 to 14,15,16 respectively
  • return SUCCESS
  • Interfaces
  • ADC used to access data from the
    analogue-to-digital converter
  • StdControl used to initialize the ADC component

Event-Driven Sensor Acquisition (contd.)
  • Parameterized interfaces
  • SenseM.Timer -gt TimerC.Timerunique("Timer")
  • TimerC component declares
  • provides interface Timeruint8_t id

Tasks and Hardware Event Handler
  • Hardware Event Handler
  • async declares a command or event that can be
    executed by a hardware event handler
  • Could be executed at any time
  • Possibility of data races on all shared data
  • Tasks
  • Can be used to perform general-purpose
    "background" processing in an application
  • Usually longer jobs
  • Can be preempted by hardware event handler

Tasks and Hardware Event Handler (contd.)
  • Tasks (contd.)
  • A task is declared in the implementation module
    using the syntax
  • task void taskname() ...
  • To dispatch a task for (later) execution, use the
  • post taskname()

Tasks and Hardware Event Handler (contd.)
  • Tasks (contd.)
  • Example
  • async event result_t ADC.dataReady(uint16_t data)
  • putdata(data)     //insert a new sample into
    the buffer
  • post processData()    
  • return SUCCESS  
  • …
  • task void processData()    
  • int16_t i, sum0    
  • atomic    
  • for (i0 i lt size i)
  • sum (rdatai gtgt 7)
  • display(sum gtgt log2size)

What are we doing at Iowa State?
  • Implementation of Arrow protocol for tracking
    mobile objects
  • A directory service allows nodes to keep track of
    mobile objects
  • We are trying to ensure reliable communication
  • Challenge
  • Medium cannot be sensed to detect collision
    since this is a wireless medium
  • Any frame reaches all nodes in the neighborhood
    of the sender
  • Approach
  • Application-layer acknowledgements on reception
    of data
  • Retransmission by the sender if acknowledgement
    is not received within a specified time period
  • After maximum number of retransmissions, send the
    next frame

What are we doing at Iowa State? (contd.)
  • Implementation of Arrow protocol for tracking
    mobile objects (contd.)
  • Approach (contd.)
  • Sender keeps on sending a series of n (currently
    32) consecutive odd/even numbers starting from
    1/0 respectively. The format of the data frame is
  • Bit 1 - Frame type, 0 for data frame
  • Bits 2,3 - Node ID of the sender of the data
  • Bits 4-9 - Sequence no. of the frame
  • Bits 10-15 data
  • Bit 16 unused
  • Receiver keeps on receiving a series of n
    consecutive odd/even numbers sent by the sender
  • Maintains two sum variables as follows -
    rcvd_sum_of_odd and rcvd_sum_of_even
  • With receiving each message, the receiver will
    send an ACK frame to the corresponding sender.
    The format of the ACK frame is

What are we doing at Iowa State? (contd.)
  • Implementation of Arrow protocol for tracking
    mobile objects (contd.)
  • Approach (contd.)
  • Bit 1 - Frame type, 1 for ACK
  • Bits 2,3 - Node ID of the sender of the data
  • Bits 4-9 - Sequence no. of the frame
  • Bits 10-15 unused
  • At the end of sending n messages, rcvd_sum_of_odd
    should be equal to the sum of first
  • n odd integers, and rcvd_sum_of_even should
    be equal to the sum of first n even integers, if
    no messages are lost
  • post tasks to display rcvd_sum_of_odd modulo 7
    and rcvd_sum_of_even modulo 7 on receivers LEDs