A Smart Wireless Sensor Network

Department of Computer Science and Engineering, Arizona State University

Faculty Advisor

Sandeep K.S. Gupta
Associate Professor
Department of Computer Science and Engineering
Arizona State University



Edward Raleigh

iMPACT Research Lab

Arizona State University




Monitoring is important.  Monitors at the border help warn of intruding illegal immigrants, there are monitors for earthquakes and volcanoes to warn of impending danger, astronauts rely on monitors for their oxygen levels, even on a day to day basis fire alarms are constantly monitoring homes.  Monitors have a variety of uses and currently need to be developed on an individual basis for each application they are used in.  What if, however, there was one type of monitor that could be used in any application?  The emerging technology of wireless sensor networks has made this possible.  The problem is, however, that the individuals who need these sensor networks the most, rarely have the knowledge to program them.  As a solution, a smart wireless sensor network system (SWiSN) has been developed with ease of setup by anyone as a goal.  Current SWiSN functionality, the development process, system performance, and future applications of the system are described in this paper.


Table of Contents       






5.1       Decide on Hardware Platform for Sensor Network Setup

5.2       Develop TelosB Sensing Program

5.3       Create New C# GUI for End User PDA Application

5.4       Create Java Applet


6.1       Testing

6.2       Data Analysis

6.3       Discussion

6.4       Other Performance Data


7.1       Data History Download

7.2       Emergency Email Values

7.3       Reading Frequency Adjustment

7.4       Cellular Network Connection

7.5       Out of Box SWiSN




A.        FURI Poster Presentation

B.        Hardware PowerPoint

C.        SWiSN Code


The idea of the SWiSN originated in Dr. Sandeep Gupta’s lab last year during a secure container project.  The containers were large metal boxes used to transport goods.  As a part of this project, a sensor network was needed which could track containers and their environmental properties such as ambient temperature, humidity, and light levels all in real time. After carefully considering how this sensor network should ideally be developed, it was decided that the network should be ‘smart’ in the sense that it should be:

Easy to Use

  • Configurable: incorporate a simple user interface for system configuration.

  • Deployable: allow the sensor network to function from locations around the globe.

  • Accessible: supply easy access to historical and live data.

  • Flexible: allow for dynamic change in the system setup.

Performance Oriented

  • Energy Efficient: maximize the sensor network life time.

  • Reliable: minimize data loss.

These ‘smart’ features are desirable in almost all sensor networks and therefore have been included in the development of the SWiSN. Commercially available wireless hardware modules have been used for the sensing and networking components.  Software tools were engineered to help implement the ‘smart’ features within the hardware.  Programs for researchers to interact with the SWiSN locally, as well as remotely through the Internet have been developed.

Any researcher who needs a wireless sensor network to monitor an environment can use the SWiSN.  From using it as a part of the secure container project, to deploying it on a battlefield for real time data collection, applications of the SWiSN are limitless.


The Tiny Application Sensor Kit (TASK) project [1], which was published in 2005, attempted to develop an environmental wireless sensor network which could be easily setup by someone without expertise in computer science.  Two separate test scenarios were carried out and examined in this project.  While the results of these trials were useful to the development of the SWiSN (i.e. the concept of keeping the system as simple as possible) no details were given on the complexity or simplicity of setting up the network for real world deployment.  With the SWiSN, however, all components are pre-programmed so any experiment can be set up by placing the components in a testing environment and simply turning them on; the system will take care of the rest. 

The work of Arp and Nickerson [2], focuses on developing a Sensor Web Language (SWL) Toolkit which aims to, “provide a greater level of simplicity in deployment than TASK”.  In this project, each network is assumed to have a specific designer which must, “install the network tool chains, learn to use the Eclipse GUI and SWL programming language to define their WSN”.  Clearly, even though this paper attempts to achieve simpler deployment than TASK, computer science expertise is required.

Other research in this area, such as the environmental monitoring of birds on the Great Duck Island [3], consists of a team of computer scientists collaborating with researchers in other areas to carry out experiments.  In such cases, computer science expertise is essential for sensor network deployment.



Currently, two customizable, environmental, and wireless sensor network systems are commercially available to the public.  Both products are similar to the SWiSN in that they allow end users to view live environmental data through the internet after setting up the network.  The product from Arch Rock Company [4] (founded in 2005) is different from the SWiSN in that it is more configurable by the end user, with features such as over the air programming.  The cheapest Arch Rock package consists of six sensing nodes and a base station at a total cost of $3,996.  Additional sensing nodes can be added for $220 each (this pricing information is not currently available on their website but was obtained through email contact with a sales representative from the company).  The other commercially available sensor network, Crossbow eKo Pro Series [5], began shipping in April of 2008.  It consists of sensing nodes with more sensors than either the SWiSN or the Arch Rock product (in addition to light, temperature, and humidity, the eKo includes soil moisture sensors).  According to their site, eKo takes hours to initially setup and comes at a price of $3,359 for a basic system with three sensor nodes and a base station; extra eKo sensor nodes run at $569 each.   

