1. Wireless Sensor Networks
Please look at the notes section for each slide for further information
Group 6
John Paul Kalapurakal
Ronak Kamdar

2. Background/Motivation
Wireless network consisting of sensors to cooperatively monitor physical or environmental conditions such as temperature, light, sound , etc.
Limited computational power and memory for each node.
Tradeoff between energy drain and reporting rate.
To increase the life of each node by decreasing battery drain through event driven reporting.
Software/Hardware Used:
Tiny OS
Cygwin
Mica2 motes
MIB 510
1. We looked through what we learnt in class about sensor networks and did some additional background research using

3. SOFTWARE TinyOS Cygwin
Open source component-based OS and platform targeting wireless sensor networks
TinyOS applications are written in nesC
Cygwin
Allow various versions of Microsoft windows to act similar to a Unix system
Similar to command prompt
Did some background research for TinyOS by going through the TinyOS website:
2. Used the users manual to install TinyOS on a windows based machine
3. Used the Cygwin website: for installation information.

4. HARDWARE
1. Used the data sheets for the above components from the Crossbow website: to learn the functions and specification of each component.

5. Milestones 1. Setup a test-bed and implement Surge Application
2. Manipulate environment to detect changes in sensed reading, collect and display changes
3.Measure highest reporting rate possible and corresponding energy drain
4.Algorithm development - "event driven" mode instead of continuous reporting (polling based setup)
5.Implementation of solution
1. Understanding the scope of each milestone was an important task of the project

6. TEST BED LAYOUT Our setup of the test bed
1. Using a serial port there is a connection from the computer to the MIB510
2. MICA2 motes with the MTS310 sensor board mounted on it are programmed and set close to the base station.
3. Figured how the communication works between the various parts of the test bed
•Base sensor
–periodically broadcasts route updates
•Any sensor in range of this broadcast
–record the identity of the base station
–re-broadcast the update
•Each sensor
–remembers the first update received in an era
–uses the source of the update as destination

7. MILESTONE 1 Work Challenges Achievements Install TinyOS and Cygwin
Setup a test-bed and implement Surge Application
Work
Install TinyOS and Cygwin
Mote hardware verification
Blink and Surge application
Install TinyOS and Cygwin (xbow version)
Challenges
Identify the problem with the new version of TinyOS
Achievements
Implemented the Surge and Blink application
Installed the new version of TinyOS and tried to run hardware verification tests. The test failed.
After extensive debugging to try and find out the problem, we decided to go with the older (xbow) version of TinyOS
We had to redo the entire process of installing the necessary software including drivers for the serial to USB cable
Hardware tests and the Blink and the Surge applications were successful with the older version of TinyOS

8. MILESTONE 1- RESULTS
1. Each window showed us relevant information for our tests
Serial Forwarder
-Opens the port and reads the no. of packets
Surge-View
-Shows the network topology
-no of packets…quality, yield and prediction
Statistics
-showed the statistics for each node in the network including the base station

9. MILESTONE 2 Work Implemented Surge application
Manipulate environment to detect changes in sensed reading, collect and display changes
Work
Implemented Surge application
Collected results in an output file
Graphically displayed changes using Surge View
Challenges
How to detect changes in real time
Interpreting the output file
Achievements
Observed real time changes to the manipulated environment.
Implementing the Surge application was an easy task. Interpreting the results from the output file was challenging.
Hence, we needed to find a way to view real time changes in sensor readings. After looking through the resources
at our disposal and a lot of playing around with the Surge-View GUI, it was found that by double clicking on the node
shows you all the relevant information about the node and its sensed reading in real time.

10. MILESTONE 2 - RESULTS
Changes in light readings were easily shown on the Surge-View GUI.
For this we needed to find, the specific location of the light sensor on the sensor board (which can be done using the data sheet for the same).

11. Milestone 3 Initial timer was set to 8 seconds
Measure highest reporting rate possible and corresponding energy drain
Initial timer was set to 8 seconds
Modified timer to smaller interval to increase the reporting rate.
Changed the timer interval to 5s ,4s, 2s 1s, >1s
Measured the corresponding energy drains in an output file.
Decreased the timer interval until the mica2 motes stopped communicating.
Graphically shown using the surge view application.
The manual clearly directed us as to where can we make changes in the Surge-View architecture to change the reporting rate.
We started off by decreasing the time interval to the minimum specified on the manual i.e. 2 seconds
However, after clearly understanding the scope of the milestone from the professor we decided to push the setup to its limits until the motes stop communicating
For this purpose, and to observe the effect of increasing the reporting rate we started with a high time interval and subsequently started decreasing it until the fastest
time interval of 320ms was observed.
5. We even tried going below this interval but the setup i.e. would not respond as in there would be no communication

12. Milestone 3 - results The minimal Timer interval was 320ms.
The energy drain was higher for higher reporting rates.
To clearly understand the implications of increasing the reporting rate, we plotted the battery voltage of the sensors which represent the amount of energy
each sensor has against time.
2. It was seen that at higher reporting rates the energy drain was much more faster. This implies that the slope of the lines in the above figure is the key characteristic of the graph.

