Cyber-Physical Systems Laboratory - User contributions [en]

CSE730x Research Seminar

2011-03-11T05:30:37Z

Gwh2: /* Mar 11, 2011 - Greg Hackmann */ add paper

{| align="right"
| __TOC__
|}

* '''Instructors:''' [http://www.cse.wustl.edu/~lu Chenyang Lu] and [http://www.cse.wustl.edu/~roman Gruia-Catalin Roman]
* '''Time: Friday at 2-3:30pm, Location: Jolley 542'''

This seminar examines fundamental and emerging concepts in concurrency and distribution by studying seminal papers and recent research results. Broad topics of interest include models of concurrency, mobile computing, parallel architectures, sensor networks, distributed algorithms, and specialized protocols. Each semester, the seminar emphasizes different themes reflecting the current research interests of the participants.

The theme of this semester's seminar is Wireless Sensor Networks. We will read and discuss papers from recent major conferences on mobile, wireless, and sensor networks and systems. These conferences include:

* SenSys ([http://sensys.acm.org/2010/index.html])
* IPSN ([http://ipsn.acm.org/2010/])
* Sigcomm ([http://conferences.sigcomm.org/sigcomm/2010/])
* MobiCom ([http://www.sigmobile.org/mobicom/2010/])
* MobiSys ([http://www.sigmobile.org/mobisys/2010/])
* NSDI ([http://www.usenix.org/events/nsdi11/])
* SOSP ([http://www.sigops.org/sosp/sosp09/])
* OSDI ([http://www.usenix.org/events/osdi10/index.html])
* RTSS ([http://www.rtss.org/])
* RTAS ([http://www.rtas.org/rtas2010/index.htm])
* Wireless Health ([http://www.wirelesshealth2010.org])
* BodyNets ([http://bodynets.org])
* BSN ([http://www.bsn2011.org])

=== Jan 21, 2011 - Mo Sha ===

Ian Rose and Matt Welsh, Mapping the Urban Wireless Landscape with Argos. 8th ACM Conference on Embedded Networked Sensor Systems (SenSys'10), November 2010.

Links: [http://www.eecs.harvard.edu/~ianrose/pubs/argos-sensys10.pdf Paper]
Links: [http://www.eecs.harvard.edu/~ianrose/talks/argos-sensys10.ppt Slides]

=== Jan 28, 2011 - Chengjie Wu ===

Georg Wittenburg, Norman Dziengel, Christian Wartenburger and Jochen Schiller. A System for Distributed Event Detection in Wireless Sensor Networks. 9th ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN'10), April 2010.

Links: [http://page.mi.fu-berlin.de/eke/wittenburg10system.pdf Paper]
Links: [http://page.mi.fu-berlin.de/eke/wittenburg10system_slides.pdf Slides]

=== Feb 4, 2011 - Greg Hackmann ===

Dan Halperin, Wenjun Hu, Anmol Sheth, and David Wetherall. Predictable 802.11 Packet Delivery From Wireless Channel Measurements. Annual conference of the ACM Special Interest Group on Data Communication (SIGCOMM) on the applications, technologies, architectures, and protocols for computer communication (Sigcomm'10), August 2010.

Links: [http://ccr.sigcomm.org/online/files/p159_0.pdf Paper]
[http://www.cs.washington.edu/homes/dhalperi/pubs/effsnr_sigcomm10_slides.pdf Slides]

=== Feb 11, 2011 - Bo Li ===

Fabien Massé, Julien Penders, Aline Serteyn, Martien van Bussel, and Johan Arends. Miniaturized Wireless ECG-Monitor for Real-Time Detection of Epileptic Seizures. Wireless Health 2010.

Links: [http://portal.acm.org/citation.cfm?id=1921095&dl=ACM Paper]

=== Feb 18, 2011 - Abusayeed Saifullah ===
Qing Yu, Jiming Chen, Yanfei Fan, Xuemin Sherman Shen, and Youxian Sun. Multi-channel assignment in wireless sensor networks: A game theoretic approach. The 29th IEEE Conference on Computer Communications (Infocom'10), March 2010.

Links: [http://portal.acm.org/citation.cfm?id=1833687&dl= Paper]

=== Feb 25, 2011 - Fei Yu ===

Thurmon E. Lockhart, Adam T. Barth, Xiaoyue Zhang, Rahul Songra, Emaad Abdel-Rahman, and John Lach. Portable, Non-Invasive Fall Risk Assessment in End Stage Renal Disease Patients on Hemodialysis. Wireless Health 2010.

Links: [http://portal.acm.org/citation.cfm?id=1921092&preflayout=tabs Paper]

=== Mar 4, 2011 - Rahav Dor ===
A presentation on the Current art of Fall detection [[http://www.cse.wustl.edu/wsn/images/9/9c/Fall_detection_Rahav.pdf]]. Compiled from the following 3 research papers surveying the field:

[[http://www.cse.wustl.edu/wsn/images/2/2d/Survey_and_Evaluation_of_Real-Time_Fall_Detection_Approaches.pdf Survey and Evaluation of Real-Time Fall Detection Approaches (High-Capacity Optical Networks and Enabling Technologies (HONET), 2009 6th International Symposium)]]

[[http://www.cse.wustl.edu/wsn/images/3/37/Approaches_and_Principles_in_Fall_detection.pdf Approaches and Principles of Fall detection for Elderly patients (e-health Networking, Applications and Services, 2008. HealthCom 2008. 10th International Conference)]]

=== Mar 11, 2011 - Greg Hackmann ===
Hyduke Noshadi, Foad Dabiri, Saro Meguerdichian, Miodrag Potkonjak and
Majid Sarrafzadeh. Energy Optimization in Wireless Medical Systems Using
Physiological Behavior. Wireless Health 2010.

Links: [http://cs.ucla.edu/~dabiri/papers/WH-2010.pdf Paper]

=== March 18, 2010 - N/A ===

''Canceled due to Spring Break.''

=== Mar 25, 2011 - Mo Sha ===

=== Apr 1, 2011 - Abusayeed Saifullah ===

=== Apr 8, 2011 - Fei Yu ===

=== Apr 15, 2011 - Chengjie Wu ===

=== Apr 22, 2011 - Bo Li ===

=== Apr 29, 2011 - Rahav Dor ===

=== May 6, 2011 - ===

=== Interesting Papers ===

PIE in the Sky: Online Passive Interference Estimation for Enterprise WLANs Vivek Shrivastava, Shravan Rayanchu, Suman Banerjee, and Dina Papagiannaki. 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI'11), March 2011.

SpecNet: Spectrum Sensing Sans Frontieres Anand Iyer, Krishna Chintalapudi, Vishnu Navda, Ramachandran Ramjee, Venkata N. Padmanabhan, and Chandra R. Murthy. 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI'11), March 2011.

Hyduke Noshadi, Foad Dabiri, Saro Meguerdichian, Miodrag Potkonjak and Majid Sarrafzadeh. Energy Optimization in Wireless Medical Systems Using Physiological Behavior. Wireless Health 2010.

Sidharth Nabar, Ayan Banerjee, Sandeep K.S. Gupta, and Radha Poovendran. Evaluation of Body Sensor Network Platforms: A Design Space and Benchmarking Analysis. Wireless Health 2010.

==Previous Semesters==
* [[Seminar Fall 2010|Fall 2010]]
* [[Seminar Spring 2010|Spring 2010]]
* [[Seminar Fall 2009|Fall 2009]]
* [[Seminar Summer 2009|Summer 2009]]
* [[Seminar Spring 2009|Spring 2009]]
* [[Seminar Fall 2008|Fall 2008]]
* [[Seminar Summer 2008|Summer 2008]]
* [[Seminar Spring 2008|Spring 2008]]
* [[Fall 2007]]
* [[Summer 2007]]
* [[Spring 2007]]
* [[Fall 2006]]
* [[Spring 2006]]
* [[Fall 2005]]
* [[Spring 2005]]
* [[Fall 2004]]
* [[Spring 2004]]
* [[Fall 2003]]
* [[Spring 2003]]
* [[Fall 2002]]
* [http://userfs.cec.wustl.edu/~cs673/spring.2002.html Spring 2002]
* [http://userfs.cec.wustl.edu/~cs673/fall.2001.html Fall 2001]
* [http://userfs.cec.wustl.edu/~cs673/spring.2001.html Spring 2001]
* [[Fall 2000]]
* [http://userfs.cec.wustl.edu/~cs673/spring.2000.html Spring 2000]
* [http://cec.wustl.edu/~cs673/backUp/fall.1998.html Fall 1998]
* [http://cec.wustl.edu/~cs673/backUp/spring.1998.html Spring 1998]

CSE730x Research Seminar

2011-02-02T04:34:07Z

Gwh2: /* Feb 4, 2011 - Greg Hackmann */ add paper

2009-04-23T16:48:09Z

Gwh2:

The experimental datasets we collected for "Robust Topology Control for Indoor Wireless Sensor Networks" are available below. They are provided in [http://www.sqlite.org SQLite3] and CSV formats.

Except where noted, each row in the dataset represents one successful packet transmission along with its round number, source, destination, sequence number, RSSI, and LQI. For example, the row

:<code>0|138|133|1|-8|88</code>

represents a packet transmitted during round 0 from node 138 to node 133 with a sequence number of 1, RSSI reading of -8, and LQI reading of 88. Each dataset also includes a second table that indicates the discrete time when each round began; e.g., the row

:<code>0|2008-08-21 23:03:34.458095</code>

means that round 0 began at 23:03 on 2008-08-21.

Putting the data on the Web is a work-in-progress. Currently a subset of the empirical study and evaluation data is posted. We can make the other datasets available on request.

== Empirical Study (Section 3) ==

=== All Links (Section 3.2) ===

{| border = "1"
|-
| [http://www.cse.wustl.edu/~gwh2/art/all-links.sqlite.zip SQLite]
| [http://www.cse.wustl.edu/~gwh2/art/all-links.csv.zip CSV]
|}

=== Ten Links Under Contention (Section 3.3) ===

''RSSI and LQI values were not collected during this experiment. Accordingly, there are no RSSI or LQI columns in the data.''

{| border = "1"
|-
| [[Media:contention.sqlite.zip|SQLite]]
| [[Media:contention.csv.zip|CSV]]
|}

=== Three Links, Fine-Grained (Section 3.4) ===

{| border = "1"
|-
| [[Media:link-fluctuations.sqlite.zip|SQLite]]
| [[Media:link-fluctuations.csv.zip|CSV]]
|}

== Evaluation (Section 6) ==

=== High-Contention Benchmark (Section 6.4) ===

{| border = "1"
|-
! no topology
| [[Media:high-contention-notopology.sqlite.zip|SQLite]]
| [[Media:high-contention-notopology.csv.zip|CSV]]
|-
! ART
| [[Media:high-contention-art.sqlite.zip|SQLite]]
| [[Media:high-contention-art.csv.zip|CSV]]
|-
! ART (w/o gradient optimization)
| [[Media:high-contention-art-nogradient.sqlite.zip|SQLite]]
| [[Media:high-contention-art-nogradient.csv.zip|CSV]]
|-
! PCBL
| [[Media:high-contention-pcbl.sqlite.zip|SQLite]]
| [[Media:high-contention-pcbl.csv.zip|CSV]]
|}

ART Experimental Data

2009-04-20T17:32:48Z

Gwh2: /* All Links (Section 3.2) */

The experimental datasets we collected for "Robust Topology Control for Indoor Wireless Sensor Networks" are available below. They are provided in [http://www.sqlite.org SQLite3] and CSV formats.

Except where noted, each row in the dataset represents one successful packet transmission along with its round number, source, destination, sequence number, RSSI, and LQI. For example, the row

:<code>0|138|133|1|-8|88</code>

represents a packet transmitted during round 0 from node 138 to node 133 with a sequence number of 0, RSSI reading of -8, and LQI reading of 88. Each dataset also includes a second table that indicates the discrete time when each round began; e.g., the row

:<code>0|2008-08-21 23:03:34.458095</code>

means that round 0 began at 23:03 on 2008-08-21.

Putting the data on the Web is a work-in-progress. Currently a subset of the empirical study and evaluation data is posted. We can make the other datasets available on request.

== Empirical Study (Section 3) ==

=== All Links (Section 3.2) ===

{| border = "1"
|-
| [http://www.cse.wustl.edu/~gwh2/art/all-links.sqlite.zip SQLite]
| [http://www.cse.wustl.edu/~gwh2/art/all-links.csv.zip CSV]
|}

=== Ten Links Under Contention (Section 3.3) ===

''RSSI and LQI values were not collected during this experiment. Accordingly, there are no RSSI or LQI columns in the data.''

{| border = "1"
|-
| [[Media:contention.sqlite.zip|SQLite]]
| [[Media:contention.csv.zip|CSV]]
|}

=== Three Links, Fine-Grained (Section 3.4) ===

{| border = "1"
|-
| [[Media:link-fluctuations.sqlite.zip|SQLite]]
| [[Media:link-fluctuations.csv.zip|CSV]]
|}

== Evaluation (Section 6) ==

=== High-Contention Benchmark (Section 6.4) ===

{| border = "1"
|-
! no topology
| [[Media:high-contention-notopology.sqlite.zip|SQLite]]
| [[Media:high-contention-notopology.csv.zip|CSV]]
|-
! ART
| [[Media:high-contention-art.sqlite.zip|SQLite]]
| [[Media:high-contention-art.csv.zip|CSV]]
|-
! ART (w/o gradient optimization)
| [[Media:high-contention-art-nogradient.sqlite.zip|SQLite]]
| [[Media:high-contention-art-nogradient.csv.zip|CSV]]
|-
! PCBL
| [[Media:high-contention-pcbl.sqlite.zip|SQLite]]
| [[Media:high-contention-pcbl.csv.zip|CSV]]
|}

File:Link-fluctuations.csv.zip

2009-04-20T17:25:58Z

Gwh2:

ART Experimental Data

2009-04-20T17:25:49Z

Gwh2: /* Three Links, Fine-Grained (Section 3.4) */

The experimental datasets we collected for "Robust Topology Control for Indoor Wireless Sensor Networks" are available below. They are provided in [http://www.sqlite.org SQLite3] and CSV formats.

Except where noted, each row in the dataset represents one successful packet transmission along with its round number, source, destination, sequence number, RSSI, and LQI. For example, the row

:<code>0|138|133|1|-8|88</code>

represents a packet transmitted during round 0 from node 138 to node 133 with a sequence number of 0, RSSI reading of -8, and LQI reading of 88. Each dataset also includes a second table that indicates the discrete time when each round began; e.g., the row

:<code>0|2008-08-21 23:03:34.458095</code>

means that round 0 began at 23:03 on 2008-08-21.

Putting the data on the Web is a work-in-progress. Currently a subset of the empirical study and evaluation data is posted. We can make the other datasets available on request.

== Empirical Study (Section 3) ==

=== All Links (Section 3.2) ===

{| border = "1"
|-
| [[Media:all-links.sqlite.zip|SQLite]]
| [[Media:all-links.csv.zip|CSV]]
|}

=== Ten Links Under Contention (Section 3.3) ===

''RSSI and LQI values were not collected during this experiment. Accordingly, there are no RSSI or LQI columns in the data.''

{| border = "1"
|-
| [[Media:contention.sqlite.zip|SQLite]]
| [[Media:contention.csv.zip|CSV]]
|}

=== Three Links, Fine-Grained (Section 3.4) ===

{| border = "1"
|-
| [[Media:link-fluctuations.sqlite.zip|SQLite]]
| [[Media:link-fluctuations.csv.zip|CSV]]
|}

== Evaluation (Section 6) ==

=== High-Contention Benchmark (Section 6.4) ===

{| border = "1"
|-
! no topology
| [[Media:high-contention-notopology.sqlite.zip|SQLite]]
| [[Media:high-contention-notopology.csv.zip|CSV]]
|-
! ART
| [[Media:high-contention-art.sqlite.zip|SQLite]]
| [[Media:high-contention-art.csv.zip|CSV]]
|-
! ART (w/o gradient optimization)
| [[Media:high-contention-art-nogradient.sqlite.zip|SQLite]]
| [[Media:high-contention-art-nogradient.csv.zip|CSV]]
|-
! PCBL
| [[Media:high-contention-pcbl.sqlite.zip|SQLite]]
| [[Media:high-contention-pcbl.csv.zip|CSV]]
|}

File:Link-fluctuations.sqlite.zip

2009-04-20T17:25:13Z

Gwh2:

File:Contention.csv.zip

2009-04-20T17:24:28Z

Gwh2:

File:Contention.sqlite.zip

2009-04-20T17:24:16Z

Gwh2:

ART Experimental Data

2009-04-20T17:22:42Z

Gwh2: Add data for Section 3

The experimental datasets we collected for "Robust Topology Control for Indoor Wireless Sensor Networks" are available below. They are provided in [http://www.sqlite.org SQLite3] and CSV formats.

Except where noted, each row in the dataset represents one successful packet transmission along with its round number, source, destination, sequence number, RSSI, and LQI. For example, the row

:<code>0|138|133|1|-8|88</code>

represents a packet transmitted during round 0 from node 138 to node 133 with a sequence number of 0, RSSI reading of -8, and LQI reading of 88. Each dataset also includes a second table that indicates the discrete time when each round began; e.g., the row

:<code>0|2008-08-21 23:03:34.458095</code>

means that round 0 began at 23:03 on 2008-08-21.

Putting the data on the Web is a work-in-progress. Currently a subset of the empirical study and evaluation data is posted. We can make the other datasets available on request.

== Empirical Study (Section 3) ==

=== All Links (Section 3.2) ===

{| border = "1"
|-
| [[Media:all-links.sqlite.zip|SQLite]]
| [[Media:all-links.csv.zip|CSV]]
|}

=== Ten Links Under Contention (Section 3.3) ===

''RSSI and LQI values were not collected during this experiment. Accordingly, there are no RSSI or LQI columns in the data.''

{| border = "1"
|-
| [[Media:contention.sqlite.zip|SQLite]]
| [[Media:contention.csv.zip|CSV]]
|}

=== Three Links, Fine-Grained (Section 3.4) ===

{| border = "1"
|-
| [[Media:link-fluctuations.sqlite.zip|SQLite]]
| [[Media:link-fluctuations.sqlite.zip|CSV]]
|}

== Evaluation (Section 6) ==

=== High-Contention Benchmark (Section 6.4) ===

{| border = "1"
|-
! no topology
| [[Media:high-contention-notopology.sqlite.zip|SQLite]]
| [[Media:high-contention-notopology.csv.zip|CSV]]
|-
! ART
| [[Media:high-contention-art.sqlite.zip|SQLite]]
| [[Media:high-contention-art.csv.zip|CSV]]
|-
! ART (w/o gradient optimization)
| [[Media:high-contention-art-nogradient.sqlite.zip|SQLite]]
| [[Media:high-contention-art-nogradient.csv.zip|CSV]]
|-
! PCBL
| [[Media:high-contention-pcbl.sqlite.zip|SQLite]]
| [[Media:high-contention-pcbl.csv.zip|CSV]]
|}

User:Gwh2/LaTeX Best Practices

2009-04-08T23:04:51Z

Gwh2:

== General ==

Add a line break after each sentence. This makes it much easier to deal with version control, since CVS and SVN can automatically merge changes iff they happen on different lines.

== Citation Formatting ==

Add <code>\usepackage{cite}</code> to your preamble to get nicer formatting for multiple-key citations.

Use <code>text~\cite{key}</code> rather than <code>text \cite{key}</code> to keep LaTeX from breaking sentences like

<pre>
blah blah blah text
[1]
</pre>

== Image Formatting ==

The '''One True Template''' for inserting images is:

<pre>
\begin{figure}[htbp]
\centering
\includegraphics[width=\columnwidth]{filename-no-extension}
\caption{Figure caption}
\label{fig:section:filename-no-extension}
\end{figure}
</pre>

* LaTeX is incredibly whiny about having the image, caption, and label in that order. Get it wrong, and parts of your paper may have funny references.
* Be sure to exclude the filename extension. That way, when a conference changes its mind and demands an .EPS rather than a .PDF, you can just convert all of your .PDF/.PNG images to .EPS, run <code>latex</code> instead of <code>pdflatex</code>, and not have to change any of your LaTeX code.
* Starting the label with "fig:section:" helps for code completion. (You ''are'' using an editor with code completion, right?)

User:Gwh2/LaTeX Best Practices

2009-04-08T22:00:13Z

Gwh2: New page: == Citation Formatting == Add <code>\usepackage{cite}</code> to your preamble to get nicer formatting for multiple-key citations. Use <code>text~\cite{key}</code> rather than <code>text ...

== Citation Formatting ==

Add <code>\usepackage{cite}</code> to your preamble to get nicer formatting for multiple-key citations.

Use <code>text~\cite{key}</code> rather than <code>text \cite{key}</code> to keep LaTeX from breaking sentences like

<pre>
blah blah blah text
[1]
</pre>

== Image Formatting ==

The '''One True Template''' for inserting images is:

<pre>
\begin{figure}[htbp]
\centering
\includegraphics[width=\columnwidth]{filename-no-extension}
\caption{Figure caption}
\label{fig:section:filename-no-extension}
\end{figure}
</pre>

* LaTeX is incredibly whiny about having the image, caption, and label in that order. Get it wrong, and parts of your paper may have funny references.
* Be sure to exclude the filename extension. That way, when a conference changes its mind and demands an .EPS rather than a .PDF, you can just convert all of your .PDF/.PNG images to .EPS, run <code>latex</code> instead of <code>pdflatex</code>, and not have to change any of your LaTeX code.
* Starting the label with "fig:section:" helps for code completion. (You ''are'' using an editor with code completion, right?)

The WUSTL Wireless Sensor Network Testbed

2009-03-30T17:56:54Z

Gwh2: /* Existing Deployment */

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 78 wireless sensor nodes (motes) placed throughout several office areas in Jolley and Bryan Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 [http://www.xbow.com/Products/productdetails.aspx?sid=252 TelosB] motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|600px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add one node to the current deployment; the existing 30 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The testbed software has a client/server architecture, plus a set of user applications that interact with the wireless testbed. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

The client, server, and user application software has been written mostly in Python, with some performance-critical sections written in C. In addition, the server application interacts with a PostgreSQL database which lists the active microservers and motes. The PostgreSQL backend is also available for user applications to store experimental data.

===Startup===
The server software is automatically started as a Linux service on the testbed server machine. The client software is also installed as a service on the microservers but is not automatically started. A script is provided to the user which connects to the server and requests that the client be started on one or more microservers.

When the client service is brought up, it sends a status message to the server, which marks the microserver as "up" in the database. The microserver will also send messages listing the motes attached to its USB ports, which are likewise stored in the database.

===Programming===
To program a set of motes, the user runs the "program.py" script, passing it the program binary and a description of the motes to program. The user can select to program specific motes, all the motes attached to specific microservers, or the entire testbed.
The server converts this request into a list of targeted motes.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's network address (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a request to the microserver to flash the binary onto the mote.

When the programming completes, the microserver informs the server whether it was successful or not. The server collects this status for every mote in the programming set, and informs the "program.py" script when the job is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

===Serial Communication===
The testbed software allows the user to send and receive serial packets through the motes' USB ports. When a microserver discovers a new mote attached to one of its USB ports, it opens a connection to the mote's serial port. Whenever a new serial packet is ready, the microserver reads the packet and sends it to the testbed server over the Ethernet backbone. The testbed server forwards each packet to end-user applications which subscribe to this data. Conversely, users may send the server requests to write a serial packet to a specific mote, which the server will forward to the corresponding microserver.

The TinyOS SDK normally provides a "Serial Forwarder" component that allows PC applications to collect data from a locally-attached mote. To interact with the testbed instead, the user runs the provided "forwarder.py" script, which acts as a drop-in replacement for the Serial Forwarder. Thus, existing applications developed using the standard TinyOS SDK can be used on the testbed without modifications.

Users may optionally use a testbed-specific Python API in place of the "forwarder.py" script. This Python API offers new features which are not provided by the standard TinyOS SDK, such as the ability to remotely reboot motes.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-03-30T17:52:00Z

Gwh2: /* Proposed Deployment */

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 78 wireless sensor nodes (motes) placed throughout several office areas in Jolley and Bryan Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|600px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add one node to the current deployment; the existing 30 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The testbed software has a client/server architecture, plus a set of user applications that interact with the wireless testbed. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

The client, server, and user application software has been written mostly in Python, with some performance-critical sections written in C. In addition, the server application interacts with a PostgreSQL database which lists the active microservers and motes. The PostgreSQL backend is also available for user applications to store experimental data.

===Startup===
The server software is automatically started as a Linux service on the testbed server machine. The client software is also installed as a service on the microservers but is not automatically started. A script is provided to the user which connects to the server and requests that the client be started on one or more microservers.

When the client service is brought up, it sends a status message to the server, which marks the microserver as "up" in the database. The microserver will also send messages listing the motes attached to its USB ports, which are likewise stored in the database.

===Programming===
To program a set of motes, the user runs the "program.py" script, passing it the program binary and a description of the motes to program. The user can select to program specific motes, all the motes attached to specific microservers, or the entire testbed.
The server converts this request into a list of targeted motes.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's network address (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a request to the microserver to flash the binary onto the mote.

When the programming completes, the microserver informs the server whether it was successful or not. The server collects this status for every mote in the programming set, and informs the "program.py" script when the job is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

===Serial Communication===
The testbed software allows the user to send and receive serial packets through the motes' USB ports. When a microserver discovers a new mote attached to one of its USB ports, it opens a connection to the mote's serial port. Whenever a new serial packet is ready, the microserver reads the packet and sends it to the testbed server over the Ethernet backbone. The testbed server forwards each packet to end-user applications which subscribe to this data. Conversely, users may send the server requests to write a serial packet to a specific mote, which the server will forward to the corresponding microserver.

The TinyOS SDK normally provides a "Serial Forwarder" component that allows PC applications to collect data from a locally-attached mote. To interact with the testbed instead, the user runs the provided "forwarder.py" script, which acts as a drop-in replacement for the Serial Forwarder. Thus, existing applications developed using the standard TinyOS SDK can be used on the testbed without modifications.

Users may optionally use a testbed-specific Python API in place of the "forwarder.py" script. This Python API offers new features which are not provided by the standard TinyOS SDK, such as the ability to remotely reboot motes.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-03-30T17:44:34Z

Gwh2: /* Testbed Software */ rewrote

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 78 wireless sensor nodes (motes) placed throughout several office areas in Jolley and Bryan Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|600px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add two nodes to the current deployment; the existing 29 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The testbed software has a client/server architecture, plus a set of user applications that interact with the wireless testbed. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

The client, server, and user application software has been written mostly in Python, with some performance-critical sections written in C. In addition, the server application interacts with a PostgreSQL database which lists the active microservers and motes. The PostgreSQL backend is also available for user applications to store experimental data.

===Startup===
The server software is automatically started as a Linux service on the testbed server machine. The client software is also installed as a service on the microservers but is not automatically started. A script is provided to the user which connects to the server and requests that the client be started on one or more microservers.

When the client service is brought up, it sends a status message to the server, which marks the microserver as "up" in the database. The microserver will also send messages listing the motes attached to its USB ports, which are likewise stored in the database.

===Programming===
To program a set of motes, the user runs the "program.py" script, passing it the program binary and a description of the motes to program. The user can select to program specific motes, all the motes attached to specific microservers, or the entire testbed.
The server converts this request into a list of targeted motes.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's network address (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a request to the microserver to flash the binary onto the mote.

When the programming completes, the microserver informs the server whether it was successful or not. The server collects this status for every mote in the programming set, and informs the "program.py" script when the job is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

===Serial Communication===
The testbed software allows the user to send and receive serial packets through the motes' USB ports. When a microserver discovers a new mote attached to one of its USB ports, it opens a connection to the mote's serial port. Whenever a new serial packet is ready, the microserver reads the packet and sends it to the testbed server over the Ethernet backbone. The testbed server forwards each packet to end-user applications which subscribe to this data. Conversely, users may send the server requests to write a serial packet to a specific mote, which the server will forward to the corresponding microserver.

The TinyOS SDK normally provides a "Serial Forwarder" component that allows PC applications to collect data from a locally-attached mote. To interact with the testbed instead, the user runs the provided "forwarder.py" script, which acts as a drop-in replacement for the Serial Forwarder. Thus, existing applications developed using the standard TinyOS SDK can be used on the testbed without modifications.

Users may optionally use a testbed-specific Python API in place of the "forwarder.py" script. This Python API offers new features which are not provided by the standard TinyOS SDK, such as the ability to remotely reboot motes.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-03-18T20:21:55Z

Gwh2: Update # of motes in intro

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 78 wireless sensor nodes (motes) placed throughout several office areas in Jolley and Bryan Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|600px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add two nodes to the current deployment; the existing 29 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-02-28T20:07:15Z

Gwh2: /* Existing Deployment */ enlarge the thumbnail

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|600px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add two nodes to the current deployment; the existing 29 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

File:Wsn-proposed.png

2009-02-28T20:06:34Z

Gwh2:

The WUSTL Wireless Sensor Network Testbed

2009-02-28T20:06:23Z

Gwh2: /* Proposed Deployment */

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
We would like to expand the testbed to include more offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. The proposed expansion will only add two nodes to the current deployment; the existing 29 nodes in Jolley Hall will be distributed across more offices.

[[Image:wsn-proposed.png|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-02-28T20:00:29Z

Gwh2: /* Future Plans */ removing since everything has been done

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
As stated previously, we would like to expand the testbed to include all of the offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. It contains 96 motes and would require the support from 39 microservers. If we were able to run wires through the ceiling, then the number of microservers required would be significantly reduced, as up to 7 motes can be connected to a single microserver at any given time. As of now, however, we do not have permission to do so, and will thus require a new microserver in each room where motes are being deployed.

[[Image:wsn-proposed.jpg|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

File:Wsn-deployment.png

2009-02-28T19:59:32Z

Gwh2: New WSN deployment map

New WSN deployment map

The WUSTL Wireless Sensor Network Testbed

2009-02-28T19:59:08Z

Gwh2: Undo revision 1318 by Gwh2 (Talk) -- hit the wrong button

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
As stated previously, we would like to expand the testbed to include all of the offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. It contains 96 motes and would require the support from 39 microservers. If we were able to run wires through the ceiling, then the number of microservers required would be significantly reduced, as up to 7 motes can be connected to a single microserver at any given time. As of now, however, we do not have permission to do so, and will thus require a new microserver in each room where motes are being deployed.

[[Image:wsn-proposed.jpg|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Future Plans==

===Expansion into Bryan Hall===
After we see how successful of a deployment we have in Jolley Hall, we would like to expand the testbed to include offices in Bryan Hall as well. The figure below shows a preliminary design of the deployment.

[[Image:wsn-bryan-hall.jpg|thumb|left|300px|Preliminary Bryan Hall deployment]]
 

===Improved Software Infrastructure===
There are a number of changes that will make the testbed easier to use and run more smoothly.

* '''Hotplugging motes.''' Currently, the client programs must be stopped and restarted if motes are plugging or unplugged. The client does support refreshing when it receives the SIGUSR1 signal, but currently nothing sends it the signal. To support hotplugging motes, the microserver needs a script in the hotplug system that sends the client the SIGUSR1 signal whenever a USB event occurs.

* '''Better mote discovery.''' The microserver discovers which motes are attached by looking for instance of the ftdi driver in the sysfs filesystem. Instead, we can use the Python bindings to the libusb library to more accurately discover which motes are connected.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-02-28T19:57:13Z

Gwh2: Reverted edits by Gwh2 (Talk); changed back to last version by Liangfok

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 31 motes placed throughout several designated areas in Jolley hall. The areas chosen were the ones we had access to at the time of the initial deployment. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Mobilab (519) which has two microservers). As we will show later on, we have implemented a simple localization service that runs surprisingly well given such a sparse deployment.

[[Image:wsn-deployment.jpg|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
As stated previously, we would like to expand the testbed to include all of the offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. It contains 96 motes and would require the support from 39 microservers. If we were able to run wires through the ceiling, then the number of microservers required would be significantly reduced, as up to 7 motes can be connected to a single microserver at any given time. As of now, however, we do not have permission to do so, and will thus require a new microserver in each room where motes are being deployed.

[[Image:wsn-proposed.jpg|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Future Plans==

===Expansion into Bryan Hall===
After we see how successful of a deployment we have in Jolley Hall, we would like to expand the testbed to include offices in Bryan Hall as well. The figure below shows a preliminary design of the deployment.

[[Image:wsn-bryan-hall.jpg|thumb|left|300px|Preliminary Bryan Hall deployment]]
 

===Improved Software Infrastructure===
There are a number of changes that will make the testbed easier to use and run more smoothly.

* '''Hotplugging motes.''' Currently, the client programs must be stopped and restarted if motes are plugging or unplugged. The client does support refreshing when it receives the SIGUSR1 signal, but currently nothing sends it the signal. To support hotplugging motes, the microserver needs a script in the hotplug system that sends the client the SIGUSR1 signal whenever a USB event occurs.

* '''Better mote discovery.''' The microserver discovers which motes are attached by looking for instance of the ftdi driver in the sysfs filesystem. Instead, we can use the Python bindings to the libusb library to more accurately discover which motes are connected.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

The WUSTL Wireless Sensor Network Testbed

2009-02-28T19:56:51Z

Gwh2: /* Existing Deployment */ the new testbed map is a PNG

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.png|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
As stated previously, we would like to expand the testbed to include all of the offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. It contains 96 motes and would require the support from 39 microservers. If we were able to run wires through the ceiling, then the number of microservers required would be significantly reduced, as up to 7 motes can be connected to a single microserver at any given time. As of now, however, we do not have permission to do so, and will thus require a new microserver in each room where motes are being deployed.

[[Image:wsn-proposed.jpg|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Future Plans==

===Expansion into Bryan Hall===
After we see how successful of a deployment we have in Jolley Hall, we would like to expand the testbed to include offices in Bryan Hall as well. The figure below shows a preliminary design of the deployment.

[[Image:wsn-bryan-hall.jpg|thumb|left|300px|Preliminary Bryan Hall deployment]]
 

===Improved Software Infrastructure===
There are a number of changes that will make the testbed easier to use and run more smoothly.

* '''Hotplugging motes.''' Currently, the client programs must be stopped and restarted if motes are plugging or unplugged. The client does support refreshing when it receives the SIGUSR1 signal, but currently nothing sends it the signal. To support hotplugging motes, the microserver needs a script in the hotplug system that sends the client the SIGUSR1 signal whenever a USB event occurs.

* '''Better mote discovery.''' The microserver discovers which motes are attached by looking for instance of the ftdi driver in the sysfs filesystem. Instead, we can use the Python bindings to the libusb library to more accurately discover which motes are connected.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

File:Wsn-deployment.jpg

2009-02-28T19:54:11Z

Gwh2: uploaded a new version of "Image:Wsn-deployment.jpg": Reverted to version as of 22:04, 6 December 2007

File:Wsn-deployment.jpg

2009-02-28T19:52:48Z

Gwh2: uploaded a new version of "Image:Wsn-deployment.jpg": Updated to show Bryan Hall deployment

The WUSTL Wireless Sensor Network Testbed

2009-02-28T19:52:05Z

Gwh2: /* Existing Deployment */ updated to show Bryan Hall expansion

{| align = "center"
| [[Image:wsn-wustl-logo.png]]
|}

{| align = "center"
| Contact: [mailto:gwh2@cse.wustl.edu Greg Hackmann]
|}

{| align="right"
| __TOC__
|}

To facilitate advanced research in wireless sensor network technology, we are currently in the process of deploying a wireless sensor network testbed at Washington University in St. Louis. The testbed currently consists of 31 wireless sensor nodes (motes) placed throughout several office areas in Jolley Hall -- i.e., several grad student offices, the graduate student lounge, several labs, and the two conference rooms. Our hope in the short term is to expand this testbed to include around 100 motes spread throughout all office areas in Jolley Hall. Eventually, we would like to expand it to cover Brian Hall as well.

This document serves as an overview of the testbed setup and its current deployment. It is a living document in the sense that it will be updated as changes to the testbed continue to be made. In the end it will serve as a source of reference for anyone using the testbed to run sensornet related experiments.

Having a testbed of this size is important for a number of reasons:

* '''Only a handful of testbeds of this size exist in the world today.''' By being one of the first to have such a testbed, we will be able to conduct experiments that others have previously been unable to run. Our eventual goal is to make the testbed accessible through a simple web interface, opening it to users across the globe.
* '''Running large scale wireless sensor network experiments is hard.''' Programming a single mote can take up to five minutes depending on the size of the binary it is being programmed with. Without a testbed to streamline the process of programming a large number of motes, programming each mote individually can quickly become a significant bottleneck. Furthermore, as programming typically takes place by physically attaching a mote to your local machine, deploying them afterwards also takes a significant amount of time.

'''IMPORTANT:''' 
Please keep in mind that the motes deployed in the testbed only contain sensors for light, radiation, temperature, and humidity. There are no microphones or cameras, and there is no plan to EVER include such sensors in the future. The purpose of the testbed is primarily for measuring communication characteristics of the motes and not evaluating the sensitivity or accuracy of its sensors. If you have any privacy concerns about including the testbed in your office please direct any questions to [mailto:wsn@cse.wustl.edu wsn@cse.wustl.edu].

==Testbed Setup==
Our testbed deployment is based on the [http://www.tkn.tu-berlin.de/publications/papers/real04f-handziski.pdf TWIST architecture] originally developed by the telecommunications group ([http://www.tkn.tu-berlin.de/ TKN]) at the Technical University of Berlin. The acronmym TWIST stands for "TKN Wireless Indoor Sensor network Testbed". It is hierarchical in nature, consisting of three different levels of deployment: sensor nodes, microservers, and a desktop class host/server machine. A high level view of this three tiered architecture can be seen in the figure below.
At the lowest tier, sensor nodes are placed throughout the physical environment in order to take sensor readings and/or perform actuation. They are connected to microservers at the second tier through a USB infrastructure consisting of USB 2.0 compliant hubs and a set of active/passive USB cables. Messages can be exchanged between sensor nodes and microservers over this interface in both directions. At the third and final tier exists a dedicated server which connects to all of the microservers over an Ethernet backbone. The server machine is used to host, among other things, a database containing information about the different sensor nodes and the microservers they are connected to. This database minimally contains information about the connections that have been established between the sensor nodes and microservers, as well as their current locations. The server machine is also used to provide a workable interface between the testbed and any end-users. Users may log onto the server to gain access to the information contained in the testbed database, as well as exchange messages with nodes contained in the testbed. The entire TWIST architecture is based on cheap, off-the-shelf hardware and uses open-source software at every tier of its deployment.

[[Image:wsn-architecture.jpg|thumb|left|300px|TWIST architecture]]
 

Having such an architecture enables one to perform tasks not feasible in other WSN deployments. For example, debug messages from individual sensor nodes can be sent to the control station over the USB interface without interfering with a WSN application running in the network. The USB infrastructure essentially provides an out of band means for collecting important information from each node without clogging up the wireless channel and adversely affecting any experiments being run. This debug information can also be time stamped by the micorservers using NTP (Network Time Protocol) in order to gather statistics about what is going on at each individual point in the network at any given time.

Programming of sensor nodes in the testbed is also made easier using the three tiered architecture, as a user simply tells the control station which sensor nodes it would like to program, and the control station does the work of distributing this request to the proper microserver. Information about which sensor node is attached to which microserver can be obtained from the testbed database, and each request can be sent to the proper microserver using a dedicated thread of control. These requests can then be processed by each microserver in parallel, speeding up the time required to program the entire testbed significantly.

Individual sensor nodes in the testbed can also be disabled or enabled the USB interface. This capability allows node failures to be simulated in the testbed environment, as well as fine tune the density of the network itself when running certain types of experiments. The introduction of new nodes into the network can also be simulated by enabling nodes at specific times during the run of an experiment.

All of the features described above really boil down to just one thing. It is possible to run sophisticated experiments in the WSN testbed without ever having to physically change the layout of the testbed or interact with the individual sensor nodes that make it up. Everything is controllable from the central server, and scripts can be written to perform countless numbers of operations involving each of the capabilites described above.

==Existing Deployment==
Currently the testbed consists of 78 motes placed throughout Bryan and Jolley Hall. The figure below shows the placement of these motes in the testbed. Each room contains a single microserver connected to all of the motes in that room (with the exception of Jolley 519 and Bryan 509C, which have two microservers).

[[Image:wsn-deployment.jpg|thumb|left|300px|Existing deployment]]
 

==Proposed Deployment==
As stated previously, we would like to expand the testbed to include all of the offices in Jolley Hall, as well as some of the lab spaces. Below is a figure of the proposed deployment. It contains 96 motes and would require the support from 39 microservers. If we were able to run wires through the ceiling, then the number of microservers required would be significantly reduced, as up to 7 motes can be connected to a single microserver at any given time. As of now, however, we do not have permission to do so, and will thus require a new microserver in each room where motes are being deployed.

[[Image:wsn-proposed.jpg|thumb|left|300px|Proposed deployment]]
 

==Testbed Software==

The software consists of three pieces: the client, the server, and the user applications. The client runs on the microservers and manages finding, programming, and communicating with the attached motes. The server coordinates the clients and the user applications. The user applications help the user to program, list, and communicate with motes in the system.

===Outlets===
An "outlet" is the place where a mote is plugged into the microserver. The outlet is described by the microserver name and the location in the USB topology. A location in the USB topology is described by the bus, and a list of ports which each child device is plugged into. For example, if we have a mote plugged into port 3 of a hub, which is plugged into port 2 on the microserver "doogle", which is serviced by bus 1, then the path of the outlet is "doogle 1-2.3". We use this format because the USB topology depends only on where each USB connection is plugged in; it is independent of both order of plugging in and which mote is attached.

===Messages===
The parts communicate by sending messages to each other. The messages are normal Python objects that communicate across sockets using Python's "pickling" module. The pickling module provides methods for marshalling and unmarshalling objects, and allows the programmer to treat the network connection as bidirectional queue of objects.

===Client and Server Implementation===
The structure of the client and server programs is extremely similar. Both act upon messages generated internally or received from sockets, and create new messages. The programs center around a "message queue" and an "event loop."

The message queue holds a FIFO queue of tuples. Each tuple contains the message itself and a "source" value. Generally the source value holds the connection that the message was received from, allowing the program to reply to the sender.

The event loop, running in its own thread, continuously pulls a message from the message queue and runs a handler method corresponding to the message type.

The client and server programs use a reactor pattern to quickly read data from the sockets and serial ports. The reactor object runs in its own thread and uses the "select" call to determine when the connections have data ready. It then calls the handlers for each ready connection. The handlers will perform some operation on the data, wrap the result in a message, and place the message into the event queue.

Note: The term "handler" is overloaded. It either refers to a handler for data from a socket or a handler for messages in the message queue.

One reactor handler deserves mentioning: the UnpicklingHandler. The UnpicklingHandler buffers incoming data until a full object has been read, and then places the object into the event queue. This way, unpickling becomes a non-blocking event, and we can read from a pickled connection without another thread.

===Startup===
To bring up the system, the user must start the server and then start the clients on any microservers he wishes to bring up. The server begins by marking every microserver as "down" in the database, and by listening for connections. The client begins by connecting to the server and sending a MicroserverUp message with the microserver's name. The server marks the microserver as "up" and sends a RefreshOutlets message to discover which motes are connected to the microserver. The microserver replies with an OutletChanged message for each connected mote, which details the outlet name and the mote id. The server stores the outlet information in the database.

===Programming===
To program a set of motes, the user runs the "program" program, passing it the program binary and a description of the motes to program. The user can select to program by mote id, by microserver name, or the entire testbed. The "program" program sends a Program[Mote$|$Microserver$|$Network]Job message to the server. The "program" program then waits for a response to the server. From the message details, the server determines the set of motes to be programmed. The server creates a ProgrammingJob object, which tracks the progress of the programming request.

Once the set of motes has been determined, the server creates a binary file for each mote. The server copies the original binary, imprints it with the mote's AM_ID (stored in the database), and moves the new binary to the home directory of the microserver the mote is attached to. The server then passes a ProgramOutlet message to the microserver. Upon receiving the message, the microserver runs tos-bsl to flash the binary onto the mote.

When tos-bsl completes, the microserver informs the server whether the programming was successful or not. The server records the status in the ProgrammingJob object. When the ProgrammingJob has a result for every mote in the programming set, the server informs the "program" program that the programming is complete.

The slowest part of programming a mote is flashing the binary onto the mote. Because the flashing takes place on the microserver, we can program motes on different microservers in parallel, allowing us to program the entire testbed in the time it takes to program the motes on a single microserver.

'''Note:''' When programming a mote, you must close any other connections to the mote's serial port.

===Serial Communication===
The testbed software allows the user to receive packets from the motes' serial ports (sending to the serial ports is not supported yet, and is discussed in the "future work" section). To receive serial data, the client program connects to the server and sends a Subscribe message. The server records the client in the list of subscribers and will dispatch incoming packets to the client. The "subscribe" program, an example of a subscriber, prints out each incoming packet.

When the client discovers a new mote, it opens a connection to the mote's serial port and to the servers "packet" port. Whenever serial data is ready, the client reads the bytes from the serial port and sends the (raw) data to the server. The server breaks the data stream up into packets, annotates the packet with the id of the sending mote, and forwards the packet to each subscriber in the subscribers list.

==Current Services==

===Localization===
We currently have a localization service implemented in which all of the motes in the testbed act as anchor nodes in order to help localize a beacon node roaming throughout the network. Below is a snapshot of a GUI application we have developed to visualize this localization service in action. With the denser deployment of motes in the proposed testbed, we hope to become extremely accurate in determining the location of these beacon nodes in the network.

[[Image:wsn-localization.png|thumb|left|300px|WSN localization application]]
 

In this figure we see two beacon nodes (102 and 103) being localized to rooms (519 and 534) respectively. The purple dots represent anchor nodes deployed in the testbed and the green lines depict which anchors have heard a message sent by one of the beacons. The localization algorithm used is based on particle filters -- a well understood method of localization used in robotics. We have expanded the use of the particle filter to the wireless sensor network domain.

==Future Plans==

===Expansion into Bryan Hall===
After we see how successful of a deployment we have in Jolley Hall, we would like to expand the testbed to include offices in Bryan Hall as well. The figure below shows a preliminary design of the deployment.

[[Image:wsn-bryan-hall.jpg|thumb|left|300px|Preliminary Bryan Hall deployment]]
 

===Improved Software Infrastructure===
There are a number of changes that will make the testbed easier to use and run more smoothly.

* '''Hotplugging motes.''' Currently, the client programs must be stopped and restarted if motes are plugging or unplugged. The client does support refreshing when it receives the SIGUSR1 signal, but currently nothing sends it the signal. To support hotplugging motes, the microserver needs a script in the hotplug system that sends the client the SIGUSR1 signal whenever a USB event occurs.

* '''Better mote discovery.''' The microserver discovers which motes are attached by looking for instance of the ftdi driver in the sysfs filesystem. Instead, we can use the Python bindings to the libusb library to more accurately discover which motes are connected.

==Acknowledgments==
This work is supported by the NSF under a CRI grant (CNS-0708460) and an ITR grant (CCR-0325529).

Cyber-Physical Co-Design of Wireless Monitoring and Control for Civil Infrastructure

2008-12-08T19:53:19Z

Gwh2: Updated WS2 snapshot and pointed to new instructions

Welcome to the wiki of the [[Structural Health Monitoring]] group at [http://www.wustl.edu Washington University in St. Louis]. This site is fairly new, so it may be a while before we have a fair number of pages here. You can also see us at our [http://mase.wustl.edu/wusceel/quake WashU page].

== Publications ==
* Hackmann, G., Sun, F., Castaneda, N., Lu, C., and Dyke, S., "A Holistic Approach to Decentralized Structural Damage Localization Using Wireless Sensor Networks," Proceedings of 29th IEEE Real-Time Systems Symposium (RTSS 2008), 2008.

: ''Published Version'': [[http://www.cse.wustl.edu/~lu/papers/rtss08-shm.pdf PDF]] [[http://userfs.cec.wustl.edu/~gwh2/publications/hackmann08-a-holistic.bib BibTeX]]
: ''Extended Technical Report'': [[http://www.cse.seas.wustl.edu/Research/FileDownload.asp?799 PDF]] [[http://userfs.cec.wustl.edu/~gwh2/publications/hackmann08-a-holistic-tr.bib BibTeX]]

== Software ==
* WS2 - The implementation of the damage localization application for Imote2 nodes. ''(updated 2008/11/20)''
** [[media:ws2_2008-11-20.zip|Source Code]]
** [[WS2 Installation Instructions|Installation Instructions]]
** [[WS2 Usage Instructions|Usage Instructions]]

== Presentations ==
* Hackmann, G., "A Holistic Approach to Decentralized Structural Damage Localization Using Wireless Sensor Networks", RTSS 2008 presentation, December 1, 2008. [[http://userfs.cec.wustl.edu/~gwh2/publications/rtss08.pptx PPTX]] [[http://userfs.cec.wustl.edu/~gwh2/publications/rtss08.pdf PDF]]
* "Implementation of Decentralized Damage Localization in Wireless Sensor Networks," by Fei Sun. MS Defense. In partial fulfillment of a Master's Degree in Computer Science. May 9, 2008. Download: [[media:fei-msp.pptx|pptx]], [[media:fei-msp.pdf|pdf]]

== Further Reading ==

* [[What is Structural Health Monitoring?]]
* [[Reading List]]
* [[Imote2 Notes]]

File:Imote2-pin1.jpg

2008-12-08T19:50:53Z

Gwh2:

WS2 Installation Instructions

2008-12-08T19:47:49Z

Gwh2: /* Step 1 */

Installing WS2 is a multi-step process that involves setting up several software tools and performing some sensor calibration. This document is designed to walk you through this process. These instructions assume that you have a PC running a recent version of Windows (Windows 2000, XP, or Vista) and know how to use a text editor like [http://www.textpad.com/ TextPad] or [http://notepad-plus.sourceforge.net/ Notepad++].

You will need to use a text editor application which supports "UNIX-style" line endings. Most text editor applications support this feature. Unfortunately, the Notepad application included with Windows does not. [http://notepad-plus.sourceforge.net/ Notepad++] is a free alternative to Notepad which will work with this tutorial.

== TinyOS Setup ==

=== Step 1 ===

You will first need to install TinyOS 1.1 and add support for the iMote2 platform. The Structural Health Monitoring group at UIUC has created a helpful [http://shm.cs.uiuc.edu/imotestart.html "Getting Started" guide] which explains this process.

=== Step 2 ===

Next, you will need to upgrade two components of TinyOS. Get the latest packages of nesC (<code>nesc-xxx-cygwin.i386.rpm</code>) and TinyOS-Tools (<code>tinyos-tools-xxx-cygwin.i386.rpm</code>) from the [http://www.tinyos.net/dist-2.1.0/tinyos/windows/ TinyOS Web site] and download them into your Cygwin home directory. Then in a Cygwin window, run:

<pre>
rpm -Uvh --ignoreos ~/nesc-xxx-cygwin.i386.rpm ~/tinyos-tools-xxx-cygwin.i386.rpm
</pre>

=== Step 3 ===

You will need to two edit TinyOS files. Open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\beta\platform\imote2\.platform</code> in a text editor. Line 12 should say:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
</pre>

Remove the part that read <code>gcc=xscale-elf-gcc</code> from the end of this line, so that it now says:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true";
</pre>

Then, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\contrib\imote2\tos\sensorboards\BasicSensorboard\BasicSensorboardAccelDataM.nc</code> in a text editor. Line 20 should say:

<pre>
#define SPEED 0
</pre>

Change the <code>0</code> to a <code>1</code>, so that it now says:

<pre>
#define SPEED 1
</pre>

=== Step 4 ===

Finally, install the WS2 software. Download the WS2 package from [[Structural Health Monitoring|this page]] to your Cygwin home directory. Then run:

<pre>
cd $TOSROOT/apps
unzip ~/Ws2_*.zip
</pre>

You can test your setup by running:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

If everything was installed correctly, then the last line printed after running these commands will say "<code>dwarf2bd -nc build/imote2/main.exe</code>".

== Sensor Calibration ==

The frequency at which each sensorboard collects vibration samples may vary by as much as 10%. In the current version of WS2, you must manually calibrate each sensorboard by collecting its "actual" frequency ahead-of-time.

You can measure this frequency using an oscilloscope and TinyOS's <code>TestSensorboard</code> application.

=== Step 1 ===

Attach the sensorboard to the iMote2. Orient the iMote2 so that the sensorboard is on top, as shown in the photo below. Attach the oscilloscope's probe to the pin circled on the photo below.

[[Image:imote2-pin1.jpg|thumb|none|Click for full-size image]]

=== Step 2 ===

Install and run the <code>TestSensorboard</code> application on the iMote2 as described here: [[Testing the Imote2 Sensor Board]]

=== Step 3 ===

After running the <code>StartCollection</code> command, the iMote2 will begin collecting sensor data for about one second. Each time it samples the accelerometer, there will be a pulse on the pin that you attached the probe to, like shown below:

[[Image:ws2-oscilloscope.png]]

Use the oscilloscope to measure the frequency of this pulse. It should be approximately 560 Hz, +/- 10%. Record this measurement.

You will also want to record the ID of the iMote2 attached to the sensorboard. You can find this ID by reading the last two digits of the serial number sticker found on the bottom of the iMote2 board:

[[Image:imote2-serial.jpg|thumb|none|Click for full-size image]]

== Base Station Setup ==

You will need to use one iMote2 to communicate wirelessly with the other iMote2s in the network. We will refer to this mote as the "base station". Install the base station code on this mote by attaching the iMote2 to your PC, and then running:

<pre>
cd $TOSROOT/apps/TOSBase
make imote2
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== Sensor Node Setup ==

Next, you will need to install the WS2 software on the nodes that you will attach to the structure. Run the following command once:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

For each mote you want attached to the structure, plug it into your PC and run this command:

<pre>
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== DLAC Parameters ==

To set up the parameters to the DLAC algorithm, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\apps\WS2-ARQ\java\ws2.properties</code> in a text editor.

Each line in this file with an "<code>=</code>" represents one DLAC parameter. Each of these parameters has a line above it starting with a "<code>#</code>" that describes what the parameter means. Change the <code>W_EH</code>, <code>W_AH</code>, <code>W_AD</code>, and <code>numNodes</code> parameters to match the values computed offline.

Below this, there is a section in the file that looks like this:

<pre>
# Mote addresses (base-16)
motes = 75, 46, 44
# Corresponding Measured sampling frequencies
frequencies = 598.8, 552.5, 586.5
</pre>

This is where the calibration information is placed. Change the <code>motes =</code> line so that it lists the IDs on the bottom of each mote you calibrated. Separate each ID by a comma. Then, change the <code>frequencies =</code> line to list the sampling frequency that you measured during the calibration step. Again, separate each frequency by a comma.

For example, if you have a mote with the ID 45 and a sampling frequency of 545.8 Hz, and another mote with the ID 76 and a sampling frequency of 575.6 Hz, then change these lines to read:

<pre>
# Mote addresses (base-16)
motes = 45, 76
# Corresponding Measured sampling frequencies
frequencies = 545.8, 575.6
</pre>

Once you have completed these steps, the WS2 system is set up and ready to be deployed.

WS2 Installation Instructions

2008-12-08T19:47:32Z

Gwh2: /* Step 1 */

Installing WS2 is a multi-step process that involves setting up several software tools and performing some sensor calibration. This document is designed to walk you through this process. These instructions assume that you have a PC running a recent version of Windows (Windows 2000, XP, or Vista) and know how to use a text editor like [http://www.textpad.com/ TextPad] or [http://notepad-plus.sourceforge.net/ Notepad++].

You will need to use a text editor application which supports "UNIX-style" line endings. Most text editor applications support this feature. Unfortunately, the Notepad application included with Windows does not. [http://notepad-plus.sourceforge.net/ Notepad++] is a free alternative to Notepad which will work with this tutorial.

== TinyOS Setup ==

=== Step 1 ===

You will first need to install TinyOS 1.1 and add support for the iMote2 platform. The Structural Health Monitoring group at UIUC has created a helpful [http://shm.cs.uiuc.edu/imotestart.html "Getting Started" guide] which explains this process.

=== Step 2 ===

Next, you will need to upgrade two components of TinyOS. Get the latest packages of nesC (<code>nesc-xxx-cygwin.i386.rpm</code>) and TinyOS-Tools (<code>tinyos-tools-xxx-cygwin.i386.rpm</code>) from the [http://www.tinyos.net/dist-2.1.0/tinyos/windows/ TinyOS Web site] and download them into your Cygwin home directory. Then in a Cygwin window, run:

<pre>
rpm -Uvh --ignoreos ~/nesc-xxx-cygwin.i386.rpm ~/tinyos-tools-xxx-cygwin.i386.rpm
</pre>

=== Step 3 ===

You will need to two edit TinyOS files. Open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\beta\platform\imote2\.platform</code> in a text editor. Line 12 should say:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
</pre>

Remove the part that read <code>gcc=xscale-elf-gcc</code> from the end of this line, so that it now says:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true";
</pre>

Then, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\contrib\imote2\tos\sensorboards\BasicSensorboard\BasicSensorboardAccelDataM.nc</code> in a text editor. Line 20 should say:

<pre>
#define SPEED 0
</pre>

Change the <code>0</code> to a <code>1</code>, so that it now says:

<pre>
#define SPEED 1
</pre>

=== Step 4 ===

Finally, install the WS2 software. Download the WS2 package from [[Structural Health Monitoring|this page]] to your Cygwin home directory. Then run:

<pre>
cd $TOSROOT/apps
unzip ~/Ws2_*.zip
</pre>

You can test your setup by running:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

If everything was installed correctly, then the last line printed after running these commands will say "<code>dwarf2bd -nc build/imote2/main.exe</code>".

== Sensor Calibration ==

The frequency at which each sensorboard collects vibration samples may vary by as much as 10%. In the current version of WS2, you must manually calibrate each sensorboard by collecting its "actual" frequency ahead-of-time.

You can measure this frequency using an oscilloscope and TinyOS's <code>TestSensorboard</code> application.

=== Step 1 ===

Attach the sensorboard to the iMote2. Orient the iMote2 so that the sensorboard is on top, as shown in the photo below. Attach the oscilloscope's probe to the pin circled on the photo below.

[[Image:imote2-pin1.jpg]]

=== Step 2 ===

Install and run the <code>TestSensorboard</code> application on the iMote2 as described here: [[Testing the Imote2 Sensor Board]]

=== Step 3 ===

After running the <code>StartCollection</code> command, the iMote2 will begin collecting sensor data for about one second. Each time it samples the accelerometer, there will be a pulse on the pin that you attached the probe to, like shown below:

[[Image:ws2-oscilloscope.png]]

Use the oscilloscope to measure the frequency of this pulse. It should be approximately 560 Hz, +/- 10%. Record this measurement.

You will also want to record the ID of the iMote2 attached to the sensorboard. You can find this ID by reading the last two digits of the serial number sticker found on the bottom of the iMote2 board:

[[Image:imote2-serial.jpg|thumb|none|Click for full-size image]]

== Base Station Setup ==

You will need to use one iMote2 to communicate wirelessly with the other iMote2s in the network. We will refer to this mote as the "base station". Install the base station code on this mote by attaching the iMote2 to your PC, and then running:

<pre>
cd $TOSROOT/apps/TOSBase
make imote2
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== Sensor Node Setup ==

Next, you will need to install the WS2 software on the nodes that you will attach to the structure. Run the following command once:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

For each mote you want attached to the structure, plug it into your PC and run this command:

<pre>
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== DLAC Parameters ==

To set up the parameters to the DLAC algorithm, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\apps\WS2-ARQ\java\ws2.properties</code> in a text editor.

Each line in this file with an "<code>=</code>" represents one DLAC parameter. Each of these parameters has a line above it starting with a "<code>#</code>" that describes what the parameter means. Change the <code>W_EH</code>, <code>W_AH</code>, <code>W_AD</code>, and <code>numNodes</code> parameters to match the values computed offline.

Below this, there is a section in the file that looks like this:

<pre>
# Mote addresses (base-16)
motes = 75, 46, 44
# Corresponding Measured sampling frequencies
frequencies = 598.8, 552.5, 586.5
</pre>

This is where the calibration information is placed. Change the <code>motes =</code> line so that it lists the IDs on the bottom of each mote you calibrated. Separate each ID by a comma. Then, change the <code>frequencies =</code> line to list the sampling frequency that you measured during the calibration step. Again, separate each frequency by a comma.

For example, if you have a mote with the ID 45 and a sampling frequency of 545.8 Hz, and another mote with the ID 76 and a sampling frequency of 575.6 Hz, then change these lines to read:

<pre>
# Mote addresses (base-16)
motes = 45, 76
# Corresponding Measured sampling frequencies
frequencies = 545.8, 575.6
</pre>

Once you have completed these steps, the WS2 system is set up and ready to be deployed.

WS2 Installation Instructions

2008-12-08T19:45:34Z

Gwh2: /* Step 3 */

Installing WS2 is a multi-step process that involves setting up several software tools and performing some sensor calibration. This document is designed to walk you through this process. These instructions assume that you have a PC running a recent version of Windows (Windows 2000, XP, or Vista) and know how to use a text editor like [http://www.textpad.com/ TextPad] or [http://notepad-plus.sourceforge.net/ Notepad++].

You will need to use a text editor application which supports "UNIX-style" line endings. Most text editor applications support this feature. Unfortunately, the Notepad application included with Windows does not. [http://notepad-plus.sourceforge.net/ Notepad++] is a free alternative to Notepad which will work with this tutorial.

== TinyOS Setup ==

=== Step 1 ===

You will first need to install TinyOS 1.1 and add support for the iMote2 platform. The Structural Health Monitoring group at UIUC has created a helpful [http://shm.cs.uiuc.edu/imotestart.html "Getting Started" guide] which explains this process.

=== Step 2 ===

Next, you will need to upgrade two components of TinyOS. Get the latest packages of nesC (<code>nesc-xxx-cygwin.i386.rpm</code>) and TinyOS-Tools (<code>tinyos-tools-xxx-cygwin.i386.rpm</code>) from the [http://www.tinyos.net/dist-2.1.0/tinyos/windows/ TinyOS Web site] and download them into your Cygwin home directory. Then in a Cygwin window, run:

<pre>
rpm -Uvh --ignoreos ~/nesc-xxx-cygwin.i386.rpm ~/tinyos-tools-xxx-cygwin.i386.rpm
</pre>

=== Step 3 ===

You will need to two edit TinyOS files. Open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\beta\platform\imote2\.platform</code> in a text editor. Line 12 should say:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
</pre>

Remove the part that read <code>gcc=xscale-elf-gcc</code> from the end of this line, so that it now says:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true";
</pre>

Then, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\contrib\imote2\tos\sensorboards\BasicSensorboard\BasicSensorboardAccelDataM.nc</code> in a text editor. Line 20 should say:

<pre>
#define SPEED 0
</pre>

Change the <code>0</code> to a <code>1</code>, so that it now says:

<pre>
#define SPEED 1
</pre>

=== Step 4 ===

Finally, install the WS2 software. Download the WS2 package from [[Structural Health Monitoring|this page]] to your Cygwin home directory. Then run:

<pre>
cd $TOSROOT/apps
unzip ~/Ws2_*.zip
</pre>

You can test your setup by running:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

If everything was installed correctly, then the last line printed after running these commands will say "<code>dwarf2bd -nc build/imote2/main.exe</code>".

== Sensor Calibration ==

The frequency at which each sensorboard collects vibration samples may vary by as much as 10%. In the current version of WS2, you must manually calibrate each sensorboard by collecting its "actual" frequency ahead-of-time.

You can measure this frequency using an oscilloscope and TinyOS's <code>TestSensorboard</code> application.

=== Step 1 ===

Attach the sensorboard to the iMote2. Orient the iMote2 so that the sensorboard is on top, as shown in the photo below. Attach the oscilloscope's probe to the pin circled on the photo below.

[[Image:imote2-pin31.jpg]]

=== Step 2 ===

Install and run the <code>TestSensorboard</code> application on the iMote2 as described here: [[Testing the Imote2 Sensor Board]]

=== Step 3 ===

After running the <code>StartCollection</code> command, the iMote2 will begin collecting sensor data for about one second. Each time it samples the accelerometer, there will be a pulse on the pin that you attached the probe to, like shown below:

[[Image:ws2-oscilloscope.png]]

Use the oscilloscope to measure the frequency of this pulse. It should be approximately 560 Hz, +/- 10%. Record this measurement.

You will also want to record the ID of the iMote2 attached to the sensorboard. You can find this ID by reading the last two digits of the serial number sticker found on the bottom of the iMote2 board:

[[Image:imote2-serial.jpg|thumb|none|Click for full-size image]]

== Base Station Setup ==

You will need to use one iMote2 to communicate wirelessly with the other iMote2s in the network. We will refer to this mote as the "base station". Install the base station code on this mote by attaching the iMote2 to your PC, and then running:

<pre>
cd $TOSROOT/apps/TOSBase
make imote2
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== Sensor Node Setup ==

Next, you will need to install the WS2 software on the nodes that you will attach to the structure. Run the following command once:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

For each mote you want attached to the structure, plug it into your PC and run this command:

<pre>
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== DLAC Parameters ==

To set up the parameters to the DLAC algorithm, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\apps\WS2-ARQ\java\ws2.properties</code> in a text editor.

Each line in this file with an "<code>=</code>" represents one DLAC parameter. Each of these parameters has a line above it starting with a "<code>#</code>" that describes what the parameter means. Change the <code>W_EH</code>, <code>W_AH</code>, <code>W_AD</code>, and <code>numNodes</code> parameters to match the values computed offline.

Below this, there is a section in the file that looks like this:

<pre>
# Mote addresses (base-16)
motes = 75, 46, 44
# Corresponding Measured sampling frequencies
frequencies = 598.8, 552.5, 586.5
</pre>

This is where the calibration information is placed. Change the <code>motes =</code> line so that it lists the IDs on the bottom of each mote you calibrated. Separate each ID by a comma. Then, change the <code>frequencies =</code> line to list the sampling frequency that you measured during the calibration step. Again, separate each frequency by a comma.

For example, if you have a mote with the ID 45 and a sampling frequency of 545.8 Hz, and another mote with the ID 76 and a sampling frequency of 575.6 Hz, then change these lines to read:

<pre>
# Mote addresses (base-16)
motes = 45, 76
# Corresponding Measured sampling frequencies
frequencies = 545.8, 575.6
</pre>

Once you have completed these steps, the WS2 system is set up and ready to be deployed.

WS2 Installation Instructions

2008-12-08T19:44:15Z

Gwh2: /* Step 3 */

Installing WS2 is a multi-step process that involves setting up several software tools and performing some sensor calibration. This document is designed to walk you through this process. These instructions assume that you have a PC running a recent version of Windows (Windows 2000, XP, or Vista) and know how to use a text editor like [http://www.textpad.com/ TextPad] or [http://notepad-plus.sourceforge.net/ Notepad++].

You will need to use a text editor application which supports "UNIX-style" line endings. Most text editor applications support this feature. Unfortunately, the Notepad application included with Windows does not. [http://notepad-plus.sourceforge.net/ Notepad++] is a free alternative to Notepad which will work with this tutorial.

== TinyOS Setup ==

=== Step 1 ===

You will first need to install TinyOS 1.1 and add support for the iMote2 platform. The Structural Health Monitoring group at UIUC has created a helpful [http://shm.cs.uiuc.edu/imotestart.html "Getting Started" guide] which explains this process.

=== Step 2 ===

Next, you will need to upgrade two components of TinyOS. Get the latest packages of nesC (<code>nesc-xxx-cygwin.i386.rpm</code>) and TinyOS-Tools (<code>tinyos-tools-xxx-cygwin.i386.rpm</code>) from the [http://www.tinyos.net/dist-2.1.0/tinyos/windows/ TinyOS Web site] and download them into your Cygwin home directory. Then in a Cygwin window, run:

<pre>
rpm -Uvh --ignoreos ~/nesc-xxx-cygwin.i386.rpm ~/tinyos-tools-xxx-cygwin.i386.rpm
</pre>

=== Step 3 ===

You will need to two edit TinyOS files. Open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\beta\platform\imote2\.platform</code> in a text editor. Line 12 should say:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
</pre>

Remove the part that read <code>gcc=xscale-elf-gcc</code> from the end of this line, so that it now says:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true";
</pre>

Then, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\contrib\imote2\tos\sensorboards\BasicSensorboard\BasicSensorboardAccelDataM.nc</code> in a text editor. Line 20 should say:

<pre>
#define SPEED 0
</pre>

Change the <code>0</code> to a <code>1</code>, so that it now says:

<pre>
#define SPEED 1
</pre>

=== Step 4 ===

Finally, install the WS2 software. Download the WS2 package from [[Structural Health Monitoring|this page]] to your Cygwin home directory. Then run:

<pre>
cd $TOSROOT/apps
unzip ~/Ws2_*.zip
</pre>

You can test your setup by running:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

If everything was installed correctly, then the last line printed after running these commands will say "<code>dwarf2bd -nc build/imote2/main.exe</code>".

== Sensor Calibration ==

The frequency at which each sensorboard collects vibration samples may vary by as much as 10%. In the current version of WS2, you must manually calibrate each sensorboard by collecting its "actual" frequency ahead-of-time.

You can measure this frequency using an oscilloscope and TinyOS's <code>TestSensorboard</code> application.

=== Step 1 ===

Attach the sensorboard to the iMote2. Orient the iMote2 so that the sensorboard is on top, as shown in the photo below. Attach the oscilloscope's probe to the pin circled on the photo below.

[[Image:imote2-pin31.jpg]]

=== Step 2 ===

Install and run the <code>TestSensorboard</code> application on the iMote2 as described here: [[Testing the Imote2 Sensor Board]]

=== Step 3 ===

After running the <code>StartCollection</code> command, the iMote2 will begin collecting sensor data for about one second. Each time it samples the accelerometer, there will be a pulse on the pin that you attached the probe to, like shown below:

[[Image:ws2-oscilloscope.png]]

Use the oscilloscope to measure the frequency of this pulse. It should be approximately 560 Hz, +/- 10%. Record this measurement.

You will also want to record the ID of the iMote2 attached to the sensorboard. You can find this ID by reading the last two digits of the serial number sticker found on the bottom of the iMote2 board:

[[Image:imote2-serial.jpg|thumb|left|Click for full-size image]]

== Base Station Setup ==

You will need to use one iMote2 to communicate wirelessly with the other iMote2s in the network. We will refer to this mote as the "base station". Install the base station code on this mote by attaching the iMote2 to your PC, and then running:

<pre>
cd $TOSROOT/apps/TOSBase
make imote2
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== Sensor Node Setup ==

Next, you will need to install the WS2 software on the nodes that you will attach to the structure. Run the following command once:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

For each mote you want attached to the structure, plug it into your PC and run this command:

<pre>
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== DLAC Parameters ==

To set up the parameters to the DLAC algorithm, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\apps\WS2-ARQ\java\ws2.properties</code> in a text editor.

Each line in this file with an "<code>=</code>" represents one DLAC parameter. Each of these parameters has a line above it starting with a "<code>#</code>" that describes what the parameter means. Change the <code>W_EH</code>, <code>W_AH</code>, <code>W_AD</code>, and <code>numNodes</code> parameters to match the values computed offline.

Below this, there is a section in the file that looks like this:

<pre>
# Mote addresses (base-16)
motes = 75, 46, 44
# Corresponding Measured sampling frequencies
frequencies = 598.8, 552.5, 586.5
</pre>

This is where the calibration information is placed. Change the <code>motes =</code> line so that it lists the IDs on the bottom of each mote you calibrated. Separate each ID by a comma. Then, change the <code>frequencies =</code> line to list the sampling frequency that you measured during the calibration step. Again, separate each frequency by a comma.

For example, if you have a mote with the ID 45 and a sampling frequency of 545.8 Hz, and another mote with the ID 76 and a sampling frequency of 575.6 Hz, then change these lines to read:

<pre>
# Mote addresses (base-16)
motes = 45, 76
# Corresponding Measured sampling frequencies
frequencies = 545.8, 575.6
</pre>

Once you have completed these steps, the WS2 system is set up and ready to be deployed.

File:Imote2-serial.jpg

2008-12-08T19:42:57Z

Gwh2:

WS2 Installation Instructions

2008-12-08T19:42:48Z

Gwh2: /* Step 3 */

Installing WS2 is a multi-step process that involves setting up several software tools and performing some sensor calibration. This document is designed to walk you through this process. These instructions assume that you have a PC running a recent version of Windows (Windows 2000, XP, or Vista) and know how to use a text editor like [http://www.textpad.com/ TextPad] or [http://notepad-plus.sourceforge.net/ Notepad++].

You will need to use a text editor application which supports "UNIX-style" line endings. Most text editor applications support this feature. Unfortunately, the Notepad application included with Windows does not. [http://notepad-plus.sourceforge.net/ Notepad++] is a free alternative to Notepad which will work with this tutorial.

== TinyOS Setup ==

=== Step 1 ===

You will first need to install TinyOS 1.1 and add support for the iMote2 platform. The Structural Health Monitoring group at UIUC has created a helpful [http://shm.cs.uiuc.edu/imotestart.html "Getting Started" guide] which explains this process.

=== Step 2 ===

Next, you will need to upgrade two components of TinyOS. Get the latest packages of nesC (<code>nesc-xxx-cygwin.i386.rpm</code>) and TinyOS-Tools (<code>tinyos-tools-xxx-cygwin.i386.rpm</code>) from the [http://www.tinyos.net/dist-2.1.0/tinyos/windows/ TinyOS Web site] and download them into your Cygwin home directory. Then in a Cygwin window, run:

<pre>
rpm -Uvh --ignoreos ~/nesc-xxx-cygwin.i386.rpm ~/tinyos-tools-xxx-cygwin.i386.rpm
</pre>

=== Step 3 ===

You will need to two edit TinyOS files. Open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\beta\platform\imote2\.platform</code> in a text editor. Line 12 should say:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
</pre>

Remove the part that read <code>gcc=xscale-elf-gcc</code> from the end of this line, so that it now says:

<pre>
$ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4 short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4 wchar_size_size=4,4 char_wchar_signed=false,true";
</pre>

Then, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\contrib\imote2\tos\sensorboards\BasicSensorboard\BasicSensorboardAccelDataM.nc</code> in a text editor. Line 20 should say:

<pre>
#define SPEED 0
</pre>

Change the <code>0</code> to a <code>1</code>, so that it now says:

<pre>
#define SPEED 1
</pre>

=== Step 4 ===

Finally, install the WS2 software. Download the WS2 package from [[Structural Health Monitoring|this page]] to your Cygwin home directory. Then run:

<pre>
cd $TOSROOT/apps
unzip ~/Ws2_*.zip
</pre>

You can test your setup by running:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

If everything was installed correctly, then the last line printed after running these commands will say "<code>dwarf2bd -nc build/imote2/main.exe</code>".

== Sensor Calibration ==

The frequency at which each sensorboard collects vibration samples may vary by as much as 10%. In the current version of WS2, you must manually calibrate each sensorboard by collecting its "actual" frequency ahead-of-time.

You can measure this frequency using an oscilloscope and TinyOS's <code>TestSensorboard</code> application.

=== Step 1 ===

Attach the sensorboard to the iMote2. Orient the iMote2 so that the sensorboard is on top, as shown in the photo below. Attach the oscilloscope's probe to the pin circled on the photo below.

[[Image:imote2-pin31.jpg]]

=== Step 2 ===

Install and run the <code>TestSensorboard</code> application on the iMote2 as described here: [[Testing the Imote2 Sensor Board]]

=== Step 3 ===

After running the <code>StartCollection</code> command, the iMote2 will begin collecting sensor data for about one second. Each time it samples the accelerometer, there will be a pulse on the pin that you attached the probe to, like shown below:

[[Image:ws2-oscilloscope.png]]

Use the oscilloscope to measure the frequency of this pulse. It should be approximately 560 Hz, +/- 10%. Record this measurement.

You will also want to record the ID of the iMote2 attached to the sensorboard. You can find this ID by reading the last two digits of the serial number sticker found on the bottom of the iMote2 board:

[[Image:imote2-serial.jpg]]

== Base Station Setup ==

You will need to use one iMote2 to communicate wirelessly with the other iMote2s in the network. We will refer to this mote as the "base station". Install the base station code on this mote by attaching the iMote2 to your PC, and then running:

<pre>
cd $TOSROOT/apps/TOSBase
make imote2
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== Sensor Node Setup ==

Next, you will need to install the WS2 software on the nodes that you will attach to the structure. Run the following command once:

<pre>
cd $TOSROOT/apps/WS2-ARQ
make imote2
</pre>

For each mote you want attached to the structure, plug it into your PC and run this command:

<pre>
USBLoaderHost.exe -p build/imote2/main.bin.out
</pre>

== DLAC Parameters ==

To set up the parameters to the DLAC algorithm, open the file <code>C:\tinyos\cygwin\opt\tinyos-cvs\apps\WS2-ARQ\java\ws2.properties</code> in a text editor.

Each line in this file with an "<code>=</code>" represents one DLAC parameter. Each of these parameters has a line above it starting with a "<code>#</code>" that describes what the parameter means. Change the <code>W_EH</code>, <code>W_AH</code>, <code>W_AD</code>, and <code>numNodes</code> parameters to match the values computed offline.

Below this, there is a section in the file that looks like this:

<pre>
# Mote addresses (base-16)
motes = 75, 46, 44
# Corresponding Measured sampling frequencies
frequencies = 598.8, 552.5, 586.5
</pre>

This is where the calibration information is placed. Change the <code>motes =</code> line so that it lists the IDs on the bottom of each mote you calibrated. Separate each ID by a comma. Then, change the <code>frequencies =</code> line to list the sampling frequency that you measured during the calibration step. Again, separate each frequency by a comma.

For example, if you have a mote with the ID 45 and a sampling frequency of 545.8 Hz, and another mote with the ID 76 and a sampling frequency of 575.6 Hz, then change these lines to read:

<pre>
# Mote addresses (base-16)
motes = 45, 76
# Corresponding Measured sampling frequencies
frequencies = 545.8, 575.6
</pre>

Once you have completed these steps, the WS2 system is set up and ready to be deployed.