When compared to the SWiSN, both of the commercially available sensor networks appear costly and take longer to setup.  As previously mentioned, the Arch Rock product, with six sensor nodes, runs at $3,996.  A similar setup (one with a base station and six sensing nodes) using the eKo Pro Series product would cost $5,103.  The SWiSN, which is capable of taking all the same types of readings as the Arch Rock product and most of the reading types of the eKo Pro Series, would only run at $1,450 with $100 for each additional sensing node.  Also, setup of the SWiSN takes a matter of minutes as opposed to the hour(s) required for either commercially available product.



At the half-way point of this project, the Smart Wireless Sensor Network (SWiSN) was sending out signals from the sensors, through the Stargate server, and to an end user’s PDA over an ad-hoc TCP/IP connection (see Appendix A for further details).  The problem with this setup is that only PDA’s with the specific software pre-installed on them were able to view live sensor data.  Recently, the focus of this project has been on developing a Java applet and installing an Apache web server onto the Stargate.  One-way communication from the sensors to an end user Java applet via the Apache web server on the Stargate has since been created.  What this means is that the wireless sensor network can be setup anywhere in the world where there is an internet connection, and upload data to the internet.  From the internet, any user can connect with any Java applet supporting platform (whether it be a cell phone, PDA, laptop, or desktop computer) and view the live data streaming through the network.  One advantage of this new setup is that it requires no software to be installed on the end user’s hardware, since all data is displayed through a Java applet (with the exception that the end user has hardware with Java applet support already on it). 

The current setup (shown in Figure 1) allows sensor readings of humidity, temperature, light, and voltage to be sent from the TelosB motes (sensing motes which take the readings) at each sensing interval, through the Stargate, to a Java applet and/or a pre-installed PDA application.  Energy efficiency has been implemented on the TelosB motes by powering down all hardware resources when not in use (i.e. each time the TelosB sends a message, it turns on its sensors and radio, takes the readings, sends the readings, and then turns everything back off except for a timer).  This strategy increases the lifetime of the TelosB motes from a few days to over a few months.  The system is configurable and flexible in the sense that any number of TelosB motes can be present at the commencement of an experiment and, during an experiment’s lifetime, new TelosB motes can be added or existing ones can be removed without creating problems.  The system can be deployed and accessed anywhere with a wireless internet connection. It implements handshaking to ensure reliable connections are established.


Figure 1: The Current SWiSN Setup



At the start of this project a working base station (the Stargate), a few PDAs with a basic PDA GUI application, and some TelosB motes were provided by the Impact lab.  The provided Stargate and PDAs were already able to communicate with each other wirelessly.  From this point, the hardware setup for the entire system was decided upon.  A sensing program for the TelosB motes was then developed.  Finally, a new C# GUI for the PDA was created in addition to a Java applet for displaying information to the end user.  Details of the SWiSN development process are outlined below.

5.1        Decide on Hardware Platform for Sensor Network Setup

To decide on a hardware platform for the sensor network, a PowerPoint presentation was developed and presented to a group of graduate students as well as the thesis advisor. The original idea was to develop something adaptable to future changes. Ultimately, it was decided to stick with hardware available in the lab for cost efficiency and so the project could commence immediately (see Appendix B for details regarding all setup options, costs, and advantages/disadvantages).  A server/client oriented setup for the Stargate Server (shown in Figure 2) is an example of a more advanced implementation idea which could not be tested due to time constraints.  Weeks were spent in the analysis and preparation of various hardware platform options for the sensor network. Ultimately, however, the use of a simple design with hardware already available in the lab was decided upon.  While planning is important, when a project actually needs to be developed ease of implementation should be given priority (a simple prototype can be expanded where as a complex system, which should work in theory, may be nearly impossible to implement). 


Figure 2: A Server/Client Oriented Stargate Setup


5.2        Develop TelosB Sensing Program

