wsn for water quality - tu/e · wireles sensor network for water quality measurements popescu, a.d....

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

https://research.tue.nl/en/studentthesis/wireles-sensor-network-for-water-quality-measurements(66b495bd-f4e8-4b98-80fb-2624ff955f4f).html

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

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

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

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

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

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

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

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

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

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].


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,


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


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.


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


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.


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


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:


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


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])


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.


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


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


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


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 (τ).


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


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:


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.


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


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)


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].


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


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.



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.



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.



• 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



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.



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.



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



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.



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



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



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



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.



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,



(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.



(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



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



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.



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



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.



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.



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.


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.


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]



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



(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



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.



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



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



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.



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


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.


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.


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


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


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


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


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


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


wsn for water quality - tu/e · wireles sensor network for water quality measurements popescu, a.d....

Documents