COMP 4203 

Sensor Networking Project Report 

 Team Members: 

Vladimir Menshikov (100840927) Xiao Zhu (100757147) 

 April 10, 2016 

 

 

Submitted to: 

Professor Dr. Michel Barbeau 

COMP 4203 Wireless Networks and Security 

School of Computer Science 

Carleton University 

 

 

 

 

1   Introduction 

1.1   Context 

Wireless Sensor Networking (WSN) is an innovative area within a broad spectrum of 

wireless networks that is specifically designed to measure a small amount of data, that is often 

related to sensor data, and interpret it at a central location [1]. A Wireless Sensor Network is 

composed of nodes that are sensors for gathering information. Some fields of use are security 

monitoring, health care monitoring, environmental data gathering and waste monitoring. It is 

built based on a wireless mesh network topology. Each node is connected to another node that 

is in the end connected to a sink node. Outer nodes are referred to as End Nodes (E). The 

central node that gathers, processes and displays the data is referred to as a Sink Node (SN) or 

a Coordinator (C). And the intermediate nodes that connect the mesh are called Router Nodes 

(R). 

 

Figure 1­1: A Wireless Sensor Network. 

 

 

1.2   Problem Statement 

Wireless Sensor Networks are widely used around the world for data logging and 

monitoring. But how to build a WSN? How are the connection issues detected? Our goal is to 

explore the process and create such a network with connection status detection on our own. 

 

1.3   Result 

We have created a working Wireless Sensor Network that logs the temperature and 

humidity of the environment in multiple graphs. We have built and configured the required 

nodes and programmed them as well as implementing a detection algorithm for when a node 

disconnects. 

 

1.4   Outline 

The rest of the report is structured as follows. Section 2 presents background 

information on how a Wireless Sensor Network is structured, node composition and 

connection. Section 3 describes what we have accomplished and how we did it. Section 4 

evaluates our project based on network stability, software responsiveness and ease of use. 

Finally, section 5 concludes the report followed by references. At the end is appendix A which 

contains detailed information about the used hardware. 

 

 

 

 

 

 

 

 

 

2   Background Information 

A Wireless Sensor Network consists of as little as a few nodes to as many as thousands 

of nodes. It is based on the Mesh Networking Topology (MNT). Note that in MNT an end node is 

also called an “End Device”. Each router node can have multiple end nodes and multiple router 

nodes can be chained together to cover larger areas. End nodes contain sensors that may 

measure things such as temperature, humidity, light level, air composition, etc. There are also 

wireless modules of the desired type: radio, wifi, bluetooth, etc. The nodes have to be paired 

with a microcontroller, which is a programmable electronic board that connects all the 

components. There also needs to be a form of a power source, which is typically a battery 

(Refer to the image below). The WSN should remain functional if nodes disconnect or 

reconnect. 

 

 

Figure 2­1: A Wireless Sensor Node. The sensor is at the bottom of the image. The 

board has power through a USB connection on the right. The wireless module can be seen on 

the bottom left of the board. 

 

Router nodes receive information from the end nodes and forward them to a sink node 

or other intermediate routers. Router nodes can also have the functionality of an end node, 

have sensors of their own to measure information and add it to the forwarded data. 

 

A sink node is where all the information is gathered, interpreted and displayed as 

needed. Typically there is only 1 sink node per sensor network but it can have multiple display 

screens in different places. Information may be processed into graphs, charts, simple text, 

warnings, etc. The possibilities are endless. 

 

The operation distance is dependent on the hardware used. It can range from hundreds 

of meters to thousands of kilometers. There can be a few long distance nodes or many short 

distance nodes based on needs. It also depends on the cost of the system. The cost is 

dependent on tower heights, antenna types, transmission power, etc. [2]. 

 

 

 

 

 

 

 

 

 

 

 

 

 

3   Result 

We have chosen and built the hardware according to our background research. The 

nodes are made up of a sensor, mesh network module, programmable microcontroller board 

and a microcontroller board shield. The shield acts as an extension to the board in order to 

attach a wireless module. We set up an Arduino IDE software in order to program the boards. 

The code is written and compiled on the computer and uploaded to the board via a USB cable. 

Arduino provides its own libraries for use. We programmed the hardware in C. Each Wireless 

Mesh Module had to be configured via USB prior to installing it on the board. 

Code example for an end node: 

void setup(void) 

{ 

  Serial1.begin(19200); 

} 

This function sets the baud rate and starts the main loop. 

 

void loop(void) 

{ 

DHT22_ERROR_t errorCode; 

delay(2000); 

errorCode = myDHT22.readData(); 

switch(errorCode) 

{ 

case DHT_ERROR_NONE: 

char buf[128]; 

sprintf(buf, "%d,%hi.%01hi,%i.%01i", ID, 

  myDHT22.getTemperatureCInt()/10, abs(myDHT22.getTemperatureCInt()%10), 

  myDHT22.getHumidityInt()/10, myDHT22.getHumidityInt()%10); 

Serial1.println(buf); 

break; 

                           … 

} 

} 

