1. Wireless Sensor Networks
Final Presentation
Ben Heruska
Michael Sabot
Group 8
ECE 4605
7 December 2006

2. Context of WSNs WSNs useful in a range of applications Limitations
Fires,medical,etc.
Limitations
Battery life
Responsiveness
Network capability
Our Environment
Mica2 motes – 900MHz
2 hop network

3. Problem Description Preliminary Goals Project Goals
Learn by Divide and Conquer
TinyOS, Mica2 (Crossbow), nesC
Install TinyOS, Program Mica2
Project Goals
Determine optimal sample rate using 2 hops
Program and implement event-driven architecture
** Simplified to Quasi-Event-Driven
Big Picture: Improve responsiveness and effectiveness of Wireless Sensor Network

4. Work Outline Setup Work Environment Discovered Optimal Sample Rate
Flash Programming the Motes
nesC Programming
Understanding the Surge Reliable code
Modifying the Surge Reliable Program

5. Work Done Installation Use of the Motes Setup Work Space
Install TinyOS and Cygwin
Use of the Motes
Learned to Upload Programs to Motes
Learned to Gather and process data from the motes

6. Work Done Flashing programs into the motes memory
Blink
Used to test mote programming
Surge Reliable
Multihop Routing
Discovered Optimal Sample Rate
Used Surge Reliable
Adjusted sample rate until network was unreliable

7. nesC C with tinyOS extensions
Provides modules that abstractly interface with mote hardware
Allows the “wiring” together of different components

8. Understanding the Surge Reliable Source Code
Provides mechanisms for collecting sensor data and transmitting it
Uses Crossbow’s modules to handle all I/O and routing functions automatically
Uses a timer based system to sample data.
Crossbow’s Multihop Routing, Broadcast, and Sensor modules

9. Modified Surge Code Created a partially event driven sensor network
Used a threshold value to decide if new data should be sent
if ((initalCount > 1)
|| ((gLight - oldLight) >= 5)
|| (oldlight - gLight) >= 5)){
oldLight = gLight;
if (initialCount >= 1)
initalCount--;
SEND DATA… }

10. Result Metric Definitions
Surge-View provided statistics/quality ratings
Quality, Yield, Prediction
Yield and Prediction not helpful
Quality inaccurate for low refresh rates
Next step: other metrics required
Our metrics used:
Time to connect (# of msgs, time)
Link Quality (from Surge_Reliable) at far node
Link Reliability (qualitative input)

11. Network Topology Modified Standard Surge_Reliable Mica2 hops
Base Node (always 0)

12. Results for Refresh Rate
Results of Test runs under similar conditions
(1) Nodes turned on immediately following program start
(2) Physical layout scheme the same
Note: # packets = how many until node showed up on Surge-View
Found: optimal sample(refresh) rate of 350ms

13. Quasi-Event-Driven Model
Definitions/Assumptions:
Ideal Event-Driven Network
All processes event driven
Small portion always running
wakes system up after event
Ours: Quasi-Event-Driven Network
Assumption: transmitting consumes the most power
All processes running
Transmission restricted to change in some value
Transmits initially, then tests sensor data against the last transmitted value to look for changes
In our setup, we used the Light field

14. Example Event-Driven All refresh rates set to 1 second
Initial Setup Completed
Quasi-Event Driven
All refresh rates set to 1 second
In this example, we would change values, then wait 5-15 seconds and change them again
Over 2.5 minutes, only 90 messages sent, saving 40% of transmissions

15. More Event-Driven Notes
Many problems due to Surge_Reliable
Connection delay caused problems with event-driven model – TCP-like connecting/handshaking
Limited to reducing total transmissions versus making it event-driven
Multitude of interfaces
Disabled us from editing core control structure
Instead we resorted to putting conditions on transmissions

16. Conclusions
Mote can transmit at a much higher rate than set by default
Pro: Provide better response
Con: Greatly reduced battery life
Event Driven model is effective
Pro: Near instantaneous response
Con: Surge Reliable implementation prevents good results

17. Future work Two Directions:
Better Event Driven Approach, Constant Slow transmission rate with immediate transmission of significant changes
Uses the current Surge Reliable implementation
Completely rewrite Surge to be truly event driven

18. Questions?