Before developing a sensing program for the TelosB motes, it was necessary to install and learn the language of the motes.  This was accomplished by following a basic mote programming tutorial (available at: http://www.tinyos.net/tinyos-1.x/doc/tutorial/) until the TinyOS operating system, Cygwin, and nesC were working on the lab machine.   Furthermore, handshaking code was added to ensure a reliable connection with the Stargate is made each time a sensing mote is turned on (see Figure 3 below to view a nesC code sample which includes some of the handshaking code).  In developing the sensing program actually used in the SWiSN, a sample program from the nesC tutorial, Oscilloscope, was heavily modified.  It was setup in such a way that the motes would be energy efficient and sensor reading frequency could easily be changed within the code.  In addition to developing a TelosB sensing program, a MICAz sensing program was also modified (MICAz, like TelosB, are sensing motes which take and transmit readings) so that MICAz motes could be used with the SWiSN in an energy efficient manner.  While the MICAz sensor readings were configured to work with the new C# PDA GUI, there was not time to implement them in the Java applet application.


Figure 3: NesC Handshaking Code


5.3        Create New C# GUI for End User PDA Application

To develop a new GUI for the PDA it was necessary to learn and use C#.  Using the Visual Studio 2005 programming environment, the older version of the PDA GUI application was modified and uploaded to the PDA for testing purposes.  A lot of time was spent trying to understand the existing C# GUI before necessary changes could be made and a new version of the software could be implemented on the PDA (shown in Figure 4 below).  This new GUI was important because it allows the end user to single out a mote within the sensor network and view only those readings.  Furthermore, it gives a side-scrolling view of the mote’s past three messages so recent data can easily be viewed.



Figure 4: Old PDA GUI (left) and New PDA GUI (right)


5.4        Create Java Applet

In order to implement the Java applet (shown in Figure 5), it was necessary to translate some of the C# code on the PDA to Java code.  It was also necessary to study the handshaking and data transfer routines (previously developed by a graduate student, Guofeng Deng).  Furthermore, HTML was used to create a web page which opens the Java applet.  NesC code, previously developed for the sensors, was reviewed to ensure the headings and order of the sensor readings were understood.  Eclipse was used to create the Java applet which runs a socket server and makes threads to handle each incoming message.  An Apache web server was installed on the Stargate to host the Java applet.  This Java applet was then uploaded on the Apache web server via the Cygwin application.  One of the main problems faced during this phase of development was trying to handle multiple messages received at one time from separate sensors.  This problem was ultimately resolved by reading the messages in on a buffer; multiple messages were then separated during a message header check within the buffer before new handling threads were created.


Figure 5: Sensor Readings Applet



6.1          Testing

The SWiSN was tested outdoors on a large concrete walkway (shown in Figure 6).  No human or animal interference occurred during the testing procedures.  A TelosB mote was programmed to send 100 sensor reading messages to the Stargate using ZigBee communication.  These readings were then forwarded to the PDA, over an ad-hoc TCP/IP connection, which counted the total number of readings received.  Readings were sent at a frequency of two per second from the TelosB mote to the Stargate.  After the mote was placed, three separate trials of sending 100 messages to the Stargate were conducted. The number of readings received at the PDA and the current temperature sensor reading were recorded after each trial. At the completion of these three trials, the TelosB mote was moved to a new location where it maintained the same orientation with respect to the Stargate but was now at a further or closer distance (it was moved along a straight line extending out from the Stargate and through the last location of the TelosB mote).  The experiment was repeated until the mote had transmitted from a total of six different distances.  This entire process was completed twice, once in the morning when the temperature was cool and once in the afternoon when the temperature was warm.


Figure 6: SWiSN Testing Area


6.2          Data Analysis

 For each completion of the process, the percentage of transissions received on average from a given distance was plotted.  A polynomial tendline was fit to each plot (shown in Figure 7 and Figure 8).  A polynomial trendline was selected because it resulted in the lowest R2 value and contacted the most plotted points out of all trendlines attempted (which included linear, logarithmic, polynomial, power and exponential).  As shown in Figure 7, when it was cooler out (12.66oC) roughly 100% of transmitted mote readings were received by the PDA if the TelosB mote was within 2.5 meters of the Stargate.  When the distance of the transmitting mote surpassed 4.5 meters, however, 0% of the readings were received.  


Figure 7: Transmission Received vs. Distance at 12.66oC


As shown in Figure 8, when it was warmer out (35.47oC) 100% of transmitted mote readings were received by the PDA if the TelosB mote was within about 1.2 meters of the Stargate.  When the distance of the transmitting mote surpassed 4 meters, however, 0% of the readings were received.  


Figure 8: Transmissions Received vs. Distance at 35.47 o


6.3          Discussion

Figure 9 below shows the variation in transmissions received for the cool vs. warm temperature experiments.  Let Tmin denote the minimum transmission range for which 100% of transmissions should be received and Tmax denote the maximum transimssion range where more than 0% of transmissions should be received.  It is evident that Tmin was increased by over a meter when the temperature was cooler.  Furthermore, Tmax was increased by over .5 meters when the temperature was cooler.  These findings demonstrate about a 100% gain for Tmin and a 10% gain for Tmax in the cooler temperature reading set.


Figure 9: Transmissions Received vs. Distance at Two Different Temperatures


6.4          Other Performance Data

  •  Experimental Stargate Lifetime: 5 hours on 4 AA rechargable batteries

  • Experimental TelosB Lifetime (6 readings / minute): Over two months on two AA batteries

  • Indoor Tmax with Stargate connected to power outlet: over 10 meters

  • Theoretical transmission delay for TelosB mote: 1 ms


7.1        Data History Download

This would allow a user viewing the sensor network through the Java applet to download the history of data sent to the Stargate by the TelosB motes.  It would be an easy way to create data backups as well as allow interpretation of the sensor values at any point in an experiment.

7.2        Emergency Email Values

The idea behind this application is to allow the researcher using the SWiSN to set key sensor values; when these key values are surpassed, the researcher will receive an email of the occurrence.  An example of this would be if the researcher set a key low value for temperature at 0oC.  In this case, the first time a temperature reading below 0oC is sensed, the SWiSN sends an email informing the researcher of the occurrence.  Sample code for sending an email through a Unix environment using C (which is the current setup of the Stargate) can be found at http://www.unix.com/high-level-programming/28625-can-we-send-email-c-program-unix.html.  Some small modifications to the existing C code on the Stargate in addition to modifying the Java applet so that parameters could be sent from the applet to the Stargate would be necessary for the implementation of this feature.

7.3        Reading Frequency Adjustment

This feature would allow the researcher to adjust the time interval between readings in real time through the Java applet.  This could be useful if the researcher needed higher resolution of readings during certain periods of the experiment.  If, for example, the researcher was interested in doing a night time experiment of light values, he or she could set up the network during the day with a low frequency (every minute).  Then, when night time approaches, the researcher could change the frequency from home through an internet connection so that every second a reading by the network would be taken.  For this feature to work, the TelosB mote code would need to be modified to listen to commands from the Stargate after sending out a message.  Also, the Java applet and Stargate code would need to be modified so that reading frequency values could be sent form the applet, through the Stargate, to the sensors.

7.4        Cellular Network Connection

This feature would allow the SWiSN to connect to the internet over a cellular network instead of wireless internet.  It would allow the SWiSN to be set up in any location around the world with a connection to the cellular network (a much wider area when compared to just locations with wireless internet access).  Implementing this feature is as easy as purchasing a cellular network card and subscribing to the service.  Once the hardware is installed on the SWiSN, all other components of the SWiSN should still work correctly (since the new underlying hardware provides the same services as the current setup).

7.5        Out of Box SWiSN

Develop user instructions and simplify setup of the SWiSN so that any researcher can easily setup the network without further assistance.  This feature would increase availability of the system to researchers of all fields (as opposed to researchers who have expertise with wireless networks).



This work was supported by the iMPACT Laboratory at ASU, NSF REU CNS #0196156, and the Fulton Undergraduate Research Initiative program.  I would like to thank Guofeng Deng for the use of his Stargate and PDA code.  In addition, I would like to thank Guofeng Deng, Krishna Venkatasubramani, Gianni Giorgetti, Dr. Mutsumi Nakamura, Dr. Georgios Varsamopoulos, and Dr. Sandeep Gupta for their direction and constant support of this project.



[1]   P. Buonadonna, D. Gay, J. M. Hellerstein, W. Hong, and S. Madden. TASK: Sensor network in a box. In Proceedings of the Second IEEE European Workshop on Wireless Sensor Networks and Applications. 2005.

[2]   John-Paul Arp and Bradford G. Nickerson. A user friendly toolkit for building robust environmental sensor networks.  In Proceedings of the Fifth Annual Conference on Communication Networks and Services Research. 2007.

[3]   A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson. Wireless sensor networks for habitat monitoring. In Proceedings of the ACM International Workshop on Wireless Sensor Networks and Applications. 2002.

[4]   http://www.archrock.com/product/

[5]   http://www.xbow.com/eko/eko_shopping.aspx



A.        FURI Poster Presentation

This links to a poster which was created at the half-way point of the SWiSN project. This poster was developed to help inform the public of this project and its current status.

B.        Hardware PowerPoint

This links to a PowerPoint presentation which was developed at the beginning of the SWiSN project to help analyze the cost vs. benefit for potential hardware setups of the SWiSN. 

C.        SWiSN Code

This links to a compilation of code which has been changed or developed in engineering the software of the SWiSN.  A complete copy of all SWiSN code is available here for download. 

Home | Projects | People | Publications | Courses | Resources | Books | News & Visitors | Contact

Last Updated: 16th April 2008