wsn for water quality - tu/e · wireles sensor network for water quality measurements popescu, a.d....
TRANSCRIPT
![Page 1: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/1.jpg)
Eindhoven University of Technology
MASTER
Wireles sensor network for water quality measurements
Popescu, A.D.
Award date:2015
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
![Page 2: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/2.jpg)
Wireless Sensor Networkfor Water Quality
Measurements
Master Thesis
Daniel Popescu
Department of Electrical EngineeringElectronic Systems Group
Master of Embedded Systems
Supervisors:Prof. dr. ir. Twan Basten - TU/e
Dr. ir. Majid Nabi - TU/eDr. ir. Siebren Schaafsma - Holst Center
Dr. ir. Richard Verhoeven - TU/e
Eindhoven, December 2014
![Page 3: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/3.jpg)
![Page 4: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/4.jpg)
Abstract
The most prevalent challenges in wireless sensor networks for environment monitoring are linkrobustness and long time deployment periods. In general, those two concepts are opposing oneto the other, but this thesis project offers novel ideas to combine them into a trade-off solution.Robustness is achieved by a routing protocol using gradients and several redundancy generatorstrategies. This approach allows the network nodes to form ad-hoc, fail-tolerant and self-healingcommunication links. The more information is exchanged, the better insight over the surroundingtopology is gained by nodes. Thus robustness benefits from this approach, the nodes will consumemore energy. To restrict this effect, very long duty cycles are adopted for saving more battery life.The idea is to achieve accurate time synchronization between neighboring nodes, in order to earnthe capability to sleep most of the time and use the right momentum to wakeup and disseminatedata. I propose through this project straight forward methods to rely on external clocks in sucha way that very long duty cycling will not affect the overall capability of the network to properlydistribute data, albeit maintaining a very low energy footprint. The essential design solution is toaccurately manage the low power sleep period of both the microcontroller and radio transceiverfor a sensor node, via a precise external wake-up signal. The whole project is implemented anddeployed directly on of-the-shelf Arduino boards and 802.15.4 compatible radio platforms. Realmeasurements of time synchronization and power metrics are analyzed against a projected modelbuilt from initial user requirements. A proof of concept test bed setup, together with a real timesniffing and topology intervention application, offer the means to visually evaluate the behaviorof nodes in different scenarios which otherwise could not be possible without long term, real lifedeployments. This project was carried out at Imec Netherlands.
Wireless Sensor Network for Water Quality Measurements iii
![Page 5: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/5.jpg)
![Page 6: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/6.jpg)
Preface
I would like to thank my university supervisors prof. Twan Basten and Majid Nabi for theirguidance and encouragement during the course of the project.
Also, I would like to thank my supervisors from Holst Center - Imec, Siebren Schaafsma andMarcel Zevenbergen for the advice and comments on all my ideas, good or bad, while working onthis project. Furthermore, I want to thank Victor van Acht for his help in the electronics andpower related issues faced during my project.
I need to give a very warm thank you to my best friend, Daniel Flamaropol for all the supportoffered with C# beginners guidance.
Finally, I would like to thank my parents and my girlfriend Alexandra for their continuingsupport and understanding while I was working on my project.
Daniel Popescu
Wireless Sensor Network for Water Quality Measurements v
![Page 7: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/7.jpg)
![Page 8: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/8.jpg)
Summary
List of plots and figures ix
List of tables xi
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Technical Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organization of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Analysis 5
2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Present water quality applications . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Clock synchronization technical approaches . . . . . . . . . . . . . . . . . . 6
2.3 Targeted Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Solution 9
3.1 High-Level Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Application Specifications and Requirements . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Power Optimization Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Application Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Implementation 27
4.1 Hardware Abstraction Layer (HAL) . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1 Arduino Software Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 Real Time Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 Xbee Driver Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.4 RTC Driver Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Harvest Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Routing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1 Neighboring Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 Gradient Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Deviation Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Strategy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Data Harvesting Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 Sniffing Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Wireless Sensor Network for Water Quality Measurements vii
![Page 9: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/9.jpg)
SUMMARY
5 Experiments and Evaluation 495.1 Node Power Consumption Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Radio Data Dissemination Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Network Life Expectancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.4 Packet Drop Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.5 Memory Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Conclusions and Future Work 59
Bibliography 61
Appendix 63
viii Wireless Sensor Network for Water Quality Measurements
![Page 10: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/10.jpg)
List of plots and figures
1.1 Economic Impacts of Water Supply and Sanitation Projects . . . . . . . . . . . . . 1
3.1 General Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Radio transmission range and links with neighbors. . . . . . . . . . . . . . . . . . . 113.3 Arduino Mega 2560 (rev. 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 802.15.4 Standard Device Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Xbee Transceiver Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6 Maxim’s DS3231 RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7 Maxim’s DS3231 RTC - Main features . . . . . . . . . . . . . . . . . . . . . . . . . 153.8 Holst Center prototype PH sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.9 Line Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.10 Protocol Booting Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.11 Gradient and Deviation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Hardware Components of a wireless sensor node . . . . . . . . . . . . . . . . . . . 274.2 Software Architecture - Functionality Blocks and Interactions . . . . . . . . . . . . 284.3 Timed Automatom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Basic Operational Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Chronological actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.6 XBee generic API frame (datasheet [23]) . . . . . . . . . . . . . . . . . . . . . . . . 324.7 XBee API frame: TX (Transmission) with 16-bit addressing (datasheet [23]) . . . 324.8 XBee API frame: RX (Reception) with 16-bit addressing . . . . . . . . . . . . . . 334.9 Harvest Manager - General flow of operations . . . . . . . . . . . . . . . . . . . . . 354.10 Container Redundancy Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.11 Island of Nodes Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.12 Gradient redistribution in case link loss . . . . . . . . . . . . . . . . . . . . . . . . 394.13 Nodes affected by deviation policies . . . . . . . . . . . . . . . . . . . . . . . . . . 394.14 Routing Service - General flow of operations . . . . . . . . . . . . . . . . . . . . . . 404.15 Routing Service - Detailed Operational Flow . . . . . . . . . . . . . . . . . . . . . 414.16 Time Synchronization - Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.17 Strategy Manager - General flow of operations . . . . . . . . . . . . . . . . . . . . 444.18 Timer Offset Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.19 Neighbor Reference Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.20 Node Power States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.21 Data Harvesting Application User Interface . . . . . . . . . . . . . . . . . . . . . . 474.22 Sniffing Application User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1 RDD period influenced by the number of containers enclosed in a packet . . . . . . 515.2 Delay measurement Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.3 Delay measurements between the RDD starting points on 2 neighboring nodes . . 525.4 Operational Time vs Battery Capacities . . . . . . . . . . . . . . . . . . . . . . . . 545.5 Estimated error ratio per node per day . . . . . . . . . . . . . . . . . . . . . . . . . 55
Wireless Sensor Network for Water Quality Measurements ix
![Page 11: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/11.jpg)
![Page 12: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/12.jpg)
List of tables
3.1 Granularity correlation between wireless range and network size . . . . . . . . . . . 113.2 Arduino Mega 2560 - Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Xbee 802.15.4 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Active Clock Domains and Wake-up Sources in the Different Sleep Modes (taken
from datasheet [21]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Watchdog Prescaler Options (datasheet [21]) . . . . . . . . . . . . . . . . . . . . . 143.6 Maxim’s DS3231 RTC - Main Features . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 ChibiOS - Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Container Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Routing Packet Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Neighboring Table Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Node Components List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Power Consumption Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Xbee Firmware Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4 Energy prediction parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.5 Packet loss in a line topology with 4 nodes . . . . . . . . . . . . . . . . . . . . . . 555.6 Memory demand for the WSN application . . . . . . . . . . . . . . . . . . . . . . . 57
1 User Requirements for the water quality WSN . . . . . . . . . . . . . . . . . . . . 632 High-Level Requirements Part 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 High-Level Requirements Part 2/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 654 High-Level Requirements Part 3/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Wireless Sensor Network for Water Quality Measurements xi
![Page 13: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/13.jpg)
![Page 14: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/14.jpg)
Chapter 1
Introduction
This thesis document presents the work carried out during my master project ”Wireless SensorNetwork for Water Quality Measurements” at Holst Center (IMEC - Netherlands). The main goalof the project was to design, implement and deploy a power aware and self-healing wireless networkto use the new environmental sensors produced by IMEC [1].
1.1 Motivation
Having access to fresh and unpolluted water is an important element of our daily life. Un-fortunately, this is not the case everywhere. According to UNICEF and World Health Organiza-tion [2], [3], 783 million people, around the globe, lack access to safe drinking water and 2.5 billiondo not have access to proper sanitization. Due to this fact, it is estimated that half of the hospitalbeds in the world are occupied by patients suffering from water related diseases.
Figure 1.1: Economic Impacts of Water Supply and Sanitation Projects
As seen in Figure 1.1, financing water safety projects contributes to economic progress. Each 1$invested in this field will return 3$ to 34$ in the economy, depending on the region and technologyinvolved [4].
Wireless Sensor Network for Water Quality Measurements 1
![Page 15: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/15.jpg)
CHAPTER 1. INTRODUCTION
The influence of contaminated water does not harm only human life, but also our surround-ing ecosystem. 24% mammals and 12% bird population linked to inland water are consideredthreatened [5]. Fresh water species experience an estimated risk of death five times greater thanthe terrestrial ones [6]. There is no shortage of ways to improve this water related problem. Anysolution can lead to a better life and a safer environment.
1.2 Technical Contribution
Environmental monitoring has always been a time consuming and costly activity. Latest im-provements in technology allow us to use wireless communications as a facility for easier andcheaper access in remote locations. An entire domain of technical challenges emerged togetherwith the more demanding uses of this technology. Without any doubt time is the most importantactor in wireless sensor networks. We must face the fact that temporal locality gives sensed datameaning, but moreover when we talk about wireless technology we also imply time synchroniz-ation. Without coordination in the time domain, a wireless sensor node loses its purpose sincea multi-hop transmission would not be possible. Notably the majority of clock synchronizationalgorithms proposed throughout the literature, is based on the idea that all nodes shall exchangeinformation over the network at regular intervals in order to keep their clocks aligned. Few ap-proaches have a practical applicability from the energy consumption point of view because most ofthem rely on keeping alive the radio communication since this is the only gateway to the outsideworld.
Research Path
In this project I will try to demonstrate that accurate enough time synchronization, for propernetwork operation, is still possible even if we turn off the RF module and we put the MCU indeep sleep mode for very long periods. An external Real Time Clock (RTC) module is plannedto give the wakeup alarm for all the components exactly when the moment is favorable to startdata dissemination. This aspect is tackled because current project’s purpose is environmentalmonitoring and in consequence long time network availability is among the main goals; thereforea strong energy efficiency plan is required.
Engineering
As a key factor in the projected goal for this master thesis, robustness is achieved favoringstraightforward ideas. This project intends to combine simple approaches like epidemic routing,directed dissemination using gradients and deviation policies to generate ”convenient” redundancyfor a robust behavior of the network.
The complexity of the problem arises from the fact that these two solutions (research andengineering) are usually in conflict. To increase energy efficiency, nodes are enforced to use aslittle as possible the radio communication, but robustness favors the redundancy factor whichplead the opposite.
1.3 Organization of the thesis
In Chapter 2 the problem is analyzed by starting from the generic goal of the project. Further,background comparison analysis is done with the present literature. Chapter 3 expresses the goalinto requirements from where the formal detailed solution and energy model of the project areshaped. Chapter 4 deals with the actual implementation choices and how the values are chosen forthe metrics previously defined in Chapter 3. Implementation details of architecture and algorithmsare discussed in this chapter as well. Chapter 5 shows all the experiments and evaluations of theproposed solution. Within the 6th chapter the final conclusions are drawn and given the results
2 Wireless Sensor Network for Water Quality Measurements
![Page 16: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/16.jpg)
CHAPTER 1. INTRODUCTION
from Chapter 4 future work topics are also suggested. The appendix contains all the brief tableformat requirements.
1.4 Intended Audience
This thesis document is meant for people with background knowledge in computer networks andwireless technologies. Basic literature in this field is represented by the works of Andrew S. Tan-enbaum ”Computer Networks” [7] and Robert Faludi ”Building Wireless Sensor Networks” [8].
Wireless Sensor Network for Water Quality Measurements 3
![Page 17: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/17.jpg)
![Page 18: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/18.jpg)
Chapter 2
Analysis
2.1 Problem Statement
In most of the developed countries, traditional water quality monitoring is performed toosporadic as it needs to be done. In case of agricultural usage, water checks may be done once ayear directly from the pumping well or once per week directly from rivers, but only in areas inwhich contamination is known to be imminent. In other cases, the checks are very rare or notdone at all. For human usage, the water distribution plants may have their own micro-labs inwhich the water sources are tested at most once per day. All those applications have in commona lot of human labor and the feedback may not come fast enough to avoid calamities.
Advances in technology made wireless electronic applications more interesting for projects con-cerning long term monitoring due to increasing factors such as power efficiency, ease of installation,reduced maintenance costs and reliability. Wireless solutions have proven be a very attractivealternative to the conventional infrastructure, once they successfully surpassed technical and en-vironmental challenges implied by exposure to water, high interferences, hard-to-reach physicallocations and long distance boundaries.
By making use of water monitoring systems based on Wireless Sensor Networks (WSN) tech-nology, the potential to detect pathogen viruses or hazards, in real time, is increased and con-tamination of population or crop may be avoided at early stages. These technical solutions arecapable to spot the source of pollution, fact which could be further used to stump it sooner withoutadditional costs and damages.
2.2 Related Research
2.2.1 Present water quality applications
Many WSN applications addressing to water quality monitoring have been implemented; theirfocus varies from small controlled areas like a few nodes on a lake or in a pool to large scale, longdistance systems to monitor rivers and city pipes.
Solutions [9] and [10] focus on building a WSN which can be easy suited for water measure-ments. The result is perfect for small and very small deployable networks which monitor a fewwater surface areas like a swimming pool complex. Nevertheless, these solutions do not tacklerobust approaches to overpass the real impact of the environment on the network. Comparingwith my project, these solutions offer a very limited and strict topology deployment. By usingdirectly the Zigbee routing layer the real contributions are scaled down to just shaping a practicalwater measurement application.
Longer time deployments and communication range solutions in [11], [12] and [13] offer aninsight on very large scale networks supported by governmental organizations in which high-endand custom hardware is built to meet harsh requirements like autonomy, accuracy measurements,
Wireless Sensor Network for Water Quality Measurements 5
![Page 19: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/19.jpg)
CHAPTER 2. ANALYSIS
very long communication ranges and environmental exposure. Each sensor node can cost a fewthousands of dollars and has all the necessary equipment to be deployed for more than a few yearswithout any necessary maintenance. My application proposal favors large deployment fields, butthe node distribution scheme may have in focus smaller areas which can be further joined. Amajor difference proposed by my solution is that of-the-shelf low cost components are favored tocustom built ones, since the focus is to actually build a robust, plug-and-play network protocolwithin a short period of time using fewer resources and not necessary having a very sophisticatedhardware platform.
An interesting WSN solution is presented in [14] in which water distribution of Singapore cityis assisted by a very complex wireless network structure. This network is able to measure all thewater quality parameters and to detect and localize a leakage or pipe break with a good precision.The information is synchronized with a data center from which several services are connected tolocal maintenance teams who are guided directly to the problematic area. By data mining andprediction algorithms, the decision to close the water vanes from an area is made in order to pursuewith repairs. The exact water taps are pointed also by the network software solution in order tominimize the impact on population. One of the most important features of this system is thatlarge reductions on the municipality’s electricity invoice are achieved, since the water pumpingschedule is based on an algorithm which takes into consideration predicted water consumptionand electricity price at a certain time of the day. This system may have many features but Iconsider that its wireless network behavior is sensitive to changes and the nodes are not expectedto simply disappear. The energy supply is directly from the power grid or from already mountedsolar panels used for public illumination and this fact relaxes the energy consumption constraints.On the other hand, my system shall have a very good low-power behavior since the consideredenvironment will not offer the advantage of having more than a battery and maybe a small solarpanel.
2.2.2 Clock synchronization technical approaches
In the domain of WSN, energy is considered a limited resource and managing it in a properway makes the difference between a profitable project and an fruitless one. Since the radio com-munication consumes the highest amount of energy in a sensor node platform, a logical step isthat wireless communication activities needs to be optimized. The right moment of data transfershall be carefully chosen; therefore a good coordination between nodes within a network is the keyfor using less energy.
One of the pioneering ideas, introduced by Fan and Lynch [15] in gradient synchronization, wasthat the time difference between two nodes is proportional to the distance between them. Gradientsynchronization was started as a particularity of the clock coordination problem where the goalwas to make the synchronization more compact between neighboring nodes than a common timeconsensus over the entire network.
The paper of Sommer and Wattenhofer [16] present the Gradient Time Synchronization Pro-tocol (GTSP). The claim of not being tighten to a particular topology involving a tree or areference node makes this method more robust to node and link failures. Their solution focuseson accurately synchronization of clocks between neighbors. Thus the solution prove to be a verythorough demonstration from both practical (20 node test bed) and simulation point of view, Irealized that the focus is not really on a very low power profile. The result unfolds that the energyefficiency is gained just by sleeping the MCU, while the radio module is kept on for synchroniza-tion purposes. This leads me to the idea that this solution is not suitable for my type of project,but some suggestions like piggy backing time metrics within packets can be further used in mysolution as means of synchronization between nodes.
The Robust Gradient Clock Synchronization (RGCS) algorithm proposed by Pinho, Figuereidoand Franca [17] is a fully distributed design without any constraint on topology or routing. Thismethod is based on a running average of time stamps to estimate the logical clocks betweenneighboring nodes. The authors plead that this algorithm behaves better than GTSP in normaland under high link losses scenarios. From my point of view this solution still remain under a
6 Wireless Sensor Network for Water Quality Measurements
![Page 20: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/20.jpg)
CHAPTER 2. ANALYSIS
questionable claim that without a practical comparison on real platforms, some assumptions aboutpacket delays may be inaccurate. The application is also relying on the RF modules being alwayson. This result can be used with an additional low power RF module for wakeup purposes, but inthis case, the energy efficiency is transferred into a hardware solution which is no longer the topicof my project. The defining difference is that the solution presented in this thesis project, usestime synchronization techniques as the means to save more power by turning off both the radioand MCU.
A compelling idea of WSN synchronization is represented by the work of Lamonanca et all [18].They introduce the idea of event-driven packet synchronization, which has the basic principle thatif there is an event detected in the network, the nodes in the neighborhood will increase theiraccuracy by transferring synchronization packets at a higher rate. In exchange, the parts ofnetwork without any activity will try to minimize the radio traffic. The paper displays goodresults of tight clock synchronization in both numerical simulations and experimental results.Thus a great algorithm, as all the others papers discussed so far, the authors do not take intoconsideration turning off both the MCU and radio for an utmost power save. Of course thisapproach will come at a cost of loose synchronization but in exchange the energy efficiency gainis higher.
2.3 Targeted Measurements
The water quality indicators under investigation, in this project, are of two types:
∗ Chemical: PH
∗ Physical: Temperature
PH measurement determines the amount of hydrogen and hydroxyl ions in water. These twocompounds establish the solubility and biological availability of chemical constituents (phosphorus,nitrogen and carbon). PH also determines how much the aquatic life can make use of phosphorusfrom water. A very high or very low PH value may indicate that the water is improper forlife. Drinking water with very low PH (<6.5 ppm - acidic) values is extremely dangerous forhumans or animals since it contains elevated levels of toxic metals (iron, copper or lead); Fish eggscannot hatch and most aquatic macro-invertebrates may die since low PH weakens their shellsand exoskeletons. Very high PH (>8.5 - alkaline) water has also a harmful effect on humans andanimals, since vital alkaline mineral reserves of calcium, magnesium, zinc and selenium can beeliminated due to temporary accumulated alkalinity in the body. Another effect of PH imbalancesdirectly affects the riparian vegetation [19] which is the food and shelter for most animals and fishfrom a water surface. PH changes may have different causes and may weight differently but mostof the times, human activities resulting in accidental spills, sewer overflow and agricultural runoffare the most critical ones to humans themselves.
Temperature is the most common measurement done in water quality assessments since itdirectly impacts both chemical and biological characteristics of a water surface. Warm temperat-ures in the water body favor a higher metabolism rate for water plants thus raising the oxygendemand. Temperature increase also affects the PH level since water molecules have a slight tend-ency to break down into their constituents, hydrogen and oxygen. The direct chemical effect, inthis case, is that an extensive number of molecules will release hydrogen ions which can be furthermeasured as a lower PH value.
Wireless Sensor Network for Water Quality Measurements 7
![Page 21: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/21.jpg)
![Page 22: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/22.jpg)
Chapter 3
Solution
The main scope of this project is to monitor a system of lakes and channels which serve asdrain sources for water treatment plants and agriculture irrigation. By supervising the PH andtemperature imbalances in water, life endanger for humans and wild aquaculture could be avoidedon time. The system shall have sensors spread over the surface of water in key points which mayoffer a very good overview of the quality parameters; per example in lakes around residential andindustrialized areas or channels from where irrigation systems have their drain sources.
We start defining the solution by building a sum of basic high level requirements from whichthe whole project will evolve. A brief form of these requirements can be found in Table 1 fromAnnex and the following chapter will dedicate its content to detail each of them.
3.1 High-Level Overview
The proposed WSN system will consist of 3 component types as depicted in Figure 3.1.
∗ Monitoring Sensor Nodes (node)
∗ Sink Node (SINK)
∗ Sniffing Device (SNIFFER)
A relatively large number of nodes will be deployed in the focused area in a Point-to-Pointor Point-to-Multi-Point mesh fashion. Each of them will have the tasks to measure the proposed
Figure 3.1: General Architecture Overview
Wireless Sensor Network for Water Quality Measurements 9
![Page 23: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/23.jpg)
CHAPTER 3. SOLUTION
system parameters (PH and temperature) and to transmit them to the SINK node. A node willbe able to store data over a small period of time in case there is a communication failure with itsdirect neighbors.
There is a direct implication between the covered area and the cost savings in human laborand fuel consumption. The wider the area, the larger the cost savings. The proposed solutionshall be able to cover 100 Ha, which is equivalent to 1 km2. Traveling at remote locations formaintenance shall be a task which needs to be done as sporadic as possible. Since it is a projectof environmental monitoring and the used PH sensor has a lifetime of approximately 6 months, a9 months of network lifetime shall be long enough for the actual needs.
An important feature of each node is that, once it is powered on, it must search itself forother active nodes to ensure that it has a path to SINK and its forthcoming acquired data willbe successfuly delivered. This plug-and-play behavior offers the possibility also for non-technicalpersons to handle and mount the nodes in remote locations. Another advantage is that it gives theability for a node equipped with an energy scavenging device who’s battery is depleted to re-jointhe network once it has enough power to sustain its processing and communication demand.
The main role of the SINK node is to gather data from all nodes and to transmit it farther viaa wired connection to a PC. Based on it’s geographical position within a network, the SINK nodewill not be required to run on batteries but it will be plugged into the mains.
The routing protocol must ensure that data packets sent by a node will be routed to the SINKnode even if the node and SINK are not directly connected. For my proposed solution I considerthat my network has only one SINK node and it is the final destination for all data packetsgenerated by sensor nodes. If one node is missing (there was no radio traffic from it) for a longerperiod of time, the linked nodes will be able to detect this and it will no longer be counted inthe routing algorithm. In that situation, the data packets from those linked nodes will be routedthrough other paths in order to be delivered to SINK.
From the user point of view, the network devices needs be accompanied by a proper userfriendly PC plotting software which shall be able to show the evolution in time of the gathereddata samples from the field. Since monitoring of chemical spill hazards is the final goal, the PCapplication shall be able to detect hazards and properly notify the user about their appearance.
An additional feature of this complete network solution, besides monitoring the water para-meters, it is to be easily troubleshooted. For this purpose the SNIFFER device employs the roleof the debugger for the rest of the nodes and their software running on them. Tightly connectedwith a graphical visualization software on PC, the SNIFFER device will offer the user the abilityto see in real-time the surrounding active nodes with their connections and also their exchangedpackets. This way easy judgments could be concluded about how the environment affects theradio range of each individual node, how the software running on the nodes behaves in certainsituations and what actions could be taken to improve the quality of transmissions for a final goalof less lost packets. This feature will only be part of the proof of concept solution.
3.2 Application Specifications and Requirements
As seen on tables 2, 3 and 4 from Annex, the project requirements are split into severalcategories to tackle them in an organized manner. As several specifications may have differentinfluences from other categories, each requirement will be presented and treated under the majorgroup that it fits best.
3.2.1 Hardware
Having the goal to cover an area of 1 km2, I can depict that with a compact mesh distribution,the maximum number of nodes depends on the wireless range of the radio modules. Table 3.1gives us a granularity correlation between the radio transmission range and the required numberof nodes to cover the proposed area taking into consideration that each node is only connected toits adjacent neighbors.
10 Wireless Sensor Network for Water Quality Measurements
![Page 24: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/24.jpg)
CHAPTER 3. SOLUTION
Radio TransmissionRange (m)
Number of nodes Density/Ha
25 1600 1650 400 4
100 100 1200 25 0.25300 16 0.16400 9 0.09500 4 0.04
Table 3.1: Granularity correlation between wireless range and network size
Figure 3.2: Radio transmission range and links with neighbors.
Based on the overall goal to monitor water quality parameters in lakes or channels, I decidethat it is important to have a good density of nodes in the field. I choose that my networksolution shall be comfort 100 nodes, which gives an average of 100 m of radio transmission rangebetween each node as seen in table 3.1. This goal can be achieved by a powerful enough wirelesscommunication module that has a range of more than 100 m. The main reason is that all nodesin a tightly coupled mesh network shall be connected with each other as seen in Figure 3.2. Bythis conservative measure, I may comfort the case that after lowering the transmission powerover time, due to battery capacity drop, the wireless connectivity can be maintained. Moreover,the maximum transmission range of a node also depends on factors as environment conditions orantenna installation. Based on the deployment circumstances, it may not make sense to alwaysset up wireless nodes fully equipped with measuring sensors, since some terrain may need onlywireless link coverage and thus no real use of water measurements.
Microcontroller BoardArduino was chosen since it is an open-source electronics prototyping platform with flexible
easy-to-use hardware and software tools. Arduino 2560 microcontroller board depicted in Fig-ure 3.3 has an Atmel 8-bit RISC architecture (MCU Atmega 2560) running at 16 MHz.
As inferred by Table 3.2, this platform has enough processing power and I/O capabilities tosustain the future protocol stack and application, but the power consumption can be an importantdrawback. This MCU uses its internal ADC to measure PH and its own internal battery voltage,while the temperature is retrieved via an SPI communication.
Radio Transceiver BoardTaking into consideration the density and scale of my project, using a standard like 802.15.4
to build the WSN protocol stack is a desirable solution. The general criteria in choosing this
Wireless Sensor Network for Water Quality Measurements 11
![Page 25: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/25.jpg)
CHAPTER 3. SOLUTION
Figure 3.3: Arduino Mega 2560 (rev. 3)
SpecificationsMicrocontroller ATmega2560Operating Voltage 5VInput Voltage 6 - 20VMax. DC Current per I/O Pin 40 mAMax. DC Current for 3.3V Pin 50 mAMax. DC Current VCC and GND Pins 200 mACurrent ATmega2560@16MHz 45 mA @ 5 VFlash Memory 256 KB of which 8 KB used by bootloaderSRAM 8 KBEEPROM 4 KBClock Speed 16 MHzDigital I/O Pins 54 (of which 13 provide PWM output)Analog Input Pins 16UART/TTL 4External Interrupts 6PWM (8-bit) 13SPI YesLED 1 on board led.
Table 3.2: Arduino Mega 2560 - Main Features
standard is that it intends to offer essential lower layer protocols which target on low energy cost,low-rate and pervasive communication between nodes.
The general architecture of IEEE 802.15.4 (LR-WPAN) [20] is described in terms of function-ality blocks called layers. Each of these layers is capable of providing services to the upper sectionsand also to interact with the lower ones as in Figure 3.4. In its core, this standard defines an RFand physical (PHY) layer with a PSK modulation scheme transceiver which works on 2.4 GHzISM band over 16 channels and achieves rates up to 250 kbps.
On top of the radio transceiver physical layer, the roles of Medium Access Control (MAC)layer include channel access control methods as Carrier Sense Multiple Access (CSMA) with Col-lision Avoidance (CA) and Time Division Multiple Access (TDMA) with beacons and GuaranteedTime Slots (GTS), Cyclic Redundancy Check (CRC) validations, acknowledgement frames (ACK),association/disassociation management and security mechanisms.
According to this standard, each device can operate in 2 modes: Full Function Device (FFD)and Reduced Function Device (RFD). The main difference between them is that the RDF devicescannot form a connection with the same type of device, but only with a FFD. Based on the par-ticularities defined by those operational modes, two types of network formations can be achieved:
12 Wireless Sensor Network for Water Quality Measurements
![Page 26: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/26.jpg)
CHAPTER 3. SOLUTION
Figure 3.4: 802.15.4 StandardDevice Architecture
Figure 3.5: Xbee TransceiverModule
SpecificationsProtocol 802.15.4Frequency 2.4GHzTX Current 45mA @ 3.3VRX Current 50mA @ 3.3VPower-Down Current <10µASensitivity -92 dBmChannels 16Distance ∼100mAntenna 3dBiBaud Rate 1200 bps - 250 kbps
Table 3.3: Xbee 802.15.4 Specifications
star topology and peer-to-peer topology. Since my proposed network topology has a mesh formdeployment, I set all the nodes in the FFD mode, therefore a point-to-multipoint topology.
A flooding based protocol is used as the routing strategy on top of the 802.15.4 PHY and MAClayers. Due to this fact, flat addressing scheme is an implicit requirement that needs to be met.This aspect is handled in LR-WPAN standard by assigning to each node the role of an End Devicewithout any association to a Personal Area Network (PAN) Coordinator device.
The XBee 802.15.4 modules produced by Digi Electronics and seen in Figure 3.5 are ideal forlow-power, low-cost applications. These modules are designed for high-throughput applicationsand offer a low latency and predictable communication timing, facts which could be further usedby the proposed time synchronization algorithm. Brief specifications for the radio module aredepicted in Table 3.3.
Real Time Clock (RTC)
One of the initial evaluations of the MCU platform was the possibility to put the controllerinto a low power sleep mode and furthermore to be able to accurately wake it up at a fixed timeinterval. Following the specifications of ATmega 2560 MCU regarding sleep power modes [21]as seen in Table 3.4 and also observed in measurements done in Chapter 5 ”Experiments andEvaluation”, it is a clear choice that the POWER DOWN mode should be used to achieve thelowest possible power consumption.
A very important part of this project is that we need to have long sleep periods to meet thelow sampling rate and power efficiency requirements. Since in POWER DOWN mode we havea very limited availability of wakeup options, the initial implementation endeavors sustained theidea that by using the internal watchdog component to wake up the processor would prove a fastand handy solution. According to Table 3.5 we can see that the maximum granularity of the
Wireless Sensor Network for Water Quality Measurements 13
![Page 27: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/27.jpg)
CHAPTER 3. SOLUTION
Table 3.4: Active Clock Domains and Wake-up Sources in the Different Sleep Modes (taken fromdatasheet [21])
watchdog timer is 8 seconds, after which an interrupt is issued to wake up the MCU. As we expecta sleep period longer than 8 seconds, then the solution to achieve it, is to wakeup the MCU every8 seconds, perform a check if the right period has passed and if it did not, then put it back to sleepand wait for another wakeup interrupt. In theory, this approach would be the simplest and bestsolution, but the real oscilloscope measurements proved that it is unreliable to achieve accuratewakeup periods. There are several reasons why this solution is not invariably exact and the mostrelevant one is that the internal RC oscillator does not always provide a consistent frequencyclock. As seen in the MCU datasheet [21] the oscillator accuracy is influenced by temperature,right fuse configuration and constant voltage supply. Even if the datasheet claims that the factorycalibration accuracy can be improved, it is never stated that we will achieve a very precise clock
Table 3.5: Watchdog Prescaler Options (datasheet [21])
14 Wireless Sensor Network for Water Quality Measurements
![Page 28: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/28.jpg)
CHAPTER 3. SOLUTION
Figure 3.6: Maxim’sDS3231 RTC
SpecificationsInput voltage 3.3 - 5.5V
±2ppm from 0◦C to +40◦CAccuracy ±3.5ppm from -40◦C to +85◦CInterface I2C @ 400kHz
200 µA @ 3.63VActive Supply Current
300 µA @ 5.5V110 µA @ 3.63VStandby Supply
Current 170 µA @ 5.5Vmax 3 µA @ 3.63VTimekeeping Battery
Current max 3.5 µA @ 5.5V
Other FeaturesBattery backup input forcontinuous timekeeping
Table 3.6: Maxim’s DS3231 RTC - Main features
source for the internal watchdog to provide a good wakeup interrupt for our MCU. After testingseveral calibration options offered by the datasheet, I had faced wakeup drift periods of 0.5-15 msecper each wakeup cycle of 8 seconds. Given that the project has a target of 15 minute measurementgranularity1, we could end up with deviations of 56.25 - 1687.5 msec which proves to be excessivelylarge when we think about a synchronization algorithm of a few milliseconds accuracy.
The other options left from the POWER DOWN sleep mode impose the external interruptsource as the most likely solution to wake up. To achieve that, we have 2 viable choices: anexternal timer or a real time clock (RTC) module. Both options offer advantages and disadvantagesconcerning energy efficiency, component management source code size and external adoption ofvarious passive components for the electrical circuit. Thus the two alternatives have a very similaroverall impact on the project, I choose the RTC in detriment of the external timer due to the factthat its internal clock oscillator is also temperature compensated. This turns to be an enormousadvantage for precise accuracy in environmental conditions. Further, another benefit is that aseparate temperature sensor is no longer needed since the already integrated one could be directlyused over I2C.
The RTC DS3231 [22] offered by Maxim Integrated seen in Figure 3.6 proved to be a goodchoice, since it fulfills the conditions inferred by this project. Its main features are presented inTable 3.6. An important drawback by using this particular RTC, for the goal of aligning timeschedules between neighbors, is that the interrupts given by it will always have a granularity ofat least 1 second. In that sense, synchronizing in the sub-second domain will need finer-resolutioninformation (milliseconds) which shall be careful managed inside the MCU.
PH SensorWater PH measurements are determined using the sensor [1] provided by IMEC/Holst Center
(seen in Figure 3.8) with the following characteristics:
∗ PH values: 2 − 10
∗ Cl−: µM − M
∗ Flexible (integrated in foil) or rigid technology.
∗ Materials: IrOx & Ag/AgCl electrodes.
∗ Interface: Analog.
Temperature Sensor
1See requirements 17 and 18 from Table 3 on page 65.
Wireless Sensor Network for Water Quality Measurements 15
![Page 29: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/29.jpg)
CHAPTER 3. SOLUTION
Figure 3.8: Holst Center prototype PH sensors
As already seen in paragraph Real Time Clock (RTC) detailed earlier, this project will makeuse of the temperature sensor embedded by the RTC DS3231 chip offered by Maxim Integrated.According to its datasheet [22] there are 3 characteristics which concern us:
∗ Value Range: -40◦C to +85◦C
∗ Accuracy: ±2◦C
∗ Temperature Conversion Current:VCC = 575 µA @ 3.63VVCC = 650 µA @ 5.5V
3.2.2 Power Optimization Analysis
Although power is impacted by most of the choices made when we select the hardware com-ponents, the routing algorithm or application’s behavior, the most important goal of this masterproject is to find a simple and efficient solution for a node to save power by duty cycling. Withoutthis condition, the goal of keeping the network ”alive” for a long period of time, imposed byrequirement 3 from Table 1 inside Appendix, would not be physically possible taking into consid-eration reasonable battery capacities. The approach, by which this goal could be tackled, is toconsider that the algorithm concerning data transmissions in the network is split into rounds ofcommunication. Each round lasts a certain time interval called the Protocol Period (τ). Duringthis period, a node will sleep, wakeup and transmit or route data packets in the network. As wealready noticed from the previous paragraphs, the combined power consumption of the microcon-troller, radio transceiver and RTC can reach ≈100 mA2, which might drain, per example, a 9vbattery with 550 mAh in almost 4 hours3 if they are not properly managed. The energy savingplan is to keep them in sleep mode as long as possible and when the time comes, the RTC canwake them up to start sampling the sensors and to disseminate the data in the network.
According to the high level requirements defined by Table 2 from Appendix, the Radio DataDissemination (RDD) period is defined as being the time in which the microprocessor and radio areboth active and data packets are being exchanged between the nodes. As long as we acknowledgethat the RDD period governs directly the battery lifetime of a node, we can focus our nextanalysis steps on how large shall we make this dissemination period and what metrics are affectedby it. This investigation needs to start from the simple reasoning of how many packets shall anode handle per unit of time taking into consideration factors like the speed of the transmissionmedium, the network topology and the maximum number of nodes in the network. My analysisbegins with the maximum packet size per second (π1sec) expressed as a function of the maximumnumber of packets per protocol period (MAXpackets) and the radio transfer throughput (ϑ).
π1sec =ϑ
MAXpackets(3.1)
2We take into consideration the Arduino Mega2560 board with all the components active, the Xbee module atfull power and the RTC running.
3The calculation is done following the formula: Battery Life = Battery Capacity / Load Current * 0.70
16 Wireless Sensor Network for Water Quality Measurements
![Page 30: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/30.jpg)
CHAPTER 3. SOLUTION
Figure 3.9: Line Topology
The radio throughput (ϑ) expressed in bytes/second can be defined as the maximum serialcommunication baud rate (gross bit rate) between the MCU and the radio transceiver over 8symbols (bits) per byte. Even if MCU’s frequency of 16 Mhz may theoretically sustain a baud of250000 bps for internal UART modules, in practice I have noticed that 115200 bps proves to bea more stable choice to be used to transfer data between the MCU and the Xbee RF transceiver.This gives a maximal theoretical throughput of:
ϑ =115200 (bits/second)
8 (bits/byte)= 14400 bytes/second (3.2)
Since we have a maximum of 100 nodes in the network, we can imagine that in the worst casescenario the topology of the network is a chained link of nodes, as seen in Figure 3.9. Followingrequirement 23 from Table 3, the nodes will need to have their packets received at SINK inmaximum 2 Radio Data Dissemination (RDD) periods. This means that a distant node likeNode100 needs to have its own packet (Packnode 100) delivered to Node50 in one RDD periodmeaning a worst case scenario of 50 hops that need to be achieved. In the next period Packnode 100
has to pass another 50 hops to reach the SINK node. To understand how many individual transfersa node needs to handle each RDD, we need to allow the following situation in which all the nodesissue their own packets: Node100 transfers its own packet (Packnode 100) to Node99. Exactly asNode100 did, Node99 will forward its own packet (Packnode 99) to Node98, but in the same RDDperiod it needs to handle also the packet coming from Node100 and to forward it to Node98.Following this reasoning, we can build up a simple arithmetic model of the maximum theoreticalnumber of packets that needs to be handled in an RDD period.
MAXpackets =
50∑Nodei(packets)
= 1 + 2 + 3 + ...+ 50 = 1275. (3.3)
Since the algorithm needs to be the same on all the sensing nodes, we face the situation that inthe worst case scenario 1275 transfers needs to be handled per RDD period. In this way we arriveat the conclusion that the maximum allowed packet size for 1 second of transmission (π1sec) is:
π1sec =14400
1275' 11, 3 (bytes/second) (3.4)
In this moment, the RDD period can be expressed as the actual packet size over the maximumallowed packet size for 1 second of transmission (π1sec):
RDD (seconds) =πactual (bytes)
π1sec (bytes/second)(3.5)
By having the RDD period, the duty cycle (δ) turns out to be:
δ =RDD
τ% (3.6)
Following the requirements defined in Table 2, the Protocol Period (τ) has a fixed value whichis already decided by the user and cannot be negotiated.
Now, we can turn back to the initial example of 100 mA active power consumption and 550mAh battery and we can also include an ≈1 mA power consumption in sleep mode4 which givesus an average power consumption (AV Gpower) of:
4Xbee Radio on deep sleep mode, MCU in POWER DOWN mode, RTC in time keeping mode
Wireless Sensor Network for Water Quality Measurements 17
![Page 31: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/31.jpg)
CHAPTER 3. SOLUTION
AV Gpower =100 (mA) ·RDDperiod (seconds) + 1 (mA) · [τ −RDDperiod] (seconds)
τ (seconds)(3.7)
If we consider :τ = 15 sec
RDDperiod = 1 sec
}⇒ AV Gpower = 7.6 mA
By following the same battery life calculation as we did before we will end up by having 50hours of operation, which is an order of magnitude greater than the plain unmanaged powerscheme.
As a conclusion, we just followed a logical flow of operations on how we can influence thebattery life with duty cycling, but the main issue is now shifted on how large shall we implementthe packet. The following paragraphs will answer this question.
3.2.3 Routing Protocol
A routing protocol is a set of guiding rules for all the participating nodes in a network whichspecify what actions shall be taken by a node to transmit its own data based on its actual state andan occurring event. A proper routing protocol shall have the following essential characteristics:
Scalability
The nodes contained in the network will execute the same amount of tasks at the same rateno matter the size of the network. Any other addition to the network topology will influencevery little the local behavior of a single node.
Fault tolerant / Robust
Heavy connectivity link loses in my network topology shall not affect proper operation ofthe remaining network nodes if there is a way to communicate with the SINK node.
Self-organizing
Connectivity links can be spontaneous formed in any condition given by the environment.Any new node who wants to join the network does not require to perform complex operationsfor the attachment procedure5.
Self-healing
If a node or a group of nodes lose their old communication links to the SINK node, theyshall be able to form new ones if there are any adjacent neighboring nodes with paths to theSINK node.
Symmetry
All the nodes will behave the same and will have the same priority in the network (flattopology). This is an important aspect compared with a hierarchical topology organizationin which the managing nodes might fail and complex tasks shall be performed for a node tobe promoted in that position.
Simplicity
The network nodes shall be easily deployed and they need to be able to form the topologyin an ad-hoc manner without any adjustments in the software protocol.
Having the advantage of the already present PHY and MAC layers, it is no longer a concernhow the routing protocol shall access the physical medium in a reliable and safe way.
In principle the main operations done by a node during its lifetime are :
5Plug-and-Play behavior
18 Wireless Sensor Network for Water Quality Measurements
![Page 32: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/32.jpg)
CHAPTER 3. SOLUTION
Figure 3.10: Protocol Booting Scenario
∗ Wake-up
∗ Sample Sensors
∗ Transmit Data / Route other packets
∗ Re-synchronize
∗ Sleep
For this project, new nodes who want to join the network will have no a priori knowledge ofneighbors, topology and timing schedules. The protocol ensures that once a node is attached tothe network, it will start transmitting data and the packets will arrive to the common destinationnode i.e. the SINK node. As we previously discussed in Power Optimization Analysis, to extendtheir battery life, all the nodes will need to follow a duty cycling schedule. This fact rises theissue of how a new node joins the network without knowing the sleep/wake-up schedule of others.Figure 3.10 presents a solution which implies that the node knows how long a Protocol Period (τ)lasts. This is used by a Joining Node to start listening for 2 · τ for a communication exchangeto happen between nodes in the proximity. This way, we ensure that there will ultimately be atleast one cycle when the surrounding nodes will wake up and transmit packets, moment used bythe Joining Node to receive their time schedules. In the same time, as a backup mechanism, eachRDD/2 period, the node will broadcast a ”request to join” message type. Since we already knowthat in the RDD period, a node is awake and exchanging information with neighbors, we securethe fact that there will be at least one broadcast received by the other nodes. We also cover thecase in which a node is awake but it does not transmit anything to the neighbors. This ”requestto join” broadcast mechanism will trigger a sum of responses from others which may give the newnode an overview of the surrounding nodes and their schedules. Once this ”Protocol Booting” isover, the new node will be able to adjust its own schedule to the neighbors and it is now consideredan attached node which will join the Radio Data Dissemination (RDD) period the next ProtocolPeriod (τ).
Wireless Sensor Network for Water Quality Measurements 19
![Page 33: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/33.jpg)
CHAPTER 3. SOLUTION
When we analyze a routing protocol, an important measure of Quality of Service (QoS) is therobustness. One of the factors by which we can achieve robustness is redundancy. It represents theduplication of paths that each node is able to build towards the SINK node with the intention todecrease the percentage of lost packets. As long as there are more paths to the destination, thereis a higher probability that a packet is delivered. Redundancy in my routing protocol is built byprotective measures through which a node is able to accept new neighbors without having a specialprocessing period for this purpose. Another way is to have a re-synchronization mechanism afterseveral τ cycles by which the node tries to specifically request its own neighbors to retransmittheir own schedules. Based on requirement 31 defined in Table 3 we need to have at most 1%measurements lost in one day. Starting from this, our next analysis goal is to determine exactlyhow many measurements are allowed to be lost in one day over the entire network. To have anidea of how this constraint needs to be ensured, we shall consider requirements 18, 19 and 20 forthe real project as an example, in which τ has a period of 15 minutes. By simple calculationswe find out that each node needs to have at most 2.16 measurements lost per day6. Using theresult from Equation 3.3 representing the maximum theoretical number of packets that needs tobe handled in each Protocol Period, it results that maximum 122400 packets are expected to betransferred in 24 hours. The consequence is that at most 1244 data packets are allowed to be lost.
Starting from the idea that one of the goals of this project is to find a simple way to routedata, I begin by taking into consideration routing options which seem to be straightforward. Thefastest way for a node to transmit the same packet to all of its neighbors it to broadcast it. Iconsider that the basic algorithm by which I start my reasoning is based on a plain flooding one.All the packets received by a node will be re-broadcasted in order for all of its neighbors to dothe same. The goal is that the packet will eventually arrive to the SINK node. Now the mainissue with a flooding algorithm is that it can become very costly in terms of wasted bandwidth asmessages could be transmitted back and forth between nodes causing what is called a ”broadcaststorm”. To restrict this, a well known solution of Sequence Number Controlled Flooding (SNCF)is employed by attaching the node address and a sequence number to the packet forming a uniquecombination. Once a packet is recognized by a node as already received by inspecting its internalmemory, then the packet is dropped.
The basic goal of this routing protocol is to ensure the fastest path to a common target node(SINK) for all the packets from the network. I allow that every node needs to follow a directeddissemination strategy for the shortest hop distance to the SINK. Since the flooding protocolhas no implicit means for a directional spread of information, a very good way to achieve thisis to implement a gradient (Φ) dissemination policy. The basic idea is that once a new node(nodei)wants to join the network, as we saw earlier, a ”request to join” type of message willbe broadcasted by it. All nodes within the radio range of nodei, which are already attached tothe network, will then respond with their own gradient value +1. If by any means, any otherneighboring node already attached to the network, has a gradient value smaller than the oneoverheard by nodei during attachment process, than its own gradient value will be automaticallyupdated with the smaller value, meaning that a shorter route to the SINK is now available. In thebeginning, it is assumed that the whole process is started by the SINK node which has a gradientvalue of 1.
This way, during the RDD period, broadcast operations issued by a node can be rebroadcastedor not by its neighbors based on its gradient value. A packet, coming from a node with a smallergradient value, cannot be rebroadcasted by a node with a higher or equal gradient value, whichmeans that data cannot travel in an opposite direction of the SINK node. This reasoning worksfor many situations, but there may be cases in which some links could be lost temporary and thusthe packets will be lost. As an example scenario, we can consider Figure 3.11 in which the nodefrom row B and collumn 4 (B4) is desynchronized from its neighbors or its battery is completelydepleted. In this case if node with gradient 4 from (C3) wants to transmit some data, his onlylink to a smaller gradient node (B4) is down, resulting in lost data. Even if this is supposed by besolved by a gradient update procedure, after which the nodes from C3 will take gradients G7 and
6PH: 96 samples/day; Temperature: 96 samples/day; Battery: 24 samples/day
20 Wireless Sensor Network for Water Quality Measurements
![Page 34: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/34.jpg)
CHAPTER 3. SOLUTION
Figure 3.11: Gradient and Deviation Policy
G8, this may take a while and in the mean time all the packets originating from them will be lost.A solution, for this type of problem, might be to introduce a measure ∆ meaning the deviation
by which the above gradient policy can be overruled. In this way, following the example fromabove, all the nodes in the ∆-hop neighborhood, no matter of their gradient value, will accept andbroadcast the packet. This policy can be split into two separate metrics:
∗ Vertical deviation ∆V - a packet can travel, in the ∆-hop neighborhood, to nodes with thesame gradient value from the position it entered that gradient zone.
∗ Depth deviation ∆D - a packet can travel, in the ∆-hop neighborhood, to nodes with agradient not smaller than ∆D units than the sending node.
To better understand the principle, in Figure 3.11, the gradient and deviation policies areshown. It is assumed that ∆V = ∆D = 2. The whole action starts when node with gradient4 (sender from cell C3) wants to broadcast its own data. All the nodes with gradients 5 and 6linked with the sending node, respectively 4 nodes (from cells C3 and C2) will accept and re-broadcast the data. As a consequence of the re-broadcasting scheme, the packet may arrive backto the issuer, as we described earlier, but to avoid broadcasting loops, it is recognized as duplicateand ignored (also depicted in the figure). Once the packet arrives to the first node of gradient 6(cell C2, bottom part), it is considered that the packet cannot travel more in a negative gradientdirection by using the depth ∆D policy, but as the other deviation policy (∆V ) states, the packetcan also travel in the vertical ∆-hop (in our case 2-hops) neighborhood which means that alsothe other two gradient 6 nodes (cells B2 and C2) will rebroadcast the packet. From now on, thepacket can travel only in the direction of the SINK node following the basic gradient principle(the green arrows).
An example of consequence for the vertical (∆V ) policy is that it prevents the node withgradient 2 (cell A5) to receive the packet from the node with the same gradient 2 (cell A4). Thereason is that the data packet had already been traveling for 2 vertical hops from the moment itentered gradient 2 zone (cell B4, bottom node).
The rules appointed by the routing choices so far give us the idea that the algorithm will usea neighboring table with the following fields:
Wireless Sensor Network for Water Quality Measurements 21
![Page 35: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/35.jpg)
CHAPTER 3. SOLUTION
∗ Neighbor ID - unique identifier of a node within the network
∗ Sequence Number - unique identifier of a packet received from that neighbor. This numberrepresents that the last packet successfuly received from that neighbor had this sequencenumber.
∗ Time - this field represents the time on the neighboring node which was sent together withthe last data packet received. As already discussed in the ”Real-Time Clock” paragraph,the granularity of this value cannot reach sub-second domain.
∗ Time Milliseconds - this field represents the finer measuring value of time on the neighboringnode received together with the last data packet received.
∗ Gradient - the actual gradient value that the neighbor has.
∗ Local Time - represents the local time value (on the current node) read from RTC when thelast data packet from this neighbor was received.7
∗ Local Time Milliseconds - represents the local time value (on the current node) which showshow many milliseconds have passed since the gross time value (in seconds) was read fromRTC7. Measure to fine tune the time at which the last data packet was received from theneighbor.
The table entries are filled and update once a packet is received from a neighboring peer. As aredundancy measure, proactive ”hello” messages types will be also broadcasted to maintain thistable up to date, but due to energy constraints, this will happen only once every several ProtocolPeriods (τ). Derived from requirement 24 within Table 3 from Appendix, a node considers that aneighboring link is obsolete if the difference between the present time and Last Time Seen entriesfrom the neighboring table is bigger than 3 · τ .
3.2.4 Application Behavior
From the application point of view the numeric figures start to be shaped from the goal ofmeasuring PH, temperature and battery. The sampling granularity gives the Protocol Period (τ).This metric is chosen from the beginning by the user through requirement 10 as seen in table 1from Appendix.
The important part comes when we must reason on how the samples of data shall be trans-mitted over the air. As we have seen in ”Power Metrics” paragraph, every byte matters in theoverall actions of squeezing the power consumption. In order to decide on that, we must analyzeseparately each data type and their possible value range.
∗ PH measurement - According to the PH sensor’s specifications from page 16, the MCU willuse the ADC controller to sample the voltage values from the sensor’s terminals. If weconsider the specifications of the ADC controller given by the ATmega 2560 datasheet [21],we find out that we will always receive a 10 bit sampling value. Expressing a 10 bit valuein a packet, means to split it into 2 different bytes, although the second byte would have atmost 2 out of 8 bits occupied with real sensor data. In this point we have 2 options:
1. Try to squeeze the packet space by combining several 2-bit remainders from separatemeasurements into a single byte. This high resolution comes at the cost of highermemory space requirement for a packet and additional time spent on processing all thereminders. Both actions resulting in a degradation factor for energy efficiency.
2. Try to normalize the 10-bit value into an 8-bit (1 byte) value. This lower resolution ofthe measurement value is compensated by the smaller packet space requirement and lesstime spent with processing, emerging with less power consumption than the alternative.
7 Also known as Last Time Seen.
22 Wireless Sensor Network for Water Quality Measurements
![Page 36: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/36.jpg)
CHAPTER 3. SOLUTION
Since there is no constraint on the actual resolution on the PH value, I consider that thesecond option, the one which normalizes the measurement value to 1 byte, is more viable interms of power consumption.
∗ Temperature measurement - Granted that the temperature sensor is embedded in the RTCmodule, the MCU will get the value via an SPI communication. Analyzing the possiblevalues that this sensor can provide, I appreciate that we need only 1 byte to cover all thepossible values. This would come very handy since, as we saw earlier, also the PH value willbe expressed in the same amount of memory space.
∗ Battery measurement - Coming more as a maintainability measurement, the method bywhich we will be able to know how much energy is left in a particular node’s battery isby measuring the voltage with the MCU’s ADC controller. Since we already saw in PHmeasurement’s case that it is advisable from the energy efficiency point of view to normalizethe value from 10-bit to 8-bit, we will do the same with this measurement value.
Since the requirements also deal with the amount of time that a node needs to save themeasurements, in case there is no radio communication possible, we need to have some guidingmeasures by which we can reason about. For this purpose we need to refer table 3.2 which givesus the amount of memory available in the system. Among the 8KB of SRAM there are also 4 KBof EEPROM. Taking into consideration that any write operation to the EEPROM can be 1 or 2factors of magnitude more expensive, from the energy efficiency and speed point of view, comparedto the SRAM, we will try to analyze the option of squeezing in the SRAM all the acquired data.This is achievable only of taking care how much we can store without running into stack overflowsituations. Thus the size interpretation of the entire data section will be tackled in Chapter 5,we can presume that using at most 10% of the SRAM for this purpose8 will not affect the overallnode activity. If we consider that sampling battery can be done 40 times less frequent that PH ortemperature, we will end up with the following expression for the number of samples (σ) that canfit in 820 bytes of memory:
σ + σ +σ
40= 820⇒ σ ' 405 (3.8)
As a result we can acknowledge that the maximum time period gained by storing the valuesin 10% of SRAM is σ · τ . As a numeric estimation, if τ = 15 minutes, we will have more than 4days of storage time.
To extend this storing time with a few percentages and also to save energy on radio commu-nication, we can choose to apply the following policy: After a data sample has been acquired, thevalue shall be compared to the last transmitted value from the internal memory. If the values arewithin a certain agreed threshold range, the node will not transmit it.
3.3 Energy Model
Before starting to implement and actually analyze optimal values to the metrics and parametersspecified in the previous sections, it is first advisable to be aware of how the energy cost modelmay look like for the routing algorithm together with all the rules and policies. My protocol’senergy model can be started by first peeking at the basic operations that a single node needs tohandle:
Enode = Ewake operations + Esampling + Eradio communication + Epost computation + Esleep, (3.9)
1. Ewake operations is defined as the sum of energy consumptions for all the operations done toexit the sleep mode and to prepare the node for sampling. This can be described easily by:
Ewake operations = Ertc irq + Cwake + Ertc management, (3.10)
8820 bytes of available space to store sampled data
Wireless Sensor Network for Water Quality Measurements 23
![Page 37: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/37.jpg)
CHAPTER 3. SOLUTION
We consider that each Protocol Period (τ) begins with the interrupt signal from the RTC,therefore Ertc irq is the energy fraction used by the RTC to perform the interrupt. Followingthe interrupt, MCU consumes a small constant energy Cwake to exit from sleep mode to theIDLE mode. After these actions, Ertc management represents the energy used to properly setthe RTC for the next IRQ and to fetch the present time from it.
2. Esampling represents the energy used while all the sensors are powered on and data is beingobtained from them. This energy can be further split into several components involved inthe sampling process:
Esampling = Csample PH + Csample temperature + Csample battery + Epost sampling (3.11)
The first 3 energy pieces cannot be influenced by us since most of the operations are donedirectly by the hardware components, thus they could or could not be added to the finalresult only if we choose to sample a sensor or not in the current protocol period. In thatsense, they are considered constant energy consumption components. The last energy factorEpost sampling is a product of the actions done to normalize the values, arrange them inpackets and also to turn off the ADC module.
3. Eradio communication is the main share of energy consumed by a node. This energy is directlyrelated on how long does the RDD period last. This energy can be described as:
Eradio communication = Crf wakeup + Esender total + Ereceiver total + Crf goto sleep, (3.12)
Since the RF module is turned on and off, there are 2 small constant energy componentsCrf wakeup and Crf goto sleep which are strictly related on how the hardware elements of theRF module reacts, thus they need to be taken into account when we analyze the powerconsumption.
Esender total =∑
∀(ρ ∪ %)
[Esender (per 1 packet)] (3.13)
Esender total represents the consumed energy related to the entire transmissions of own datapackets % and the set of received packets from other neighbors ρ which need to be forwarded.One broadcast operation Esender(per 1 packet) can be further split as:
Esender (per 1 packet) = Etx + Etx computation + Elocal operations. (3.14)
Ereceiver total =∑∀ρ
[Ereceiver (per 1 packet)] (3.15)
where Ereceiver total show the consumed energy quota for receiving packets from the neigh-bors. As above, ρ represents the set of packets received by the current node in one ProtocolPeriod (τ). This energy component can further be divided in :
Ereceiver (per 1 packet) = Erx + Erx computation, (3.16)
Thoroughly depicted in the Xbee datasheet [23], Etx and Erx energy components can beinfluenced only by the length of the RDD period.
Because it is unlikely that all the nodes will have the same ratio of send/receive operations, wemust start a separate analysis of the energy consumption for individual communication links.Derived from the solutions offered by [24] and [25] and following the epidemic flood algorithmassumed in this project, the energy impact Ei on an active link between 2 neighboring nodes,for sending a packet i into a protocol period τ is described by the following expression:
Ei = Esender (per 1 packet) +∑
k∈(Θi∩Λi)
Ereceiver,k (per 1 packet) (3.17)
24 Wireless Sensor Network for Water Quality Measurements
![Page 38: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/38.jpg)
CHAPTER 3. SOLUTION
where parameter Θi is defined as the whole set of sender’s neighbors at the time packet iis being sent and Λi is the subset of Θi neighbors which were in ”Listening” mode at thetime packet i was being sent. Ideally all the neighbors that a node is aware of need to bein listening mode, but due to various reasons, this may not be always the case and we needto take it into account. Note that the potential energy consumption for each packet i inthe network during a protocol period (τ), according to Equation 3.17, is the energy of abroadcast operation plus the energy of receiving on all sender’s k neighboring nodes whichwere in listening mode.
4. Epost computation can be defined as the energy component for all the operations done toprepare the MCU to enter in sleep mode. This can be described as:
Epost computation = Esynchronization processing + Ertc adjustment + Cturn off (3.18)
where Esynchronization processing can be described as the activities done to inspect the neigh-boring table, calculate the RTC deviation, compute new gradient and possibly remove oldentries from the neighboring table. If there is a time difference on the seconds domain thatthe RTC needs to be adjusted, then the energy for this operation Ertc adjustment is thor-oughly depicted in the RTC datasheet [22]. Cturn off is somehow a constant energy elementsince some MCU components need to be turned off and also the MCU has to be put in thePOWER DOWN sleep mode.
5. Esleep is the energy consumption accumulated while the system is in sleep mode9
By analyzing the first part of this model while we recall each component power consumptionpresented earlier in this chapter, we can validate that most of the energy consumption is derivedfrom how much time a node keeps the RF transceiver active (RDD period). Furthermore, if weconsider that this period is influenced by the packet size, we can definitely state that the nextchapters objectives will be to find an optimal balance between the RDD period and the packetsize.
9MCU is in POWER down mode, XBee RF module is in deep sleep mode and the RTC is in timekeepingmode [22].
Wireless Sensor Network for Water Quality Measurements 25
![Page 39: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/39.jpg)
![Page 40: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/40.jpg)
Chapter 4
Implementation
This chapter discusses the design and implementation of the network with respect to thefollowing topics :
∗ Software architecture
∗ Distribution of tasks
To open the discussion about how the solutions from the previous chapter started to be shaped,we first discuss a general overview of the hardware components involved in this project and howthey interface with each other as in Figure 4.1.
We already covered the reasons why these particular hardware elements have been chosen, butnow it is time to understand how they form the WSN and the desired functionality to fulfill its goal.The simplest way to split the entire solution into functionality blocks is to follow the requirementsand different duties. We can identify that there must be a functionality block which deals withthe problem of data accumulation from the sensors. Another immediate software section, whichcan be delimited, is the radio transmission task. By this time, both of the previously mentionedfunctionality blocks cannot deal with the clock synchronization issue. Hence, a new block shall bedefined with the main task to handle the time related issues of the system. Even if it is possible for
Figure 4.1: Hardware Components of a wireless sensor node
Wireless Sensor Network for Water Quality Measurements 27
![Page 41: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/41.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.2: Software Architecture - Functionality Blocks and Interactions
each of those modules to implement their own way to access the hardware components, it is moreconvenient that a separate layer of services will take care of this matter. The main reason why wechoose to do this, is to have a hardware abstraction layer between the actual project functionalityand concreted hardware. If in the future, due to various reasons, we choose to change any hardwarecomponent of the system, we will be able to do this without the need to change all the softwarecomponents involved in that part, but to simply use a new abstraction layer specifically for thenew hardware module.
Figure 4.3:Timed Automatom
As we also depict from Figure 4.2, we decided on the fol-lowing functionality blocks1 2:
1. Hardware Abstraction Layer (HAL) - drivers and soft-ware components which offer to the other software mod-ules the functionality of the hardware elements.
2. Harvest Manager - software module which gathers datafrom sensors
3. Routing Service - software module for managing the radiocommunication on a node.
4. Strategy Manager - supervisor module which manages theschedules for the other SW modules and deals with theclock synchronization in the system.
To describe and analyze the timing and operational flow behavior of the whole protocol stack,we will use the basic timed-automaton theory as depicted in the Figure 4.3. Every time a stateis entered or left, an associated transition is taken and all the linked rules to that transition areimmediately applied. A clock guard timer allows us to guarantee that a certain state will always
1From this moment they will be referred as software modules.2The colors for each SW module and its associated tasks will be kept over the entire document: Gray - HAL;
Red - Strategy Manager; Blue - Radio Service; Orange - Harvest Manager; Green - Sleep/Power related states.
28 Wireless Sensor Network for Water Quality Measurements
![Page 42: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/42.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.4: Basic Operational Flow
be left if the guard expires. ”T = state guard” reflects that its associated transition will be takenif the clock value of T will meet the clock guard’s value.
Following Figure 4.4, the whole protocol stack starts by an Initialization phase which plays thegeneral role of setting up the MCU, RF Module and to associate the node into the network. Aswe previously discussed in the last chapter, every new node will have to adjust its clock with theneighboring nodes. For this purpose the ”Protocol Booting” state allows, a joining node, to listenin two Protocol Periods (τ) for activities of the surrounding nodes. A proactive measure for the”Protocol Booting” is to send once every RDD/2 periods a ”request to join” message. After theinitialization stage, the node enters a low power SLEEP mode. Only by an RTC interrupt signal,the node will be able to wake up and advance into a coordination task hosted by the StrategyManager. At this point, the node is able to start reading from the sensors. The Harvest Managersoftware module takes over to proceed with Data Acquisition related tasks. As soon as datasampling is done, the Radio Service module continues with the Routing Service tasks. When theRDD period ends, the Strategy Manager takes over to re-synchronize with the neighbors. Aftereverything is done, the node goes back into the low power SLEEP state.
A glimpse of chronological actions done by the software modules during each Protocol Period(τ) can be seen in Figure 4.5. More details about each action done by the software modules willbe treated further in separate sections within this Chapter.
Wireless Sensor Network for Water Quality Measurements 29
![Page 43: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/43.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.5: Chronological actions
4.1 Hardware Abstraction Layer (HAL)
This software section emerged from the need to have a ”buffer” like layer which offers properhardware access to higher layer SW modules, without them to actually know how the hardwarecomponents work.
4.1.1 Arduino Software Stack
Although a brief presentation was already made on Arduino when we introduced the MCUboard in Chapter 2, we need to point out some details about how the whole concept works.Arduino is an open source suite of drivers organized under the same framework environment whichare closely accompanied and supported by several hardware platforms. In general, Arduino offersa fast way to overpass implementation of trivial drivers which may add additional time burdenon your project through inherent small problems that could appear due to lack of proper testing.The driver libraries contained by Arduino are a way to kickoff faster towards your goal. Despitethe already mentioned advantages, for an advanced embedded project, which is tight on powerconsumption and space constraints, Arduino does not always offer the proper optimal solutions.
The current project is organized in such a way that there are no advanced actions that ahardware component needs to handle, in a way that Arduino would not be able to provide. Thefollowing drivers from Arduino’s stack are integrated in the project:
• Basic timer access: Used to count the milliseconds.
• UART communication: On ATmega 2560 there are 4 serials available. For this project onlySerial 0 and Serial 2 are used. Within the basic Arduino driver, I have modified the bufferfrom 128 bytes to 64 bytes for both RX and TX and I also changed the way to calculate thering buffer position with fast bitwise operations. Those additions improved the serial driverresponse with ≈4%. The test was made by generating 1 MB of data from Arduino to PC at115200 bps. The transfer time dropped from an average of 76 seconds till the margin of 73seconds. We have to take into consideration that the theoretical speed of 14400 bytes/second(72,81 seconds for 1 MB) had not been achieved because an UART-to-USB converter chip,ATmega32-U2, present on the board, could have a small impact on the overall transfer time.
30 Wireless Sensor Network for Water Quality Measurements
![Page 44: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/44.jpg)
CHAPTER 4. IMPLEMENTATION
• Wire & SPI libraries: Used to interface the RTC @ 400 Hz.
4.1.2 Real Time Operating System
The infinite loop approach is the only way that Arduino offers to perform the processing oftasks. In general, this approach is enough for simple and straight forward tasks without the needto have any scheduling involved. However, I consider that the current project would need a fullembedded operating system with real time guarantees to be sure that the design will properlyfollow the constraints from specifications. Chibios [26] is a real time operating system which ismeant to serve the processing of tasks in a determined the amount of time and offers real timeguarantees on the context switching. The main features provided by this OS are depicted inTable 4.1.
FeaturesPreemptive scheduling (128 priority levels)Round robin scheduling for threads at the same priority level.Threads, virtual timers, semaphores, mutexes, condition variables, event flags, messages, mailboxes, I/O queues.All the kernel structures are static and declaratively allocated, thus no ”need” for a memory allocator.Thread safe Heap & Memory Pools allocator subsystems.Blocking and non-blocking I/O channels with timeout and events generation capability.Size: 6 KB with all options enabled and speed optimizations on.<2 KiB by disabling the the unused subsystems and optimizing for size.PC simulator target included; The development can be done on a PC under Linux or Windows.Written in C and ASM.Free software, GPL3 licensed.
Table 4.1: ChibiOS - Main Features
Though many operating systems are perfectly able to perform most of the features of ChibiOS,the great advantage offered by it, compared with others, is that we are free to choose which featureswe want to include in the core and also that everything is statically allocated directly from thekernel.
As we imagine, each of the functionality blocks already defined need to be independentlyscheduled. For this reason, packing each module under a separate statically allocated thread offera very stable and reliable groundwork to supervise the memory space directly from the compilationphase.
4.1.3 Xbee Driver Library
The XBee 802.15.4 series I, RF modules used for this project, are able to interface with ahost device through an UART port. No matter of the setup choices selected to achieve theradio transmission behavior, we must start a discussion of actually how we communicate with theXBee module. By default, this transceiver operates in Transparent Mode, as a serial replacement,meaning that there is no control on exactly when the frame shall be transmitted or once a frame isreceived, the frame originator is not directly disclosed to the user. An alternative mode of operationis the Application Programming Interface (API) mode which offers the following advantages forour project:
• Direct control of the broadcast without entering in a special command mode specific forTransparent Mode.
• Receives success/fail statuses for the transmitted frames.
• Distinguish the originator address of the received frame.
Besides the actual benefits, the API mode needs the user to take care of all the configurationdetails for each transmitted frame. A particular structured way is desired to communicate with
Wireless Sensor Network for Water Quality Measurements 31
![Page 45: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/45.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.6: XBee generic API frame (datasheet [23])
the XBee module. For this purpose, I chose to implement a special driver library to surpass thesubstantial level of hardware details, which may occur when the Radio Services software modulewould want to access the transceiver. Although trivial operations like transmit or receive hide alot of specific aspects that shall be properly handled by this driver library.
As seen in Figure 4.6 taken from datasheet [23], the basic API structure for any type ofcommunication (internal3 or external) will have a start delimiter, length, frame data and checksum.To start a short discussion about the checksum we need to settle the fact that among the 2 optionsof API operations, I will have to use the API = 2 mode which supports escaped characters. Thismode is implicit if we consider that the payload build by the Hardvest Manager and Radio Servicemay include the following special meaning values: 0x7E - start of frame; 0x7D - escape; 0x11- XON; 0x13 - XOFF. Once an escaped byte is encountered, the operations which have to bedone are to insert an escape (0x7D) pursued by the value XORed with 0x20. Coming back to thechecksum calculation, we need to add all the non-escaped bytes (without the start frame delimiterand length), we must keep only the LSB 8 bits from this sum and in the end this value needsto be subtracted from 0xFF to result the checksum value. In order to verify a checksum for anincoming packet, we need to do a sum over all the bytes (without the start frame delimiter andlength) and if the value if 0xFF after we keep the LSB 8 bits, then the checksum is valid.
Another detail which needs to be sealed, is the fact that 16-bit addresses will be used indetriment to 64-bit ones considering that this project’s network will not exceed 100 nodes.
In the view of all the specifics already discussed, we can briefly go through each type ofcommands needed by the Radio Service.
• TX (Transmission): Following Figure 4.7 taken from datasheet [23], a transmit operation is
Figure 4.7: XBee API frame: TX (Transmission) with 16-bit addressing(datasheet [23])
3setting different configurations directly on the XBee module itself.
32 Wireless Sensor Network for Water Quality Measurements
![Page 46: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/46.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.8: XBee API frame: RX (Reception) with 16-bit addressing
being recognized as having its identifier equal to 0x01. As from the QoS point of view, thereis a possibility to activate/deactivate an ACK response by filling the Frame ID byte with aunique value of the packet (value > 0). This value will be contained by the delivery responseand based on it, the sender can determine if a certain sent packet have been successfulyreceived by the remote node. For this project we will not consider ACK responses due tothe fact that the number of transfers that we have to consider per Protocol Period τ , will bedoubled. I admit that considering this way, we will ensure just a best effort approach, butam I taking this decision to gain the accumulated energy consumed with each packet’s reply.As we already decided by the basic routing strategy, broadcasting will be used, and thereby0xFFFF is the destination address for any transmitted address. Since we just granted thatwe will not use any ACK mechanism, the clear choice is 0x1 (no ACK) for the optionsfield. As limitation of the radio transceiver buffer, the maximum payload size for a frameis constrained at 100 bytes. Later in this chapter, we will appreciate that we can furtherdecrease this size to lower bounds and take a bit of advantage in terms of buffer memorysize occupation.
• RX (Receive): As seen in Figure 4.8 taken from datasheet [23], any received frame has theidentifier value of 0x81. An important field for our protocol is represented by the sourceaddress, which gives a node the ability to distinguish a packet originating from a multi hoplocation4 than one from a direct neighbor. The RSSI and Options fields give different detailsof the packet which are not taken into consideration for the current project. The payload ofthe received packet will match the size of a transmitted one, furthermore being discussed indetail later in this chapter.
The radio modules are being set to operate in a peer-to-peer mode without beaconing. Thiscan be translated that the transceivers do not depend on a Master/Slave relation between eachother. Thus in the 802.15.4 MAC layer standard, we will force the modules to adopt a non-coordinator policy, therefore using an End Device type of association. This can interpreted asthe fact that no action of membership establishment shall be done between any modules. In thatsense, the communication management among radio modules will be transferred to the RoutingService software module.
4.1.4 RTC Driver Library
The DS3231 RTC module used for this project is interfaced with a host device via an SPIcommunication channel. By inspecting its datasheet [22], we discover that there are a lot of
4This issue is further discussed in the section treating the Routing Service software module.
Wireless Sensor Network for Water Quality Measurements 33
![Page 47: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/47.jpg)
CHAPTER 4. IMPLEMENTATION
possibilities to get or set the date and time on the RTC module since it maintains separate fieldsfor seconds, minutes, hours, days, months, and years. Thus we will see further in this chapter thatwe consider time as the number of seconds passed since 1st/Jan/2014, I built this driver libraryto deal with the transformation from the actual value of time to the actions that need to be doneon hardware to set it into the appropriate fields. Also when the date and time is needed from theRTC, a backwards transformation will handle the desired task. By this time, we already agreedthat the clock module will have to issue interrupts at strict intervals to wakeup the MCU fromsleeping. For this purpose the clock module driver hides the detailed hardware procedures formanaging interrupts. It offers the above software layers abstract procedures to access the facilitiespresented by the module.
4.2 Harvest Manager
Given the fact that we have to sample PH, temperature and battery at different time intervalsand to also identify which node detected those measurements, we need to create a generic structureto hold all of these details. As depicted from Table 4.2, this structure contains the following fields:
• Source Address - based on this field we can recognize which node sampled the measurements.The size of 1 byte is enough from the application point of view since there are at most 100nodes contained by the network.
• Timestamp - this field allow us to establish the exact time when the samples were taken.Inspired by Epoch’s Time way to express time, this 4 bytes field will represent the numberof seconds past since 1st/Jan/2014. To understand the principle we need to make a simplecalculation for the number of seconds in a year Secondsyear as following:
Secondsyear ≈ 60 (sec/min) · 60(min/h) · 24 (h/day) · 365 (days/year)
≈ 31536000 (seconds/year)(4.1)
where 31536000 is a number which can be represented on 25 bits of memory. If we considerthat the maximum 32-bit value is 4294967295, we can estimate that this filed is enough tocount seconds for ≈ 136 years, which is more than enough for our application purpose. Theidea to subtract a couple of bits from this field to save some space, is translated into moreoperations done by the MCU for any access to this value. The real gain by doing this is notenough compared with the additional time added by the extra processing steps. As a generalremark, an important factor, when we deal with memory accesses, is to reason about thekind of architecture we use and the wideness of one memory access in order to improve thespeed of our algorithm. In our case, the MCU can access 8-bits per operation, which meansthat as long as we keep the fields a multiple of 8-bits we can avoid doing extra operations.
• Container Control - this 1 byte field can be split into 4 smaller parts as following:
1. # container - represents the number of data fields which are contained into this con-tainer structure. As we will see further, there are maximum 2 data measurements thatcan be included per container, therefore a 2 bit value can cover the maximum numberof data measurements.
Container ControlSourceADDR
Timestamp(seconds) # Containers Data 1 Type Data 2 Type Reserved
DataI
DataII
1 Byte1 Byte 4 Bytes
2 bits 2 bits 2 bits 2 bits1 Byte 1 Byte
Table 4.2: Container Structure
34 Wireless Sensor Network for Water Quality Measurements
![Page 48: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/48.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.9: Harvest Manager - General flow of operations
2. Data 1&2 Type - those fields represent the type of measurements contained by thecorresponding data field (PH, temperature and battery). Also 2 bit field can wrap upthe necessary range of values (0-2).
3. Reserved - Thus, so far we covered just 6 bits from the whole 1 byte assigned, we willleave this field for future use. A possible benefit would be to double the current numberof data types from a 2-bit to a 3-bit value.
• Data I & II - represent the actual sensor measurement values acquired by the HarvestManager task.
I have to mention that I choose to include just 2 data measurement fields into a container sincemost of the time (for my application) just PH and Temperature are being sampled by a node,thus including a 3rd data field may burden too much the packet with improperly used memoryspace. Instead, I choose to include a control byte which gives the whole structure flexibility overthe number of data measurement types that the whole project application may transport andrecognize in the future.
As previously analyzed in Figure 4.4, the Harvest Manager task is signaled by the StrategyManager to start data sampling. If we follow the operations shown by Figure 4.9. we can observerthat sequentially, each sensor is measured. Once a value is available from a sensor, it will bepacked into a container structure. As soon as we have a complete container, it will be pushed intoa delivery list which will be later depleted by the Radio Service during the RDD period.
Wireless Sensor Network for Water Quality Measurements 35
![Page 49: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/49.jpg)
CHAPTER 4. IMPLEMENTATION
Deviation ControlSourceADDR
SequenceNumber
Timestamp(seconds)
Timestamp(milliseconds)
GradientVertical Depth
Number ofContainers
PacketType
Payload
1 Byte 1 Bytemax 9
Containers1 Byte 4 Bytes 4 Bytes 2 Bytes 1 Byte
4 bits 4 bits 4 bits 4 bitsmax 72bytes
Table 4.3: Routing Packet Structure
4.3 Routing Service
Since we already defined the means by which we pack the gathered samples into a structuredway, the next step is to tailor a suitable structure to be handled over the radio. If we considerthat each node transmit only its container in a frame, we arrive at the conclusion that we mayhave too much overhead for the actual measurement data. An additional problem that needs to beconsidered is that we cannot use only the information within a container to properly route data.Deviation and gradient policies can rely only on values carried by individual packets.
As seen in Table 4.3 the packet structure offers all the details for the routing layer to makea clear decision if the packet needs to be forwarded or not. Besides the already trivial fields ofSource Addr, Sequence Number, Timestamp (seconds & milliseconds), Gradient, Deviation Vertical& Depth we need to have a small discussion on the following aspects:
• Control → Number of Containers - represents how many containers are enclosed in a packet.If a node has a received packet which has enough space left to accommodate more containers,it will use that structure to enclose its own containers. In this situation the packet header(all the fields besides the Payload) will be updated as following 5:
1. Source Addr, Sequence Number, Timestamp (seconds & milliseconds), Gradient willhave the current’s node values.
2. Deviation Vertical & Depth will be reset to the default protocol values.
3. Number of Containers field values will be increased with the actual number of containersappended by the current node.
• Control → Packet Type - based on this field the receiving node will process differently thepacket:
1. Normal - represents a regular data packet which needs to be forwarded if it meets allthe requirements.
2. First After Reset - is also a normal data packet, but by using this particular type,a node will be able to notify the neighboring nodes that they need to reset the lastpacket sequence number associated with its ID. Therefore we avoid dropping packets atremote locations just because the neighboring nodes are not aware that the local nodehad been reseted.
3. Boot Request & Response - represent is the ”request to join” packet type referred in theprevious chapters. Thus in this case this is split into separate types request/response.
4. Command Request & Response - although used only for the demonstration part of theproject, these packet types deal with how the commands are handled by nodes.
4.3.1 Neighboring Table
The purpose of this table resides in the ability of a node to choose its own gradient, to determinethe expected sequence number for a particular neighbor and to synchronize with a selected set
5the values unmentioned here are not relevant in this discussion
36 Wireless Sensor Network for Water Quality Measurements
![Page 50: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/50.jpg)
CHAPTER 4. IMPLEMENTATION
NeighborADDR
NeighborSequenceNumber
NeighborTime
(seconds)
NeighborTime
(milliseconds)
NeighborGradient
LocalTimestamp(seconds)
LocalTimestamp(seconds)
1 Byte 4 bytes 4 bytes 2 bytes 1 byte 4 bytes 4 bytes
Table 4.4: Neighboring Table Structure
of neighbors. A new node will have to build a list of surrounding nodes during the ”ProtocolBooting” period as presented in Figure 3.10.
In the routing algorithm, if a packet is received and the frame address and neighbor address areequal, it means that the packet originates from a direct neighbor. This triggers a check betweenthe local gradient and the gradient of the initiator neighbor. If this check results that the neighborhas a lower or equal gradient than the local one, an update on the neighboring table is done. Laterin this chapter, we will see that before the time synchronization phase, we have a neighbor table”reconciliation” which removes all the entries from the table older than two Protocol Periods (τ)or from neighbors having gradients higher than the local node. This mechanism allows a nodeto appreciate its neighbor as missing if there was no activity from a neighbor within the last twoprotocol periods. Implicitly the path offered by that neighbor is no longer valid. By following thepolicy in which the higher gradient node entries are erased, from the neighboring table, we ensurethat only the records used in the synchronization procedure are kept.
Every time a node receives a packet from a neighbor present in the neighboring table, thesequence number is checked to ensure that duplicates are dropped. In that circumstance that apacket is received from multi-hop neighboring node, the duplicate detection mechanism checks itagainst a separate table named Table of Incoming Packets (TIP). The structure of that table isof the form Neighbor Address - Sequence Number. If the check fails, the packet is immediatelydropped. This way we ensure that there will be no packet passing the same node twice.
Although we defined how the packets are detected as duplicates, we can have special circum-stances in which the same data container can be ”allowed” to cross the same node multiple timesas depicted in Figure 4.10. Node X with gradient G4 will broadcast to its neighbors a packet withsequence number Y and Container C1 at time instance 1. Further, both nodes with gradients G3will accept that packet. One of the nodes will forward it directly, but the other will append itsown packet as seen in at time instance 4. The packet will now have 2 containers (C1 and C2), anda new header with ID Z and sequence T. Going further, we will notice that node with gradient G2will accept both packets (X,Y) and (Z,T) and will forward them to the SINK node. By this way,
Figure 4.10: Container Redundancy Scenario
Wireless Sensor Network for Water Quality Measurements 37
![Page 51: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/51.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.11: Island of Nodes Scenario
container C1 could be routed through node with gradient G2 the second time because it is part ofa different packet. This measure is beneficial from the robustness point of view since redundancygives a higher probability for a packet to meet its target.
4.3.2 Gradient Policy
The gradient policy has the purpose to guide the network traffic in the direction of the SINKnode. Considering the situation when a node with gradient Gx transmits a packet and a directneighbor with gradient Gx−1 accepts the packet, it means that the packet has traveled 1 hoptowards the SINK node via the shortest path available.
In Figure 4.11 we present the ”island of nodes” scenario, where a group of nodes looses theconnectivity to the SINK node. This type of situation is hard to be recognized without a proactiverouting protocol. Nevertheless, by using gradients, we have a default solution which may treatthis problem. We grant that a node looses the connectivity with a neighbor when it does notreceive any acknowledgement from its neighbor in a certain period of time. In that case, the nodewill erase its neighbor’s entry from the neighboring table. As an example, when the node withgradient G2 looses the connectivity with its lower gradient neighbor, it will enter in the ”BootingProtocol” phase already described in Chapter 3. There are 2 situations at this point:
• The neighbors will drop their associated neighboring table entries for the node with gradientG2 because they are too old. In this case, they will enter in the ”Booting Protocol” procedure.
• One or both of the neighbors will reply to the ”request to join” message type coming fromthe former gradient G2 node, turning its gradient to G4.
The next phase is that the gradient G3 nodes themselves recognize that there has been noactivity from the former G2 node. In this moment, we are exactly in the same situation whenthe gradient G2 node detected that it has lost its connectivity with the lower gradient neighbor.The next step is to loop again over the actions and we will end up in a situation where each nodeincreases its gradient value. This will be possible till the point where a node will hit the highest
38 Wireless Sensor Network for Water Quality Measurements
![Page 52: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/52.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.12: Gradient redistribution in case link loss
possible gradient value6 (100 ) as seen at steps 99 and 100 from Figure 4.11 and it remains in the”Booting Protocol” procedure searching for neighbors. Thus not the fastest solution, this approachmay also heal the case where one of the gradient G3 nodes could have a neighbor of gradient G4with real path to SINK. This later scenario results into a reorganization of gradients in such a waythat a node will take gradient G5 and the others G6 (as in Figure 4.12).
4.3.3 Deviation Policies
Figure 4.13: Nodes affectedby deviation policies
The deviation policies are routing protocol redundancy gen-erators therefore they give a plus for robustness. Both policiescombined create a packet ”contamination effect” for a lim-ited area around an issuing node. The main purpose of thesetwo metrics is to ensure that in situations where nodes en-counter temporary broken links with lower gradient neighbors,the packets can have a chance to avoid the problematic area.Those 2 metrics are a direct property of the packet and basedon them and the gradient, the routing protocol decides its nextdeviation actions.
To better understand these operations is to follow the ex-ample from Figure 4.13, in which we consider ∆D and ∆V beingequal to 2. When node, from D4 having gradient 2, builds anew packet or appends a container into in an existing packet,the deviation values are reset together with the entire packetheader as described earlier in this chapter. Once the packet istransmitted, there are 3 situations:
• The packet is accepted by gradient 1 node from E4. In this situation both ∆D and ∆V arereduced to 0, therefore the packet will no longer have path detours using those metrics, aslong as a new node does not try to append its own containers to it.
• The packet travels towards the neighbors in the same gradient G2 from column D. At everyhop, the receiving nodes will decrease ∆V . If one of these nodes receives the packet with∆V being zero, then the packet is dropped, otherwise the packet is forwarded. This case isencountered by the nodes from D1 and D7 which drop the packet.
• The packet travels on line 4 towards the neighbors with gradients smaller than the issuer.Exactly as in ∆V ’s case, the ∆D parameter is begin decreased at each hop. When ∆D
6The maximum gradient value is considered to be equal with the maximum number of nodes within the network.
Wireless Sensor Network for Water Quality Measurements 39
![Page 53: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/53.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.14: Routing Service - General flow of operations
becomes null, a neighbor with a smaller gradient than the issuer will no longer accept thepacket.
All the nodes affected (as in the Figure 4.13) will retransmit the packet. Reducing ∆D and∆V to zero, when the packet travels to a smaller gradient neighbor, is imperative to reduce theeffect of contamination. In this situation, if we keep the values for these metrics, we end up into a”broadcast storm” with routing a lot of useless packets. Eventually, they are detected and droppedbased on duplicate sequence numbers, but a lot of processing resources would be spent.
So far, we went through the most relevant rules and we have seen how they react in differentscenarios, but we did not treat yet how the Routing Service task handles the radio communication.As seen in Figure 4.14, once the Harvest Manager task signals that harvesting is done, the RFmodule is turned on. Initially, a random operation is computed which gives a 50% probability thatthe processing will start with RX (receive) or TX (transmit). This is done to reduce the situationwhen all the nodes will try to receive and transmit exactly in the same time, during the RDDperiod. Both RX and TX are states with several internal operations which will have to be servicedin maximum 100 msec. If the task processing enters the RX state, then it is expected that, duringits time quota, packets will be received from the neighboring nodes. As detailed in operationalflow of the receiving task, seen in Figure 4.15a, when packet arrives, it is processed differentlydepending on its type. Once a Normal or First After Reset packet arrives, it is tested againstthe gradient and deviation policies discussed earlier. If it originated from a direct neighbor, thenthe flow will make all the checks and updates on the neighboring table. Otherwise, if the packetis not from a direct neighbor, the checks are done on the TIP table. Further the flow attemptsto append existing containers from the delivery list shared with the Harvest Manager. If thereare any received packets with free space left in the payload, then the available containers will beappended. In this moment, the packet is ready to be pushed into the transmission list shared withthe TX task. If Boot Request or Command Request are received, then the task saves the contextsfor later responses and returns to listening. Once the RDD period is over, the previously savedrequests are granted with responses. By this way we ensure that during the RDD period the datapackets have a higher priority than the other packet types. We consider that if any check fails,
40 Wireless Sensor Network for Water Quality Measurements
![Page 54: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/54.jpg)
CHAPTER 4. IMPLEMENTATION
(a) Receive (b) Transmit
Figure 4.15: Routing Service - Detailed Operational Flow
then the packet is dropped and the flow returns to its initial state.Coming back to the general flow of operations diagram, as soon as the RX state is left, then a
new attempt is made for the remaining containers in the delivery list to be enclosed in a new radiopacket. Further, the TX state (Figure 4.15b) takes over and starts transmitting the packets inthe transmission list shared with the RX task. If the 100 msec quota for TX expires or there areno more packets left in the transmission list, then the processing returns to RX. In any state, ifthe RDD period expired, then the normal flow is immediately left. Boot and Command requestsare now being replied and then, the RF is turned off. Further the Strategy Manager is signaled tocontinue its processing.
Wireless Sensor Network for Water Quality Measurements 41
![Page 55: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/55.jpg)
CHAPTER 4. IMPLEMENTATION
(a) Forward without RTC (basic) (b) Forward with RTC (composed)
(c) Forward with RTC (mixed with backward)
(d) Backward without RTC (basic) (e) Backward with RTC (composed)
(f) Backward with RTC (mixed with forward)
(g) Symbols
Figure 4.16: Time Synchronization - Scenarios
42 Wireless Sensor Network for Water Quality Measurements
![Page 56: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/56.jpg)
CHAPTER 4. IMPLEMENTATION
4.4 Strategy Manager
Till now, we treated the ways to gather data and how to route it through the network. Thoughwe consider that the routing layer is a set of rules and actions, we have not discussed yet whenshall we apply them. The Strategy Manager task is the coordinator process in the system andbased on its outcome, the entire protocol stack makes the node ”integrated” in the network.
We already discussed how we can represent time in this project, but now we must consider atechnique to manipulate it. We know that based on the neighboring table, a node becomes awareof where it is situated in time compared to its neighbors. As we proposed in the beginning, straightforward approaches are favored to keep the processing as simple as possible. As a consequence,we consider that the SINK node gives the time ”reference” in our network. As an example, ifwe assume that a node wants to join, it will enter in the ”Protocol Booting” state to collectinformation from the surrounding nodes. SINK, being in the proximity, it is taken as a directneighbor, therefore its clock will be collected, together with the other data, in the neighboringtable. Now everything boils down to what those values actually represent and how we manipulatethem to make the node aligned in the time domain with the SINK node. For a node, the RTC isa device which provides the time in seconds, but measuring the milliseconds gives us the actualaccuracy needed for synchronization. The milliseconds represent a subdivision of a second whichstart from the last completed second. We already know that the RTC gives an interrupt exactlywhen the present time (represented in seconds) match the alarm previously set. Following thislogic, the MCU wakes up and we consider that we have an ”o’clock” event, therefore we startcounting the milliseconds. When we actually receive a packet, we immediately time-stamp it byrecording the actual seconds given by the RTC when it woke up the MCU and the displacementin milliseconds starting from that moment. By having those concepts clear, following the previousexample, we allow the fact that the adjustment needed when the node wants to synchronize withthe reference node, to be considered in two major scenarios:
• Reference node’s time is ahead - Also seen in Figure 4.16a, we consider the scenario wherethe reference node has the same time represented in seconds with the local node, but the dif-ference is observed in the milliseconds domain. To correct it’s time according to the referencenode, the local node adopts the offset difference in milliseconds between the recorded valuesfrom the neighboring table. When the next Protocol Period starts, the MCU is woken upby the RTC’s interrupt. Then it must wait for this new calculated offset to pass after whichthe RF module can be turned on. This way, the RF modules will be started in the sametime and they will have the entire RDD period to transfer data in the network. Further,in Figure 4.16b an extended forward adjustment case is presented. We can identify thatwhen the difference between timestamps, pass above the milliseconds domain. In this case,the adjustment must be done in 2 steps; First, we must add the right amount of seconds toRTC’s current value. This is interpreted as the future projection of the local node’s timein the same second with the reference node. Secondly, we arrive in the same basic scenariofrom Figure 4.16a and the same actions are applied to produce the new offset used for thenext Protocol Period.
• Reference node’s time is behind - As shown in Figure 4.16d, we allow the scenario wherethe reference node is within the same second borders, but the difference is revealed by themilliseconds domain. To adjust its time to the reference node, the local node adopts directlythe offset presented by the reference node. As the same way we treated in the ”forward”example, the local node will use this offset in the next Protocol Period. Further, if we considerthe circumstances from Figure 4.16e, which shows that the absolute difference between thelocal node and the reference is more than a second, we proceed by adjusting the RTC witha negative value in seconds. This gives us a past time projection of the local node’s timein the same second with the reference node, boiling down to the same basic case discussedbefore from Figure 4.16d.
Thus not yet discussed under their scenario ”categories”, there are 2 ”mixed” cases which share
Wireless Sensor Network for Water Quality Measurements 43
![Page 57: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/57.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.17: Strategy Manager - General flow of operations
both ”forward” and ”backward” techniques. The first case, seen in Figure 4.16c, is a forward casethat does a positive addition to the RTC value. Since this is translated as a future projection oftime for the local node, the fine tunning of milliseconds is done according to the rules of basicbackward adjustment. This is because the projection in the future gives an instant of time in frontof the reference node. Symmetrically the other ”mixed” case can be seen in Figure 4.16f. Forthis occasion, the RTC is negatively adjusted, but the milliseconds offset is calculated as the basictime forward case.
Giving the fact that the former scenarios offered us an accurate analysis on the actual actionsdone for one node to synchronize to the other, we can now start a brief presentation of how StrategyManager employs the synchronization for a node. Figure 4.17 presents a detailed overview of thestates presented in the high level activity context shown by Figure 4.4. As soon as the RTC wakesup the MCU, the Strategy Manager starts counting the milliseconds and sets a timer to expireafter the offset of milliseconds calculated in the previous Protocol Period. In the mean time, theRTC module is requested to give the current time in seconds and the MCU processing slot isgranted to the Harvest Manager.
When the timer interrupts and the Harvest Manager gives the ready signal, the Radio Serviceis allowed to turn on the RF module as seen in Figure 4.18. Thus there is a discussion on how thisapproach works when the offset is 0, I already assume that the minimum offset value by which thetimer is set is the maximum time allowed for harvesting. As the measurements show, there areno more than 5 milliseconds granted for data acquisition. By this way, when the offset is greaterthan 5 milliseconds, the harvesting time is already enclosed, therefore there is no additional timeused by data sampling.
Right after the Routing Service hands out the MCU slot, the Strategy Manager takes over andstarts a neighboring table reconciliation which eliminates higher gradient neighbors and too oldrecords7. After this step, based on the remaining entries in the table, the gradient is recalculatedas the minimum value + 1. If it is not valid, it means that either there are no more entries in thetable or the node is part of an island of nodes without any paths to SINK. This will turn on theradio and the node will start the ”Protocol Booting” procedure. As soon as the period ends andthere are neighbors in the table, the reconciliation step is reconsidered, otherwise the ”Protocol
7In the beginning the node assumes that its gradient is invalid (255), thus all the neighbor table entries arekept for processing.
44 Wireless Sensor Network for Water Quality Measurements
![Page 58: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/58.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.18: Timer Offset Context
Booting” procedure is resumed.In case the gradient is valid, there is a local time synchronization procedure which calculates
the amount of time needed to be adjusted on the RTC, and the new offset (in milliseconds) for thenext Protocol Period. In the time synchronization procedure, we choose the reference neighbor byfollowing the next rules:
1. A set is build out of entries updated in the current Protocol Period.
2. A subset of smaller gradient neighbor entries will be considered from the previous set.
3. If no smaller gradient neighbors were found, the subset will consider entries with neighborsin the same gradient as the local node.
4. After comparing the remaining entries from the previous step, it is selected the entry whichhas the last starting time as seen in Figure 4.19.
By choosing the reference with this reasoning, we favor the situation in which all the smallergradient neighbors will be already awake and listening when the local node starts to transmit
Figure 4.19: Neighbor Reference Choice
Wireless Sensor Network for Water Quality Measurements 45
![Page 59: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/59.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.20: Node Power States
data. Therefore, we create a gradient distribution also in the time domain. In that sense, wewill eventually have some propagated delay in the entire network. Only by real testing we canaccurately measure the length of this delay.
Once the Local Time Synchronization processing is finished, if necessary an RTC adjustment isdone, otherwise the MCU is being prepared for the sleep period and finally the Strategy Managerputs the MCU into POWER DOWN mode.
Going through the node power states diagram from Figure 4.20, we can immediately make aconnection between the actual actions done by the processing tasks and the power state in whichthe node resides. As we previously discussed, we consider as SLEEP state when the MCU is inPOWER DOWN mode and the radio is off. A change on this state can be made only by an RTCinterrupt at time T=τ which resets T to zero. REDUCED POWER state is considered whenthe MCU is active, but the RF modules is not yet turned on. This state directly blends withthe entire time quota spent on processing by the Harvest Manager and Strategy Manager. Whendata sampling is ready and the offset timer expires we switch to the ACTIVE state by turningon the RF module for at most RDD seconds. The shift to the SLEEP mode is done through theREDUCED POWER state as soon as the radio is turned off and the synchronization process isfinished.
4.5 Data Harvesting Application
Apart from all the solution details debated in this thesis, the high level goal is to offer acomplete HW and SW solution which could provide direct measurements from the field. For anon-technical user, the information acquired by the network nodes needs to be presented in acoherent way. In order to achieve this, a PC software had to be implemented.
This software solution is able to connect to the SINK node and to receive all the data packetssent by the network nodes. The useful information is extracted from each packet to be furthershown on intuitive plots. An important aspect is that the user can follow how the measured en-vironmental parameters change over time. The application displays PH, temperature and batterylevel as seen in Figure 4.21. Each node has its measurements displayed in it’s own separate tab.When a node joins the network, a new tab is dynamically added. The date and time of the lastreceived packet from a node are separately shown to easily identify if the measurements from thatnode are recent of not.
46 Wireless Sensor Network for Water Quality Measurements
![Page 60: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/60.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.21: Data Harvesting Application User Interface
4.6 Sniffing Application
This project, observed in a quantifiable manner, is an embedded solution which is deployedon several devices. Starting from that, troubleshooting the behavioral on each individual devicerunning the WSN software stack implies a very labor intensive job. A resolving answer was tocreate a new software framework which could show details in real-time of how the nodes react”as a network” to different triggered scenarios. As already stated in the previous chapters, aseparate device named SNIFFER employs the role of debugger for the rest of the nodes. It is ableto receive all the packets transferred between the nodes in range from the surrounding network.The application is also capable to transmit several types of commands in order to apply differentcharacteristics on the nodes. Apart from this separate device entity, each node has additionalfunctionality embedded in the software stack to handle requests from the SNIFFER device. A PCapplication connects to the SNIFFER and every frame transferred in the neighborhood is sniffedand processed in real-time. Based on the packets received, the application displays the currentnetwork topology in a user friendly manner as seen in Figure 4.22. Events like appearance ordisappearance of nodes are intuitively shown to the user. The links displayed by this applicationreflects the actual neighboring table adjacencies. When a transmission is detected, the form ofthe links change to indicate this and the issuing node is highlighted. States like ”just rebooted”,”looking for neighbors”, ”joined the network” or ”responded to command” in which a node canreside at some point, are also displayed in real-time for each individual device.
Wireless Sensor Network for Water Quality Measurements 47
![Page 61: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/61.jpg)
CHAPTER 4. IMPLEMENTATION
Figure 4.22: Sniffing Application User Interface
The most important feature of this framework is that we have total control of the network. Weare able to change several parameters like time, gradient and node ID or we can directly inspecteach neighboring table. Apart from that, to simulate different scenarios we are able to inject inthe network a desired topology formation by allowing or denying neighboring relations betweennodes, even if they are located nearby and direct communication links could be formed. By thisway, the overall protocol stack behavior is tested as it would be in a real life deployment situation.
48 Wireless Sensor Network for Water Quality Measurements
![Page 62: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/62.jpg)
Chapter 5
Experiments and Evaluation
Since this project is a practical attempt to achieve power efficiency in an environmental WSN,the focus of the whole evaluation process is directed on checking if the proposed requirementshave been achieved. A testbed of 4 nodes, one SINK and one SNIFFER was used to evaluate theperformance of the protocol stack on real platforms.
5.1 Node Power Consumption Assessment
As we chose to use general of-the-shelf development boards and radio modules, an energyefficiency analysis of the whole node needs to be done. This fact will give me a reference on whatis possible to be achieved with the current platform and what is the ideal promises of a custombuild one.
When we start discussing the power consumption of our node platform we need to be awareof all the components that can drain power. As seen from Table 5.1 we can expect that someredundant components will have to be removed to save at least the quiescent power consumed bythem.
Component Type Component CodeArduino Platform:MCU Atmega2560USB convertor MCU ATMEGA16U2Operational Amplifiers 2 x LMV358IDGKRVoltage Regulator 15v to 5 v NCP1117ST50Voltage Regulator 5v to 3.3v LP2985ADiodes CD1206-S01575Fuse MF-MSMF050Leds x 4Radio Module XbeeReal Time Clock Module DS3231Xbee Adaptor Board:Regulator 3.3v MIC5219
Table 5.1: Node Components List
By following the steps from Table 5.2 we can observe that this general purpose Arduino boardis not ”ready” by default for a very low power project. Several trial and error steps had to betaken in order to claim that we achieved a reasonable power consumption for the prospective powerstates of the node. The final measurement outcome gives us a power consumption of 70 mA forthe ACTIVE state, 18,1 mA for the REDUCED POWER state and 290µA for the SLEEP state,fact used later in this chapter when we determine the number of operational hours of this project.
Wireless Sensor Network for Water Quality Measurements 49
![Page 63: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/63.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
Step Action DoneMeasuredCurrent
PowerState
1
MCU Active @ 16 MHzUSB MCU Active9V supplyNothing attached to the Arduino board
49.39 mA
2Removed voltage regulator (15V to 5V)5V direct supply
35.3 mA
3 Lower the supply to 3V 28.6 mA4 Xbee adaptor board attached 28,7 mA5 RTC module attached 29,1 mA
6Removed power amplifiers from the Arduino boardRemoved 3.3 v converters from both the Arduino board and the Xbee Adaptor
19 mA
7Attached the RF module with the settings presented in Table 5.3RF module Active (RX)
73 mA
8Attached the RF moduleRF module Active (TX)
72 mA
9 RF module pins: CTS & DIO1 grounded 71,3 mA10 Leds removed from Arduino Board 70 mA Active
11RF module on sleepMCU Active @ 16 MHz
18,1 mAReducedPower
12 MCU put to sleep in POWER DOWN mode 3 mA
13MCU: Disabled all internal modules (UART, ADC, SPI, etc.)MCU: All general purpose pins set as output lowMCU: SPI pins: CLK, MOSI, MISO set as output high
0.29 mA Sleep
Table 5.2: Power Consumption Measurements
Setting Name Chosen Option Option CodeCoordinator/End Device (CE) End Device 0End device association No association 0RF Power Level (PL) -10 dBm 0RF CCA Assessment (CA) -44 dBm 0x2CSleep Mode (SM) Hibernate 1Sleep Options (SO) Disable wakeup pool 1Serial Interfacing (BD) 115200 baud 7API Enable (AP) Api with escaped characters 2All I/O ADC & PWM options DisabledAssociation Indicator (D5) Disabled 0CTS Enable (D7) Disabled 0RTS Enable (D6) Diasbled 0
Table 5.3: Xbee Firmware Settings
5.2 Radio Data Dissemination Period
As we studied in the previous chapters the RDD period directly influences the average powerconsumption of the nodes. Therefore by minimizing this duration, we directly influence the expec-ted network lifetime. At this point we can restore the discussion about how many seconds do weneed to have the radio module active in order to accommodate the worst case topology scenarioproposed in Figure 3.9. The result will show that by using a direct approach imposed by the initialreasoning from equations (3.3) to (3.5), we will end up with longer periods of radio dissemination,therefore more power consumed. If we apply directly the equation (3.5) considering that πactual= 25 (bytes)1, we end up with:
RDD (seconds) =πactual (bytes)
π1sec (bytes/second)=
25 (bytes)
11.3 (bytes/second)≈ 2.21 sec
1Frame header (8 bytes) + Maximum payload length (17 bytes) considering a merged structure between apacket and a container: packet header (14 bytes) [seen in Figure 4.3] + container data part (3 bytes) [seen inTable 4.2]
50 Wireless Sensor Network for Water Quality Measurements
![Page 64: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/64.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
Figure 5.1: RDD period influenced by thenumber of containers enclosed in a packet
Figure 5.2: Delay measurementTopology
This is a reasonable solution, but if we consider that we can accommodate more containersinto a packet, as proposed by the radio packet structure from in Table 4.3, we can have a smal-ler expected number of transmissions MAXreal packets that we may consider using the followingequation:
MAXreal packets =MAXpackets
# Containers. (5.1)
Giving the fact that, as long as we increase the number of containers in a packet, we decreasethe required number of transmissions per RDD, the following implications arise:
• Almost 300% increase of ”useful”2 data per frame can be achieved. Starting from 26,6% (1container per packet) till 76,6% (9 containers per packet).
• The accumulated time of the MAC layer accesses to the medium is decreased. For eachtransmitted frame, the MAC layer needs to gain access to the medium. Once the mediumis granted a node can transfer an entire frame in one step, but if there are more frames tobe transmitted, then the medium access needs to be granted again, therefore the less frameswe have to transmit, the less time wasted with medium access.
• The packet processing time rises for each appended container.
• If a packet is lost, the potential useful data loss ratio increases proportional to the numberof containers within a packet.
To study how the number of containers affect the RDD period, I employed a special setup inwhich a node generates a packet and starts to append containers to it exactly as in a real situation.Once the desired number of containers are appended, the packet is sent to the SINK. When theSINK receives the first container a chronometer starts counting and when the desired number ofpackets are achieved, the chronometer is stopped.
Following the plot from Figure 5.1, we realize that the estimated RDD period has a continuoustendency to drop as long as we increase the number of containers within a packet. This effect is nolonger valid when we follow the real measured RDD period needed to finish the associated numberof transfers for each packet size. I observe that starting with the 7th container, the RDD period has
2We consider ”useful”: (2 bytes) data values + (1 byte) data types + (4 bytes) sampling time + (1 byte)neighbor address
Wireless Sensor Network for Water Quality Measurements 51
![Page 65: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/65.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
(a) Experiment A: Same gradient neighbors (20 milliseconds delay)
(b) Experiment B: Different gradient neighbors (16 milliseconds delay)
Figure 5.3: Delay measurements between the RDD starting points on 2 neighboring nodes
a slightly increasing tendency. This matter emerges due to increasing processing time to appendmore containers to a packet. Giving this fact, the protocol stack will optimally operate withmaximum 6 containers. This triggers a small cutback from the buffer size needed to accomodatethe frame payload from the value of 100 bytes to 70 bytes. The outcome after this experiment is
52 Wireless Sensor Network for Water Quality Measurements
![Page 66: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/66.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
that the RDD value is approximated to 1,5 seconds.The next experiments have the goal to determine how does the starting delay between neighbors
affects the RDD period. For these experiments, 3 nodes + SINK are used in a topology as seenin Figure 5.2. To study the starting delay we need to consider 2 neighbors in the same gradient(Experiment A) and 2 neighbors with consecutive gradients (Experiment B). The oscilloscopemeasurements were made directly on the signals which turn on the radio modules from those nodes.The delay is determined by a subtraction function which is calculated between the acquired signalsby the oscilloscope as seen in Figure 5.3. The experiments were done over 4 hours of operationwith τ = 15 sec and RDD period fixed at 1 sec. Both experiments presented delays of ≈ 20milliseconds (Experiment A: 20 milliseconds; Experiment B: 16 milliseconds). Considering thisdelay and the derived requirement from previous chapters in which 50 hops must be traveled bya packet in one RDD period, we can extrapolate that comparing 2 nodes found 50 hops away oneof each other, we will end up with 1 second3 delay between their RDD kickoff times.
By using this result and the one from above in which the RDD is influenced by the numberof containers, we can state that a lower gradient node needs to stay awake 1 second more incomparison to its neighbor situated 50 hops away. This ensures that all the packets transferredby the distant node will be received. Since the beginning, I assumed that all the nodes will havethe same behavior. Therefore each of them will have to add an extra second to the previous RDDperiod of 1,5 seconds, resulting in the final choice of 2.5 seconds for the RDD period.
5.3 Network Life Expectancy
Till now we have considered how the RDD period can be influenced by the amount of datathat needs to be transferred in each frame. Since one of the project goals is to offer a long periodof deployment, we need to reason about what battery capacity is needed to sustain the projectrequirement of 9 months of deployment. The next prediction will use all the real parametersgathered till now as seen in Table 5.4.
Parameter Name Value UnitProtocol Period (τ) 900 secondsRDD 2,5 secondsBattery Capacities 550 - 6000 mAhCurrent node ACTIVE mode 70 mACurrent node SLEEP mode 290 µACurrent Reduced Power mode only with the MCU active (RP1) 18,1 mACurrent Reduced Power mode only with the XBee module active (RP2) 52,3 mA
Table 5.4: Energy prediction parameters
Following the example given by the average consumption equation 3.7 from the SolutionChapter, we can derive:
AV Gcurrent consumption =Activecurrent ·RDDperiod + SLEEPcurrent · [τ −RDDperiod]
τ(5.2)
The battery life is estimated as:
Battery Life =Battery Capacity
AV G current consumption· 70% (4)
As seen in Figure 5.4 the target of 9 months starts to be achieved using a rated battery capacityof 5200 mAh. Thus this plot shows only a calculated estimation, real experiments had to be done
320 milliseconds for each hop · 50 hops = 1000 milliseconds4The 70% factor makes allowances for external factors which can affect battery life.
Wireless Sensor Network for Water Quality Measurements 53
![Page 67: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/67.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
Figure 5.4: Operational Time vs Battery Capacities
to prove the validity. By using a 6LR61 - 9V battery with a rated capacity of 550 mAh and τ =15 seconds, I have made 2 experiments as following:
• The first experiment was done with the modified Arduino 2560 board in which most of thecomponents were stripped off according to Table 5.2, therefore the current consumption inACTIVE mode was 70 mA and in SLEEP mode 290µA. The predicted time is 32,33 hours,but the real experiment shown 38.91 hours of operation with frequent disconnects startingfrom hour 35. The result shows an increase of ≈20% comparing with the estimated time.
• The second experiment was done with a stock Arduino 2560 board in which the measuredcurrents were: ACTIVE mode (92 mA) and SLEEP mode (22 mA). The predicted time is12,83 hours, but the real experiment proved that the operational time reached 15,8 hours. Iadmit, that after the 14th hour there were seen a lot of connection problems and lost packets.Nevertheless, the outcome is ≈23% more than the estimated time.
As both experiments shown a plus of 20% comparing with the estimation, I am permitted tostate that the estimation from Figure 5.4 is valid.
Although the estimation results prove that they fulfill the initial requirements of 9 months,we add additional evidence that the power saving strategy from this project is better than othersolutions from literature presented in Chapter 2. For this purpose we may consider 2 generalpower saving scenarios:
• Reduced Power mode 1 in which only the radio module is turned off while the node needsto save power. This experiment results into a power consumption of 18,1 mA. Followingequation 5.2 in which the SLEEPcurrent is replaced with RP1current we achieve an averageconsumption of ≈18,2 mA resulting in ≈200 operational hours for the 5200 mAh batterycapacity. This result is 37 times smaller than the case in which both the MCU and RFmodule are turned off during sleep mode.
• Reduced Power mode 2 scenario in which only the MCU is turned off while the radio module iskept idling when node needs to save power. This experiment results into a power consumption
54 Wireless Sensor Network for Water Quality Measurements
![Page 68: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/68.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
of 52,3 mA. Following equation 5.2 in which the SLEEPcurrent is replaced with RP2current,we achieve an average consumption of ≈52,3 mA resulting in ≈69 operational hours for the5200 mAh battery capacity. This result is 109 times smaller than the case in which boththe MCU and RF module are turned off during sleep mode.
5.4 Packet Drop Ratio
As we already analyzed in the previous chapters, we need to acknowledge that at most 1%of usable data can be lost in one day. Therefore, we are not allowed to miss more than 24measurements per node during 24 hours or more than 1244 missed packets. The experimentsundertaken to evaluate this requirement were run for 8 hours and used τ = 15 seconds and RDD= 2,5 seconds. By following a simple arithmetic calculation, a node transmits 1920 times during8 hours.
• The first experiment goal was to test the frame consistency for a direct link from one nodeto the SINK. It has been observed that 9 packets were lost (0,47 %). Only 5 packets werelost due to CRC check issues and 4 were not received at all.
• The second experimental goal was to test how many packets can be lost on a line topologyconsisting of only 4 nodes, but with a variable number of data issuers. The nodes were
Figure 5.5: Estimated error ratio per node per day
Dataissuers
Packets/ node
/ τ
Packets/ node/ day
Packets/ network
/ day
Packets Lost/ network
/ day
% Loss/ network
/ day
Avg Packet loss/ node/ day
% Loss/ node/ day
Percentageincrease
1 1 1920 1920 15 0,67 % 3,75 0,195 %2 3 5760 11520 46 0,69 % 11,5 0,200 % 102,222 %3 6 11520 34560 95 0,74 % 23,75 0,206 % 103,261 %4 10 19200 76800 164 0,8 % 41 0,214 % 103,579 %
Table 5.5: Packet loss in a line topology with 4 nodes
Wireless Sensor Network for Water Quality Measurements 55
![Page 69: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/69.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
forced to always build a new packet for their own data in order to generate more traffic inthe network. According to Table 5.5 we have the following parameters:
1. N - number of packet issuers per experiment
2. #τ - represent the number of Protocol Periods (τ) in one day
3. Packets/node/τ = [N · (N+1)] / 2 - represent the number of packets that a node shallhandle per τ .
4. Packets/node/day = #τ · Packets/node/τ - represents the number of packets that anode shall handle per day.
5. Packets/network/day = Packets/node/day · N - is the number of packets expected overthe entire network in a day.
6. Packets Lost/network/day - is the measured number of lost packets over the entirenetwork during one day. This number is determined by how many packets have beendetected as missing on the SINK node.
7. Percentage increase - is the ratio of increase between 2 consecutive loss rates (%Loss/node/day).It represents how much increase in loss ratio arose from adding another data issuer inthe network.
Thus to be able to extrapolate our experiment to the maximum network size, I am usingthe average of 103,0207 % over the percentage increase loss ratio. By this approach, I canestimate the loss ratio per node when there is a full network formation (100 nodes). As seenin Figure 5.5 the target of 1% is not achieved by keeping the same increase ratio of packeterrors.
It is observed that the current WSN application has more packet loss ratio than it was planned.I expect that most of the errors emerge from both design and implementation issues. The RDDperiod was kept to 2,5 seconds to eliminate the possibility that a node does not complete sendingall of its packets in the allocated time quota. Since all the nodes are in the same place, each timea node transmits all the others receive, therefore it is expected that a lot of processing is donefor overheard packets which are eventually dropped. At the same time, there could be also errorsincurred directly by the Xbee firmware. A possible solving solution would be to introduce an ACKmechanism for each transmitted packet, but this would trigger totally different design choices.
5.5 Memory Assessment
Since in any embedded project, memory is a scarce resource, a restrained conduct must beemployed for every level of project design, starting from the high level architecture decisions till theimplementation phases. After a memory demand analysis was done on different implementationsteps of the WSN application, we conclude according to Table 5.6, that only 34% out of 8KBof SRAM is required by our application. As we previously assumed that we will use the SRAMmemory to store measurement values in case there is no radio communication possible, we cansafely evaluate that adding an extra 10% usage to the SRAM will not affect the overall behaviorof our project.
56 Wireless Sensor Network for Water Quality Measurements
![Page 70: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/70.jpg)
CHAPTER 5. EXPERIMENTS AND EVALUATION
Step Feature Program Section% from
256K - FlashData Section
% from8K - SRAM
1 plain Arduino Sketch 490 0,19 % 9 0,11 %2 + Serial 1750 0,67 % 184 2,25 %3 + Wire (uninitialized) 2960 1,13 % 391 4,77 %4 + Wire (initialized) 3320 1,27 % 391 4,77 %5 + RTC Lib (initialized) 7660 2,92 % 588 7,18 %6 + ChibiOs Library (no Thread) 8318 3,17 % 605 7,39 %7 + ChibiOs (Main Thread Only) 9646 3,68 % 714 8,72 %
8+ ChibiOs(1 bare thread with 0 bytes allocated Stack)
9674 3,69 % 795 9,70 %
9 + ChibiOs (1 semaphore) 9776 3,73 % 799 9,75 %10 + Analog read 9964 3,80 % 801 9,78 %
11+ Strategy Manager thread (256 bytes - Stack)+ Harvest Manager thread (128 bytes - Stack)+ Routing Service thread (300 bytes - Stack)
42842 16,34 % 2805 34,24 %
12Compiled with:a) Optimizations for size (-Os)b) No debugging symbols
27984 10,68 % 2837 34,63 %
13 - Debugging traces from code 24312 9,27 % 2837 34,63 %14 - Demonstrator Features (command interface) 21744 8,29 % 2822 34,45 %
Table 5.6: Memory demand for the WSN application
Wireless Sensor Network for Water Quality Measurements 57
![Page 71: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/71.jpg)
![Page 72: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/72.jpg)
Chapter 6
Conclusions and Future Work
In this thesis a WSN was built for environmental monitoring applications. The major goalof this project focused on how a WSN can achieve long time deployment and at the same timeto be robust against bad connectivity links. Thus, in general, these concepts are in conflict, thesolutions presented in this thesis aligned all the necessary measures to fit into a clever design bothworlds.
Lowering the power consumption gives us an improved network lifetime which can ensure alonger deployment period. Several strategies have been employed to enhance the energy efficiencyat every stage in the design process. We have seen that low energy footprint reasoning can betackled in all the hardware and software layers. Thoroughly debated in this document was howthe nodes can be active for a small amount of time during which they shall be able to disseminatedata in the network and the rest of the time to be in a dormant state, to save power.
The major claim of this project consists in the novelty concept that in SLEEP mode we turn offboth the MCU and the radio transceiver module. Using an external RTC for an accurate notionof time, they are properly woken up and still be synchronized with their neighbors. The analysisrevealed that by using this approach, each node is able to conserve more battery power comparedwith the alternative options.
Routing data in the network makes the link between the two worlds of power consumptionand robustness. As seen throughout this document, when we debate the power consumption issuewe also have to address the disadvantages brought to robustness. One tackled issue was how togenerate enough redundancy to increase the probability that packets can arrive to their destination.Several policies like gradients, deviations, neighboring tables or smart packet structures wereemployed to generate a well balanced redundancy in the network.
This project provides a complete solution which was started from choosing the right com-bination of HW elements, implementing a suitable software stack and finally building a softwareapplication for PC to examine the measured data through intuitive plots. A real-time debuggingframework solution was also realized especially for the demonstrator part of the project. By usingthis facility, different behavioral scenarios were possible to be investigated on the protocol stackin a user-friendly manner.
Summarizing the above, the following contributions were done in the thesis:
• Major power savings were achieved in sleep state by turning off the MCU and the RF module,while an RTC was employed to wake them up at the proper moment to disseminate data.
• Gradient strategy in combination with other redundancy generating policies were used todisseminate data and to organize the topology awareness for the routing protocol.
• A testbed of 6 nodes was created to evaluate the performance of the network solution.
• A real time debugging framework was built to visualize in an graphical manner the protocolstack behavior in different topology scenarios.
Wireless Sensor Network for Water Quality Measurements 59
![Page 73: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/73.jpg)
CHAPTER 6. CONCLUSIONS AND FUTURE WORK
• A user PC application was built to visualize the sensor measurements on intuitive plots.
Considering the work achieved by this project, I recommend the following directions for futureendeavors:
An improvement on the synchronization algorithm employed by this WSN application, maysolve the extra second added to the RDD period. I appreciate that this occurred due to chaineddelays on the neighboring paths starting from the network boarder nodes till the SINK node. Itwas proven in the evaluation chapter that the synchronization policy will always have a small,but predictable delay, injected by various reasons like processing time and software or hardwaredesign choices. A more involved approach of neighbor clock synchronization would be to actually”predict” the future neighboring time. Solving this issue by following this concept, we can improvethe overall power metrics.
As confirmed by the experiments, the Arduino board and Xbee radios used were useful forthe proof of concept, but having a dedicated hardware platform can solve most of the problemsregarding power consumption. Fitting a less featured radio module and microcontroller on thesame board and running them at lower voltages and frequencies can extend the overall nodelifetime. An indirect improvement by pursuing this path would be a better radio link qualitywhich would be a result of less interferences and higher compatibility between these components.
Considering that the actual evaluation of this project consisted mainly on experimental resultsof a much smaller topology than the one aimed by this WSN application, a simulation of the entireprotocol stack may reveal several hidden design and implementation issues, which would be veryhard to observe only by testing the real platforms. In that sense, trends for the metrics proposedby this project can be granted easier and the already presented estimations may be accuratelyvalidated.
60 Wireless Sensor Network for Water Quality Measurements
![Page 74: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/74.jpg)
Bibliography
[1] Marcel Zevenbergen. Ion sensor for fluid monitoring. Technical report, IMEC, 2013. 1, 15
[2] World Health Organization (WHO) and United Nations Children’s Fund (UNICEF). Progresson sanitation and drinking-water. Joint Monitoring Programme (JMP) for Water Supply andSanitation, 2012. 1
[3] United Nations Development Programme (UNDP). Beyond scarcity: Power, poverty and theglobal water crisis. Human Development Report, 2010. 1
[4] Guy Hutton. Global costs and benefits of drinking-water supply and sanitation interventionsto reach the mdg target and universal coverage. Human Development Report - World HealthOrganization (WHO), 2012. 1
[5] UNESCO. Water and energy. United Nations World Water Developement Report, 2014. 2
[6] Jean-Christophe Vi; Craig Hilton-Taylor and Simon N. Stuart. Wildlife in a changing world ananalysis of the 2008 iucn red list of threatened species. International Union for Conservationof Nature and Natural Resources, 2009. 2
[7] Andrew S. Tanenbaum. Computer Networks, volume 5. Prentice Hall, 2010. 3
[8] Robert Faludi. Building Wireless Sensor Networks: with ZigBee, XBee, Arduino, and Pro-cessing, volume 1. O’Reilly Media, 2011. 3
[9] Wen-Yaw Chung; Chien-Lin Chen; Jyen bin Chen. Design and implementation of low powerwireless sensor system for water quality monitoring. IEEE, 2011. 5
[10] Zulhani Rasin and Mohd Rizal Abdullah. Water quality monitoring system using zigbee basedwireless sensor network. International Journal of Engineering and Technology IJET-IJENS,2010. 5
[11] B. OFlynn et all. Smart coast - a wireless sensor network for water quality monitoring. 32ndIEEE Conference on Local Computer Networks, 2007. 5
[12] Marco Zennaro et all. On the design of a water quality wireless sensor network (wqwsn): anapplication to water quality monitoring in malawi. Vienna - IEEE, 2009. 5
[13] Ho-Hyun Lee et all. Propagation analysis of wireless mesh network for real-time monitoringaround the four major rivers in south korea. International Symposium on Communicationsand Information Technologies (ISCIT) - IEEE, 2012. 5
[14] Mudasser Iqbal; Andrew J. Whittle Michael Allen; Ami Preis. Water distribution systemmonitoring and decision support using a wireless sensor network. 14th ACIS InternationalConference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distrib-uted Computing - IEEE, 2013. 6
[15] R. Fan and N. Lunch. Gradient clock synchronization. PODC04, July 2528, 2004, St. Johns,Newfoundland, Canada. ACM 1-58113-802-4/04/0007, 2004. 6
Wireless Sensor Network for Water Quality Measurements 61
![Page 75: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/75.jpg)
BIBLIOGRAPHY
[16] Sommer Phillip; Wattenhofer Roger. Gradient clock synchronization in wireless sensor net-works. San Francisco, CA - IEEE, 2009. 6
[17] Andre C. Pinho; Daniel R. Figueiredo; Felipe M.G. Franca. A robust gradient clock syn-chronization algorithm for wireless sensor networks. Bangalore - IEEE, 2012. 6
[18] Lamonaca Francesco; Gasparri Andrea; Garone Emanuele; Grimaldi Domenico. Clock syn-chronization in wireless sensor network with selective convergence rate for event driven meas-urement applications. IEEE Instrumentation and Measurement Society, 2014. 7
[19] Gabriel de Barros Moreira Beltro et all. Effects of riparian vegetation on the structure of themarginal aquatic habitat and the associated fish assemblage in a tropical brazilian reservoir.Biota Neotropica vol.9 no.4, 2009. 7
[20] IEEE Computer Society. Ieee standard for local and metropolitan area networks part 15.4:Low-rate wireless personal area networks (lr-wpans). IEEE Standard 802.15.4, 2011. 12
[21] Atmel Corporation. Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V - Datasheet, 022014. 2549QAVR02/2014. 13, 14, 22
[22] Maxim Integrated. DS3231 - Extremely Accurate I2C-Integrated RTC/TCXO/Crystal, 012013. rev. 9. 15, 16, 25, 33
[23] Digi International Inc. XBee/XBee-PRO RF Modules, 07 2013. Product Manual v1.xEx -802.15.4 Protocol for RF Module Part Numbers: XB24-A...-001, XBP24-A...-001. 24, 32, 33
[24] Emrah Cem et all. Energy cost model for frequent item set discovery in unstructured p2pnetworks. Computer and Information Sciences II Springer-Verlag London Limited, 2012. 24
[25] Robbert van Renesse. Power-aware epidemics. Dept. of Computer Science, Cornell University,Ithaca, 1060-9857102 IEEE, 2002. 24
[26] Giovanni Di Sirio. Chibios/rt, 2013. 31
62 Wireless Sensor Network for Water Quality Measurements
![Page 76: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/76.jpg)
Appendix
# Req Description Real Project Demo Project1 Each node shall be able to acquire measurements of PH and temperature Yes Yes
2Each node shall be able to transfer all the measurements via a wirelessconnection to a SINK node.
Yes Yes
3Each node shall be running on battery power, without maintenance, forat least [...]
9 months 1 day
4Each node shall be able to have a plug-and-play behavior in an ad-hocnetwork.
Yes Yes
5If nodes are active, then the routing protocol shall be capable to route datato the SINK node.
Yes Yes
6 The SINK node will not depend on battery power. Yes Yes7 The PH Sensor shall be usable for 6 months. Yes No
8The network shall be capable to detect and notify if a node is missing in atmost [...]
1 h 45 sec
9The network shall detect pollution hazards and notify the location in at most [...]from the moment it is observed.
30 min 30 sec
10Complete data measurements shall be available at least every [...] with asampling resolution of [...] between samples.
2h; 15 min 30 sec; 15 sec
11 The network shall be capable to cover an area of [...] with a single SINK node. 1 Km2 100 m2
12 The SINK node will directly transfer the data, received from other nodes, to a PC. Yes Yes13 A UI friendly application shall display the acquired measurements received. Yes Yes
14A UI friendly application shall offer the user the possibility to see in real time thesurrounding active nodes in the proximity and their connections.
No Yes
15A UI friendly application shall offer the user the possibility to intervene in real time onthe network to change its behavior.
No Yes
Table 1: User Requirements for the water quality WSN
Wireless Sensor Network for Water Quality Measurements 63
![Page 77: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/77.jpg)
BIBLIOGRAPHY
Ma
jor
/M
inor
Gro
up
#R
eqD
escr
ipti
onR
eal
Pro
ject
Dem
oP
roje
ct
Lin
ked
toU
ser
Req
uir
emen
ts
1A
nod
ep
latf
orm
shall
be
form
edw
ith
an
Ard
uin
ob
oard
an
dan
802.1
5.4
com
pat
ible
wir
eles
sm
od
ule
.Y
esY
es1,2
2A
nod
ew
ill
hav
epro
per
con
nec
tors
tob
ein
terf
ace
dw
ith
aP
Hse
nso
ran
da
tem
per
atu
rese
nso
r.Y
esY
es1
P3
An
od
ew
ill
use
its
AD
Cco
ntr
oll
erto
mea
sure
PH
,te
mp
eratu
rean
dit
sow
nb
atte
ryvo
ltag
e.Y
esY
es1
RP
C1
4A
nod
ew
ill
use
the
802.1
5.4
wir
eles
sm
od
ule
tose
nd
its
acq
uir
edd
ata
tow
ard
sa
SIN
Kn
od
eusi
ng
aw
irel
ess
con
nec
tion
.Y
esY
es2
A5
Eac
hn
od
ew
ill
nee
dto
hav
een
ou
gh
mem
ory
space
tofi
t[.
..]
of
sam
pli
ng
dat
a.820
byte
s81
byte
s10
P6
Th
eS
INK
nod
esh
all
be
cap
ab
leto
be
plu
gged
dir
ectl
yto
main
s.Y
esY
es6
RA
7T
her
ew
ill
be
only
on
eS
INK
ina
dep
loym
ent
are
aof
[...
].1
Km
2100
m2
11
A8
Th
eP
HS
enso
rsh
all
hav
ea
mea
sure
men
tst
ab
ilit
yd
evia
tion
of
at
most
1%ov
er6
mon
ths
of
dep
loym
ent.
Yes
No
7
PC
29
Th
eS
NIF
FE
Rd
evic
ew
ill
be
ab
leto
list
enfo
rall
the
tran
smis
sion
sb
etw
een
nod
esin
the
pro
xim
ity.
Yes
Yes
14,
15
Har
dw
are
(H)
PC
210
Th
eS
NIF
FE
Rd
evic
ew
ill
be
ab
leto
tran
smit
diff
eren
tco
mm
an
ds
ton
od
esin
real
tim
e.N
oY
es14,
15
R11
An
od
ew
ill
hav
ea
du
tycy
cle
of
[...
]<
1%
<15%
3R
12T
her
ew
ill
be
aR
ad
ioD
ata
Dis
sem
inati
on
(RD
D)
per
iod
ever
y[.
..]
(τ)
15
min
15
sec
3,
5R
13E
ach
RD
Dp
erio
dw
ill
last
[...
].2,5
sec
2se
c3,
5
14E
ach
nod
ew
ill
hav
eav
ail
ab
le2
xb
att
erie
sw
ith
ara
ted
cap
aci
tyof
2600
mA
hea
ch.
Yes
No
3
15E
ach
nod
ew
ill
hav
eav
ail
ab
le1
x9v
batt
ery
wit
ha
rate
dca
paci
tyof
600
mA
h.
No
Yes
3
Pow
erM
etri
cs(P
)
A16
Th
esa
mp
lin
gp
erio
dsh
all
be
as
short
as
poss
ible
.Y
esY
es3
Tab
le2:
Hig
h-L
evel
Req
uir
emen
tsP
art
1/3
64 Wireless Sensor Network for Water Quality Measurements
![Page 78: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/78.jpg)
BIBLIOGRAPHY
Majo
r/
Min
orG
rou
p#
Req
Des
crip
tion
Rea
lP
roje
ctD
emo
Pro
ject
Lin
ked
toU
ser
Req
uir
emen
ts
17S
amp
lin
gP
His
don
e[.
..]
1x/15
min
1x/15
sec
1,3
18S
amp
lin
gT
emp
eratu
reis
don
e[.
..]
1x/15
min
1x/15
sec
1,3
P19
Sam
pli
ng
Bat
tery
Pow
eris
don
e[.
..]
1x/24h
1x/10
min
3H
20E
ach
sam
ple
mea
sure
men
tw
ill
be
norm
ali
zed
tofi
tin
1byte
of
data
.Y
esY
es10
H21
Acq
uir
edsa
mp
les
may
be
save
dfo
rat
most
[...
]in
an
od
e’s
mem
ory
ifn
ora
dio
com
mu
nic
ati
on
isp
oss
ible
.4
day
s10
min
10
RP
C1
22If
the
PH
sam
ple
mea
sure
men
tis
ou
tof
norm
al
level
saft
er2
con
secu
tive
mea
sure
men
ts,
then
the
PC
ap
pli
cati
on
con
sid
ers
itas
hav
ing
ap
ollu
tion
haz
ard
and
wil
ln
oti
fyth
eu
ser
ab
ou
tth
isfa
ct.
Yes
Yes
9
23A
cqu
ired
sam
ple
ssh
all
be
rece
ived
by
SIN
Kin
at
most
[...
]p
erio
ds.
2·R
DD
2·R
DD
10
Ap
pli
cati
onB
ehav
ior
(A)
R24
An
od
eis
con
sid
ered
mis
sin
gaft
er[.
..]
per
iod
s.3·τ
3·τ
8
PA
25T
he
rou
tin
gp
roto
col
shall
ensu
rea
pro
per
nod
esl
eep
sch
edu
lesu
chth
atal
lth
en
od
esw
ill
bec
om
eact
ive
inth
esa
me
tim
eto
top
rop
erly
dis
sem
inate
data
toth
eS
INK
nod
e.Y
esY
es3,5
26T
he
rou
tin
gp
roto
col
shall
ensu
rere
du
nd
ant
path
form
ati
on
sto
ward
sth
eS
INK
nod
e.Y
esY
es2,5
27T
he
rou
tin
gp
roto
col
shall
be
ab
leto
use
oth
erav
ail
ab
lep
ath
sin
case
shor
ter
lin
ks
tod
esti
nati
on
dis
ap
pea
rov
erti
me.
Yes
Yes
2,5
P28
To
rest
rict
use
less
flood
ing
of
data
inth
en
etw
ork
,th
ero
uti
ng
pro
toco
lw
ill
ensu
rea
dir
ecte
dd
isse
min
ati
on
toS
INK
by
emp
loyin
ggr
ad
ient
and
dev
iati
onfa
ctor
poli
cies
.Y
esY
es2,5
29If
an
od
ew
ants
toen
roll
inth
en
etw
ork
,it
wil
lb
road
cast
an
att
ach
men
tre
qu
est
each
[...
]an
dw
ill
wait
for
the
surr
ou
nd
ing
nod
esto
rep
ly[.
..].
RD
D/2
2·τ
RD
D/2
2·τ
4
30T
he
SIN
Kn
od
ew
ill
con
sid
era
new
nod
ejo
ined
the
net
work
on
ceit
rece
ived
ap
acke
tfr
om
it.
Yes
Yes
2,4
Rou
tin
g(R
)
HA
31N
om
ore
than
1%of
mea
sure
men
tssh
all
be
lost
inon
ed
ay.
Yes
Yes
10
Tab
le3:
Hig
h-L
evel
Req
uir
emen
tsP
art
2/3
Wireless Sensor Network for Water Quality Measurements 65
![Page 79: WSN for Water Quality - TU/e · Wireles sensor network for water quality measurements Popescu, A.D. Award date: 2015 Link to publication Disclaimer This document contains a student](https://reader033.vdocuments.us/reader033/viewer/2022042201/5ea1e609376c6339120ba3e5/html5/thumbnails/79.jpg)
BIBLIOGRAPHY
Ma
jor
/M
inor
Gro
up
#R
eqD
escr
ipti
onR
eal
Pro
ject
Dem
oP
roje
ct
Lin
ked
toU
ser
Req
uir
emen
ts
H32
Th
eap
pli
cati
onsh
all
be
ab
leto
con
nec
tto
the
SIN
Kn
od
ean
dre
ceiv
eth
ed
ata
acqu
ired
by
the
net
work
.Y
esY
es13
33T
he
app
lica
tion
shal
ld
isp
lay
sep
ara
tely
the
mea
sure
men
tsfo
rea
chin
div
idu
aln
od
e.Y
esY
es13
34S
hal
ld
isp
lay
det
ails
of
nod
e’s
loca
lti
me
an
dd
ate
for
the
last
rece
ived
pac
ket.
Yes
Yes
13
35T
he
plo
tsw
ith
the
mea
sure
men
tsfr
om
SIN
Kw
ill
be
of
the
form
valu
e/ti
me.
Yes
Yes
13
Dat
aA
cqu
isit
ion
PC
Ap
p(P
C1)
36T
he
plo
tssh
all
be
able
toau
to-a
dju
stw
ith
the
valu
esre
ceiv
edan
dsh
all
als
ob
eab
leto
be
zoom
edin
/ou
tan
dto
show
on
lyp
art
sof
the
enti
red
ata
plo
t.Y
esY
es13
37T
he
app
lica
tion
shal
ld
isp
lay
the
curr
ent
net
work
top
olo
gy
ina
use
rfr
ien
dly
man
ner
.Y
esY
es14
H38
Sh
all
con
nec
tto
the
SN
IFF
ER
dev
ice
an
dre
ceiv
eall
the
data
sniff
edfr
om
the
envir
onm
ent.
Yes
Yes
14
AR
39S
hal
lm
onit
orth
eap
pea
ran
ce/d
isap
pea
ran
ceof
nod
esin
real
tim
eacc
ord
ing
wit
hre
qu
irem
ents
23an
d29.
No
Yes
14
R40
Sh
all
be
able
tod
isp
lay
the
lin
ks
that
an
od
eb
uil
ded
wit
hth
ecu
rren
tro
uti
ng
pol
icy.
No
Yes
14
41S
hal
lb
eab
leto
mod
ify
on
the
fly
the
foll
owin
gp
ara
met
ers
of
ase
lect
edn
od
e:ti
me,
grad
ient,
nod
eID
.N
oY
es15
R42
Sh
all
be
able
toge
tfr
om
an
od
eth
ecu
rren
tn
eighb
ors
toget
her
wit
hall
the
det
ails
from
the
nei
ghb
or
tab
le.
No
Yes
15
43S
hal
lb
eab
leto
forc
ea
reb
oot
on
ase
lect
edn
od
e.N
oY
es15
R44
Sh
all
be
able
toal
low
/d
eny
nei
ghb
ori
ng
rela
tion
sby
ad
din
g/d
elet
ing
lin
ks
bet
wee
nn
od
es.
No
Yes
15
R45
Sh
all
dis
pla
yin
aco
mp
reh
ensi
ve
gra
ph
ical
man
ner
ifa
nod
eh
asre
boote
d,
join
edth
en
etw
ork,
trie
sto
att
ach
toth
en
etw
ork
or
ifa
com
man
dh
as
bee
np
roce
ssed
.N
oY
es14,
15
Sn
iffin
gA
pp
lica
tion
(PC
2)
P46
Sh
all
dis
pla
yin
aco
mp
reh
ensi
ve
gra
ph
ical
man
ner
wh
ena
nod
etr
an
smit
s.N
oY
es14
Tab
le4:
Hig
h-L
evel
Req
uir
emen
tsP
art
3/3
66 Wireless Sensor Network for Water Quality Measurements