13. Milestone 4 Learning nesC programming language
Algorithm development - "event driven" mode instead of continuous reporting(polling based setup)
Learning nesC programming language
Understanding the architecture of the Surge application.
Brainstorming
Fixed threshold
Hardcode value for comparison.
Variable threshold
Event of interest.
Surge view needs a minimum number of packets to identify network topology.
We were familiar with the architecture of the Surge application. However, we had to learn and look up examples on the internet about some sample
code in nesC so that we become familiar with it.
2. We met to brainstorm on ideas on how to make the reporting event driven.
3. We realized that we can compare a new reading with the older reading and if it is above a certain threshold we can make it our event of interest

14. Milestone 4 - results
if(((gPrev_Light << 1) < gLight) || ((gPrev_Light >> 1) > gLight) ) {
atomic {
Data_Changed = 1;}
call Leds.redToggle(); }
gPrev_Light = gLight;
Counter++ ;
So we came up with a simple ‘if’ loop where the condition was our event of interest.
We had to keep adjusting the threshold until we thought the change in the light reading will be ‘more or less’ than the previous light reading
If this happens we set our Data_Changed flag to true, which indicates that our event of interest has occurred.
We used the toggling of LED’s as a debugging mechanism to check our code.

15. Milestone 4 - results if(Counter < 50){ post SendData(); } else {
if(Data_Changed == 1){
call Leds.greenToggle();
Data_Changed = 0;
gfSendBusy = FALSE;
call Leds.yellowToggle();
For an initial amount of time, we had to make the communication continuous reporting because the Surge-View GUI needed a minimum no. of packets
to display the network topology.
2. The Surge-View GUI was our main interface of knowing what is happening in our network
3. After the initial amount of time, we sent data only when our event of interest had occurred.
4. With this simple logic our code did not work. We had to debug a lot and take a bit of help from our mentor to understand the nesC code, to infer that we had to change
the gfSendBusy flag to false, since by not doing that the application thought that the previous transmission was still in progress and did not let the event of interest propagate
through the code. 15 15

16. Milestone 5
Implementation of solution
Send data only if there is a change in the sensed light reading.
We decided to change only the light readings since it was the easiest and the fastest way to check our event driven reporting algorithm
If time permitted, we could implement the same if statement with different threshold values with the other sensors on the board like temperature, accelerometer etc.

17. Milestone 5 - results
To prove the success of our algorithm, we gave a demonstration to our mentor.
Also, to make the whole process easy to understand, we took three short video clips to show it to the class for their understanding of the algorithm.
Videos can be made available upon request.

18. Results
We then made the plotted the same sensor variable (battery voltage) against time, to compare the result of our algorithm against continuous reporting.
We found that the slope of our energy drain line for event driven reporting is zero.
This shows the significance of the slope of the energy drain line when compared to the slopes of different reporting rates using continuous reporting.

19. Issues faced TinyOS installation error and compatibility
Fragile equipment
Flash error and Programming board error
Some of the broader issues that we faced during the project are:
The change in using the older version of TinyOS as compared to the newer version
The sensors being very delicate, we had to be careful, not to let the soldering of the battery wire to the sensor break.
We found constant errors while trying to program the motes using the programming board. One solution that we found was effective was to reset the board and if that
does not work, we can just remove and re-plug the power cord into the programming board.

20. Future work Alternate event driven algorithms
Cluster head nodes
Only a subset of nodes report data
Optimize using data aggregation in intermediate nodes.
Cannot distinguish between node failure and no change in sense reading.
Proposed solution: Beacon signals
We thought that our algorithm is very simple in logic and could not be used in the real world. A more sophisticated routing algorithm was necessary.
There has been a lot of research in the area of sensor network routing protocols, we found a really interesting protocol named ‘SIFT’ proposed by the research community at MIT
3. We wanted to discuss the underlying idea behind the protocol which necessarily addresses the constraints of wireless sensor networks with respect to the applications they are
used for.
4. We also noticed that sending the same data from a further node all the way to the base station, we can accommodate intermediate motes with data aggregation mechanisms to
limit the amount of data sent over the network and thereby increasing its life span.
5. Also, we observed that in an event driven reporting scheme, the base station would not be able to recognize if a mote has failed or it does not have anything to report. We proposed
to equip each mote with beacon signals which are sent periodically to signify that they are alive.
This can be useful if the network administrator wants to deploy more motes and the environment is hazardous for human intervention.

21. Summary Practicality of using event driven vs. continuous reporting.
Energy dissipation increases with increasing reporting rate
The max reporting rate is 320ms
Event driven reporting decreases energy drain
This project helped gain hands on knowledge of the working of sensor networks
It made us realize the trade off between energy drain and the corresponding reporting rate.
We concluded that event driven reporting reduces energy drain and improves the life span of the network.

22. Questions?