This function sets a delay on the loop because information can be read from the sensor 

every 1­2 seconds but it also needs a 2 second startup time. Error code tracks possible errors 

for data reading, such as a checksum error, bus hung error, data timeout, too quick (polling), 

etc. In this example we will discuss the no error case. After the data is read without any errors a 

character buffer is created and populated with information based on our string format. The 

string format is id%temp%humid. Id is the device ID which is used to distinguish where the data 

came from. Temperature and Humidity readings formated to 1 decimal place. The % sign is 

used because of the simplicity of splitting the string in Java, which is what we used for our GUI. 

Then the println function prints the buffer which sends it out wirelessly. 

 

The created WSN works as intended. For more detailed network cases refer to the evaluation 

portion of this report. 

 

 

Figure 3­1: Project Mesh Network Overview 

 

 

 

 

We chose JAVA to develop our interface software for SN. A computer needs a wireless 

module connected to a USB port (Figure 3­2). The software automatically detects connected 

ports and can connect to them. The library used for port I/O is jSerialComm v1.3.11 [3]. 

Information is read continuously from the port and is interpreted and displayed on the graphs. 

The graphs belong to the jfreechart library v1.0.19, which is very powerful [4]. The software can 

also detect if a sensor is disconnected and resume working if a sensor reconnects, continuing 

updating the graphs. Just like a WSN should behave.  

 

Figure 3­2: Running software. Wireless module connected through USB on the left. 

 

 

 

 

 

 

 

 

We created an algorithm to detect if a sensor is disconnected or reconnected. Data is 

updated every time an input is received (2 seconds per sensor, average input every second). We 

created a counter in the update loop to increment every run. Each sensor also has its own 

counter which increments based on the ID of the received input. If the counters have a 

difference larger than d (d=5) then it is safe to assume the lower counter belongs to the 

disconnected sensor. In order to be able to detect if a sensor reconnects the counters need to 

be synchronized periodically, every s (s=8) inputs for example. After which the counter checks if 

the difference is still larger than d. If not, then the sensor is assumed to be reconnected. The 

period between the synchronization and a valid disconnection period is undefined, therefore 

while awaiting confirmation the status bar is set to “Updating”. 

 

But with only using the algorithm above, there is a problem in detecting if both sensors 

are disconnected because there is no input, which means no counters are incremented or 

functions executed.  For this issue, we figured out a solution below. 

 

First, we create a timer, if there is no input within t (t=5) seconds then it is assumed 

both sensors are disconnected. Once input is received the timer is disabled, this happens 

repeatedly if a sensor is connected and therefore the timer does not go off. This is the one of 

two ways to bypass a case of no input in Java since the program does not come back from the 

input function unless there is any input. A timer forces it to terminate and continue the loop. 

Another way is to have a thread continuously sending “empty” information to the program to 

trigger a return from the input function, but that would require a more sophisticated 

configuration of the detection counters as well as empty cycles of computing power which 

should be avoided if the SN is running on a battery. 

 

 

 

 

 

4   Evaluation 

The performance of hardware depends on its specifications which were given by the 

manufacturer. Refer to appendix A at the end of the report for more information about the 

hardware. 

 

The sensor node setup was done by us to prevent potential static electricity damage as 

the system is very fragile without proper encapsulation of the hardware, which was out of our 

budget range. 

 

Regarding the property of an End Device (E), it can not receive data but only send data, 

there are multiple connection cases where a node goes out of range or disconnects. 

Case 1: Router (R) out of range of Sink Node (SN) or disconnected, E in range of SN. 

The WSN is stable. In this case the E can send information directly to the SN. 

Case 2: R out of range of SN or disconnected, E out of range of SN. 

The SN will be unable to receive any information. 

Case 3: R in range of SN, E out of range of SN. 

The E is can send data through R to SN. WSN is perfectly stable. 

Case 4: SN is disconnected or out of range. 

WSN cannot function. 

 

 

 

 

 

 

 

 

 

Our software and hardware is easy to use. For the hardware part just plug in the 

modules in their appropriate places with a USB cable. Each node connects to a battery and the 

sink node connects to the computer. Refer to the image below. 

 

Figure 4­1:  Sensors nodes on the left and right. Battery in the middle.  

 

For the software part just run it with a double click, it automatically detects USB ports 

with a wireless module and the user only needs to hit “Connect”. The software then displays 

information on the status of the sensors and their readings. The information received is 

displayed on graphs, temperature and humidity as a function of time, see figure 4­2. Each 

sensor has its own graph and they can be combined with a mouse click on the “Mix/Split 

Graphs” button. See figure 4­3 for a mixed graph image.  

 

 

 

 

Figure 4­2: Software Screenshot with split graphs. 

 

Figure 4­3: An image of a mixed graph. 

The software was used by some of our friends and relatives around campus (6 people) 

and their feedback was very positive overall, very simple to use. The feedback was as follows:  

● The main issue as seen by 2 people was the unavailability of a display for an exact 

measurement. They don’t want to “have” to read the graph in order to know a value. 

We have agreed that it is indeed an inconvenience. 

● The “Updating...” status iterations were a little slow as mentioned by 3 people. That is 

due to the core design, update every 8 inputs, which is very slow if only 1 sensor is 

connected (16 seconds). It was a tradeoff between frequent updates or a longer actual 

status display of “Good” or “Sensor X disconnected” and the timing balance between 

reading from 1 or 2 sensors.  

● The software was seen as very responsive by everyone to a disconnection from both 

sensors as that detection algorithm did not depend on external input.  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5   Conclusion 

5.1   Summary 

The WSN is working as intended with nodes being able to disconnect and reconnect at 

any time without breaking overall performance as long as the nodes are in range. The 

developed software is able to display information graphically and detect the connection status 

of sensors independently. 

5.2   Relevance  

Used a wireless network topology in creating a wireless sensor network to log 

environmental data. It is a growing field in wireless networking as mentioned in the 

Introduction. 

5.3   Future Work  

Can expand on the amount of nodes and add more sensors to cover a larger area and 

log more information based on needs as well as improve the quality and durability of our 

hardware to increase the amount of viable placement locations. For example a full weather 

report in a local area that could be more accurate than a city weather report if a city is big or 

the area of the WSN is farther out. Another possibility is to monitor the environment in lakes or 

sea floors with a waterproof setup. 

 

Contribution of Team Members 

   Vladimir Menshikov: Network Researching. Hardware coding and the building of the Graphic 

User Interface for Sink Node. Participate in the development of network connectivity detection 

algorithm and implementation debugging. Report writing. Final editor for the report. 

   Xiao Zhu: Project Idea. Hardware researching, assembling, configuring and coding. Participate 

in the development of network connectivity detection algorithm and implementation 

debugging. Report writing. 

 

 

 

References 

[1] Techopedia, “Wireless Sensor Network”, 

https://www.techopedia.com/definition/25651/wireless­sensor­network­wsn 

Accessed: Feb 7, 2016. 

[2] ACM Digital Library, “Long distance wireless mesh network planning: problem formulation 

and solution”, http://dl.acm.org/citation.cfm?id=1242693. 

Accessed: Mar 20, 2016. 

[3] jSerialComm Java Library, http://fazecast.github.io/jSerialComm/. 

Accessed: Mar 13, 2016. 

[4] JFreeChart Java Library, http://www.jfree.org/jfreechart/. 

Accessed: Mar 13, 2016. 

[5] Digi, XBee™ Gateway User's Guide, 

http://ftp1.digi.com/support/documentation/html/90001399/90001399_A/Files/XBee­concept

s.html#_Toc384719516. 

Accessed: Feb 14, 2016. 

[6] Digi, XBee ZigBee Mesh Kit, 

https://docs.digi.com/display/XBeeZigBeeMeshKit/How+to+set+up+a+ZigBee+mesh+network. 

Accessed: Feb 14, 2016. 

 

References 5 and 6 were not directly referenced in this report. They were used for research and 

setup of our hardware. 

 

 

 

 

 

 

 

Appendix A 

Pictures taken from manufacturer’s website for visualization purposes only. 

Temperature and Humidity Sensor module 

Model/SKU: SEN0137. 

Name: DHT22. 

Supply Voltage: 5V. 

Output Voltage: 0­3.3V. 

Temperature Range: ­40 to 80 ℃. resolution 0.1℃. error <±0.5℃. 

Humidity Range: 0­100%RH. resolution 0.1%RH. error±2%RH. 

 

 

 

 

 

 

Network Mesh Module 

Name: XBee ZigBee PRO 

Data Rate:  RF 250 Kbps, Serial 1 Mbps. 

Indoor Range: 300ft (90m). 

Outdoor/RF Line­of­Sight Range: 2 miles (3200m). 

Transmit Power. 3.1 mW (+5 dBm). 

Receiver Sensitivity: ­100 dBm. 

Frequency Band: ISM 2.4 GHz. 

Interference Immunity: DSSS. 

Protocol: ZigBee PRO 2007. 

Encryption: 128­bit AES. 

Supply Voltage: 2.7 to 3.6V 

 

 

 

Xbee USB Adapter Board 

Product ID: 32400 

A required adapter board to connect an XBee wireless mesh module to a computer via USB. 

 

 

 

 

 

Microcontroller Board 

Name: DFRobot Mega 2560 V3.0. 

Model/SKU: DFR0191. 

Operating Voltage: 5V. 

Input Voltage (recommended): 7 ~ 12V. 

Flash Memory: 256 KB of which 8 KB used by bootloader. 

SRAM: 8 KB. 

EEPROM: 4 KB. 

Clock Speed: 16 MHz. 

 

 

 

 

 

 

Microcontroller Board Shield 

Name: Mega Sensor Shield V2.4. 

Model/SKU: DFR0165. 

Extension to the microcontroller board, allows placement of a wireless module.