Table of Contents [602929]

Table of Contents
Table of contents
1. Introduction ………………………….. ………………………….. ………………………….. ……………….. 1
1.1. Project context ………………………….. ………………………….. ………………………….. ……… 1
2. Proje ct Objectives and Specification ………………………….. ………………………….. ………….. 3
3. Bibliographic research ………………………….. ………………………….. ………………………….. …. 5
3.1. Dynamic data acquisition systems ………………………….. ………………………….. ……….. 5
3.2. Static data acquisition systems ………………………….. ………………………….. …………….. 6
3.2.1. Sensor networks ………………………….. ………………………….. ………………………….. 8
3.3. Summary ………………………….. ………………………….. ………………………….. ……………. 17
4. Analysis and Theoretical Foundation ………………………….. ………………………….. ……….. 18
4.1. Introduction ………………………….. ………………………….. ………………………….. ………… 18
4.2. Conceptual architecture of the application ………………………….. ……………………….. 18
4.3. Discharge ………………………….. ………………………….. ………………………….. …………… 19
4.3.1. General ways of measuring discharge ………………………….. ………………………. 19
4.4. Slope -Area Method for Discharge Measurement in Open Channels ………………… 21
4.4.1. Selection of site ………………………….. ………………………….. ………………………… 21
4.4.2. Devices for measurement of slope ………………………….. ………………………….. .. 21
4.4.3. Cross -sections of the stream ………………………….. ………………………….. ……….. 22
4.4.4. Computation of the hydraulic radius ………………………….. ………………………… 22
4.4.5. Value of Manning’s Coefficient ………………………….. ………………………….. ….. 23
4.4.6. Uncertainties in flow measurement ………………………….. ………………………….. 23
4.5. Wireless Sensor Network ………………………….. ………………………….. ………………….. 23
4.5.1. Measurement Nodes ………………………….. ………………………….. ………………….. 25
4.5.2. Gateways ………………………….. ………………………….. ………………………….. …….. 25
4.6. LabVIEW Development Environment ………………………….. ………………………….. … 26
4.7. Real-Time Operating Systems ………………………….. ………………………….. …………… 28
4.8. LabVIEW Real -Time Module ………………………….. ………………………….. …………… 29
4.9. LabVIEW Wireless Sensor Network (WSN) Module ………………………….. ……….. 30
4.9.1. Execution Model ………………………….. ………………………….. ……………………….. 30
4.9.2. Communication methods ………………………….. ………………………….. ……………. 32
4.10. Pressure sensors and transducers ………………………….. ………………………….. …….. 33
4.10.1. Accuracy of pressure transducers ………………………….. …………………………. 34
5. Detailed Design and Implementation ………………………….. ………………………….. ……….. 36
5.1. System architecture ………………………….. ………………………….. ………………………….. 36
5.1.1. Water Slope Measurement ………………………….. ………………………….. ………….. 37
5.1.2. Cross -section Computational Model ………………………….. ………………………… 38

Table of Contents
5.2. Components choice ………………………….. ………………………….. ………………………….. 40
5.2.1. Pressure transducer ………………………….. ………………………….. ……………………. 40
5.2.2. Measurement nodes ………………………….. ………………………….. …………………… 41
5.2.3. Gateway ………………………….. ………………………….. ………………………….. ………. 42
5.2.4. From el ectrical current to depth ………………………….. ………………………….. …… 43
5.3. Installation issues ………………………….. ………………………….. ………………………….. … 44
5.4. Software application ………………………….. ………………………….. ………………………… 46
5.4.1. Measurement Node Software ………………………….. ………………………….. ……… 46
5.4.2. Gateway Software ………………………….. ………………………….. ……………………… 48
6. Testing and Validation ………………………….. ………………………….. ………………………….. . 54
7. User’s manual ………………………….. ………………………….. ………………………….. …………… 57
7.1. Deployment and installation ………………………….. ………………………….. ……………… 57
7.2. Using the software application ………………………….. ………………………….. …………… 58
8. Conclusions ………………………….. ………………………….. ………………………….. ……………… 62
8.1. Contributions and achievements ………………………….. ………………………….. ………… 62
8.2. Further Development ………………………….. ………………………….. ……………………….. 62
Bibliography ………………………….. ………………………….. ………………………….. ……………………. 63

Chapter 0
1 1. Introduction
In the last decades, it has become increasingly obvious that monitoring the
groundwater resources of a country is a very important thing to do. The water in rivers is used
in many industries and at the same time it constitu tes an essential life resource for the
population (i.e. drinking water for humans and animals, industrial applications, etc.). As
population and industrial exploitation is increasingly threaten this valuable resource,
collectio n of water quality data is an essential step in the management of groundwater. In case
of contamination, a real -time monitoring system can provide an early warning and can greatly
reduce the impact to the population and overall costs. One of the most impor tant water
parameters is discharge , as it is used in many formulas for determining other variables of
interest. At this moment, many discharge measuring methods strongly rely on the
participation of a human operator. Automating this process is a fundamen tal step forward in
the continuous monitoring of watersheds. This project proposes a low -cost prototype for
measuring river discharge continuously.
1.1. Project context
Romania’s major pollution concerns (like many other European countries) are related
to polluti on sources generated by intensive industrial and agricultural development. Although
quite rare, accidental pollution (oil, heavy metals, and cyanide ) is more severe because of the
large human concentration along the river floodplains and generally affect w ater supply and
ecosystems for long term. The impact of such a spill concerns both upstream and downstream
activities in the river basin and sometimes can pass beyond a nation’s boundaries.
In order to manage the water resources of a country efficiently, real -time data about
geo-bio-chemical processes involved in the water cycle are needed but making a decision in
case pollution is detected requires that all the data related to a certain wate rshed is centralized
to be able to make a decision for protecting downstream ecosystems and water users. Such a
system that contains real -time data about watersheds along with mathematical simulation
models related to water and contaminant flow that helps authorities make an informed
decision when needed is called a Decision Support System [1]. The Decision Support System
needs, at a basic level, information about possible pollution sources and types, maximum
allowed concentration for pollutants, and estima tion of the pollutant mass and travel time in
the river system. Also, knowing mitigation strategies in case of pollution like absorbent
barriers, chemical neutralization, releasing water from upstream reservoirs to increase
pollutant dilution can be helpfu l because a decision system will be able to simulate using
mathematical models each of this variant and provide an answer to the question of what is the
best solution for a given scenario. Because an accidental pollution is inherently unexpected, it
is cru cial for the system to have real -time data that can be passed over to the simulation
models to enable quick decisions and plan strategies for warning users. Therefore, a Decision
Support System having a centralized database, mathematical models for predict ing flows and
connected to the internet comes as an important tool for water supply companies and river
basin water management authorities that help them make adequate intervention measures and
communicate pertinent information to the public.
The high -level components of a Decision Support System are the Data Model,
Ingestion of Real-time Datasets, the Hydraulic Model and Decision Making Parameters and
Warnings . The Data Model consists of a relational database that gathers all the data from
different sourc es. These data are about the river network, industry (location, failure
probability, and pollutants ), urban areas, hydraulic structures (like retention structures that can
be used for concentration control), main stakeholders, measured and processed data, among

Chapter 0
2 others. The Ingestion of Real -time datasets, an essential component as the Decision Support
System needs to have the latest data to be able to make a good decision, is a system that
measures, acquires and stores water parameters describing the pollut ant process in space and
time. This is achieved by a sensor network deployed in the river that can function
autonomously and can transmit data over long distance wireless communication. The
Hydraulic Model refers to having a computation model for the whole watershed of the river
that is being monitored. This will help in estimating flow patterns and simulating pollutant
impact in the river basin. Decision making parameters and warnings are a set of parameters
that the system will use when making a decision and prescribing intervention measures.
In the context of such a Decision Support System, a sensor network that can measure
the discharge in real -time, transmit it over long distances using wireless communication (such
as GSM) and store it into a shared da tabase that the DSS can later access is one of the
foundation pillars because it is one of the most important parameters to know when tr ying to
model contaminants flow.
Currently, rating curves are used to relate stage to discharge which are formulated
from periodic measurements of discharge at known stages. A well -defined rating curve
typically requires many discharge measurements over a wide range of stages which is not
always possible due to remoteness of the gauging stations, rapid events that are hard to
capture, limited resources or even inaccessibility due to flooding. These rating curves also
suffer from uncertainty phenomena called “hysteresis” during flashy events like the rapid rise
and fall of water. This phenomenon is characterized by a differe nce, both on the water rising
stage of the event and on the falling one, between the rating curve prediction of the discharge
and the actual value of the discharge.

Chapter 2
3 2. Project Objectives and Specification
The high -level objective of this project is building a wireless sensor system capable of
measuring discharge effectively and autonomously using a low cost, easy to deploy solution.
The measured values must be logged to a shared database for later retrieval and processing b y
some other systems . In the following paragraphs, I will list the complete requirements of the
project and detail each one stating its context .
Measuring discharge continuously is one of the primary functional requirements of
the system. The chosen method for measuring discharge should take into consideration all the
other req uirements because the method itself influences the overall attributes of the system.
As we will see later, this requirement is closely related to other non-functional require ments
such as accuracy. The fact that the measurement is continuous refers to the ability of taking
samples at regular interv als that are static or changed based on user intervention or some
predefined algorithm that can identify a delicate situation such as a significant increase in
discharge. In such a situation, the system must increase its sampling rate at the detection of
the event to be able to accurately describe the event but keep a lower sampling rate when no
event is detected in order to save battery power. In this context, providing a user interface
for changing system parameters and viewing system status is another requi rement. The
system operator should be provided with an easy way of controlling the system and adapting
it as he sees fit. The user should be able to detect if the system is functioning within required
parameters without having to go to the location where t he sensors are deployed. This can be
achieved through a remote status and configuration panel.
Due to the inherent nature of the sites where the s ystem must be deployed, having
wireless communication units is essential because wires in open environments a re exposed
to weather conditions, stealing and damaging and the site might be isolated from any wired
data access point . Furthermore, two communication protocols are required, one for
communication over short distances to transmit data locally between the different
measurement sites and provide synchronization and basic control and one for communicating
over long distances to transmit the collected data to a database server and providing high level
control parameters and status. Thus, both of the communicat ion protocols must be duplex,
allowing receiving and transmitting of data.
Another important aspect of the system is electric power autonomy . This is again due
to the nature of the site where the system will function. The location where the system must
be deployed has to be chosen based on a number of criteria related to the river channel
characteristics, vegetation growth, tendency of depositing sediment s and flow characteristics.
Having an extra criterion concerning electric power requirements would sign ificantly reduce
the number of feasible sites thus reducing the applicability and robustness and making the
system far less feasible in a real -world situation. Although complete autonomy using
alternative power supplies such as photovoltaic cells is ideal, having a system that is low
power and can operate using batteries for a fair amount of time in the order of months is also
acceptable because regular visits to the deployment site should anyway be conducted for
inspecting changes in the river channel conf iguration.
The overall accuracy of the system with respect to the measured value should also be
taken into consideration. Having a low error in the measurement is important because the
values might be used in other systems so the lower the error is in the value of discharge, the
lower the impact of that error is when considering the overall accuracy of the system that uses
the values. In the case of such a system, an error of maximum 5% is acceptable.

Chapter 2
4 Another functional requirement for the system is the a bility to log the acquired data
to a database . The ability to save the data on a non -volatile medium and in an organized
fashion is important when considering the usage of such a system. Besides the fact that the
values can be used as standalone informatio n, the resulting data base is integrated into a larger
system that needs the associate d metadata such as t he timestamp of the measurement. At
minimum, the measurement system should log the measured discharge value, the timestamp
associated with the measurem ent and some intermediary values used for computing the
discharge. Before being logged to a database the data should be checked for errors . The
types of errors that should be checked are those that are completely wrong due to errors in
instruments or other random errors. For example, getting to a zero or negative value when
measuring and calculating should be detected and that measurement discarded sin ce it is
clearly a value that does not make sense. That can be achieved by setting boundaries in the
algorithm based on a statistical model of the site. Errors in accuracy and digitization cannot be
handled and are considered later for the overall accuracy of the system.
A constraint to be taken into consideration is the price of such a system. Water quality
monitoring systems are not currently implemented in many countries mainly because of the
price of such a system. In order for the water administration agencies to consider
implementing such a system it is important that the cost of buying and deploying it is not a
deal breaker. The deployment time and effort can also be thought as an important aspect
when choosing such a system so building it cheap and easy to deploy and maintain would
increase its chances of being widely accepted and successful.

Chapter 3
5 3. Bibliographic research
In this domain, many published research papers present systems with various
approaches to collecting data from rivers. Some of the works studied rely on static
installations at certain locations of the river to acquire data while others are based on the flow
of the river or mo torized boats to scan long sections of the rivers to get a bigger picture of the
conditions of the river or identify processes that are taking place in it.
3.1. Dynamic data acquisition systems
These systems are characterized by the fact that the equipment that acquired data about
water quality is not placed at a fixed location but rather it moves or it is moved along a section
of the river. The advantage of these systems over the static ones is that the obtained data is not
restricted to a particular area but rather the whole river (or an important part of it) is scanned,
thus providing more insight on the water quality, or they can reveal problems that are
localized to certain areas of the river that would not be probed by the static ones. The
challenge for these types of systems is to add intelligence that provides a certain level of
autonomy or completely automate the process.
One of these systems is the “Floating Sensor Network” project [2], developed at
University of California, Berkeley. The system consists of a fleet of 100 floating smartphone
based robots and was initially deployed on Sacramento River in California. The fleet can be
deployed rapidly to provide real -time and high -precision data about waterways. The
advantage of having a large number of sensors travelling along the water is that they highlight
the processes that are influenced by the water movement like pollutant propagation, salmon
migration, and the way salt water mixes wit h fresh water in deltas . Another advantage over
fixed sensor stations is that the latter do not always generate enough data for modeling and
prediction of other events. Figure 3.1 shows the structural design and the equipment of a
floating sensor. The 30.5 centimeter long capsules are marked with fluorescent strips and host
GPS equipped smartphones running the Android operating system. Custom software was
written to run on the open source platforms of the sensors and the Android operating system.
The softwa re sends the capsule’s geographical coordinates to servers using the cell phone’s
data network which allows tracing a map of the river flow. Also, sending the coordinates
allows for later retrieval of the sensors. Some of the sensors are also equipped with propellers
and artificial intelligence to be able to avoid obstacles or navigate to precise interest points.
The buoyancy control system allows the capsule to dive to depths of maximum 5 meters thus
allowing exploration of different levels of depth. The ZigBee short range wireless radio is
used for communication between the robots. At the moment, besides providing the flow map,
the sensors can also measure salinity in real -time but in the future it is planned to equip the
capsules with more sensors to get concentrations for different substances.

Chapter 3
6
Figure 3.1 – The design of a capsule (left) and the sensors in a capsule (right)
Another system that scans long portions of the river but which uses an approach based
on spectrometry to collect water quality data was deployed on Meurthe River in north -eastern
France [3]. The system hardware is embarked on an inflatable boat and powered by an
inverter supplying 220V AC from a 12V DC battery. The boat is then driven ac ross the river
on a section about 4.5 kilometers long and a GPS system is used to trigger measurements
every 40 to 50 meters. The novelty brought by the system is the measurement technique that
was used. Besides thermocouples that measure air and water tem perature the system uses a
spectrometry based instrument to acquire water quality data. Using this kind of measurement,
the most disruptive factor is ambient light so the hardware must adapt to outdoor conditions.
The solution is based on the LabVIEW softw are platform using National Instruments’
CompactDAQ (data acquisition dedicated hardware) along with a LabVIEW toolkit for
spectrometry. The platform provides a framework were a remote interface connected to the
CompactDAQ was developed for supervising the whole process resulting in a mapping of
various pollution forms detected. Measurements are attributed with location data from a GPS
receiver connected through the RS -232 serial interface and are totally autonomous, thus no
human interaction is needed in o perating the acquisition system. Error handling is
implemented for detecting possible acquisition errors. The same solution can be used in stale
water (lakes, ponds) or in seas.
3.2. Static data acquisition systems
These systems have the particularity that the measurement takes place at one or several
fixed but independent locations on the river where sensors have been deployed and the data
acquisition process is continuous over time. The se syste ms usually include data logging or
real-time publishing of the res ults obtained.
One example of this type of systems was used in the domain of slate gas exploitation
by hydraulic fractioning [4], where a mixture of water, sand and various chemical compounds

Chapter 3
7 is used to fraction high depth slate rocks in order to free nat ural gases. The Susquehanna
River Basin Commission based in Harrisburg, Pennsylvania created a water quality
monitoring network using 50 stations that provide continuous and real -time data to determine
if the hydraulic fractioning has any impact on the wat er and ecosystem. The obtained data are
made public. The amount of liquid that is pumped in the rocks is in the range of 11 to 20
million liters which is made up of 90 percent water, 9 percent sand, and the remaining 1
percent can range from a drilling com pany to another but it is common to contain mineral oils,
pH correctors, guar gum, citric acid, diesel fuel, ethylene glycol, glutaraldehyde . Most of the
compounds are relatively harmless for the environment like the mineral oil, guar gum and
citric acid b ut others like diesel fuel, ethylene glycol and glutaraldehyde can present a
significant environmental concern. Up to 10 percent of the fluid returns to the surface within
30 days of injection as “flowback”. Each measuring station is made up from a multi –
parametric probe YSI 6600 V2 -4 placed in a PVC protective housing that is anchored in the
river bank and connected to a dat a platform as seen in Figure 3.2 .

Figure 3.2 – The PVC housing containing the probe (left) and its powering solar cell (right)
The power supply for the sensors comes from solar panels. Although oil companies
are required to publicly state the formula of the fractioning fluid, monitoring some chemica l
substances is not viable. Instead, they monitor other parameters that may indicate a leak of
saline solution or some underground water that is rich in minerals. These parameters are
temperature, conductance, pH, dissolved oxygen and turbidity. Stations a re placed in three
types of locations: near drilled wells or near the routes of the trucks that transport the fluid, in
areas where it is possible for drilling to be made in the future and in totally isolated areas that
have no connection to the drilling a ctivity. Sampling is made every 5 minutes and acquired
data is transmitted every 2 to 4 hours to a server which makes the data public. The system can
detect a leak of 16000 liters of fluid on a surface of 90 to 130 square kilometers in maximum
5 minutes an d can trigger an alarm.
Although that sensors installed in the rivers prov ide accurate readings about the
constituents of the water, sometimes the lack of context prevents the correct interpretation of
that data. For example, the increase in concentration of a particular chemical can be caused by
a spill somewhere on the course of the river but it can also happen due to a fall in water level.
Without knowing this additional information it is hard to make assumptions. A paper [5 ]
written by O’Connor ET. Al. describes a multi -modal sensor network where visual sensors
such as camera and satellite imagers, along with context information can be used to
complement and enhance the usefulness of a traditional in -site sensor network in measuring

Chapter 3
8 and tracking some fe ature of a river or a coastal location. An AXIS PTZ Network camera was
placed at River Lee, Cork Ireland at one of the five places where another in -situ sensor
network was deployed, controlled remotely from a desktop PC. Software was developed to
interface with the camera every minute, each time changing to one of four angles. The
objective of the research project was to estimate the depth of the water using off -the-shelf
webcam type devices giving an indication of a variety of conditions at the site such a s
temperature, dissolved oxygen and conductivity readings. The detection was based on looking
for features in the images as the water level increases or decreases such as rocks in the water,
level of water against a wall. By observing the sequence in which these features appear one
can estimate the level by searching which of these features are present on a picture. A week’s
worth of gathered data was chosen and manually annotated in order to have a set of ground –
truth images for each of the features. Figur e 3.13 shows a comparison where the searched
features were all present at one time and where none of the features were seen.

Figure 3.3 – Features detected (left) and the absence of the same features when the water level
rises (right)
The Matlab image processing toolbox was used for processing the images and
extracting the relevant features and a Support Vector Machine as the classification method for
the images.
3.2.1. Sensor networks
A particular case of the st atic data acquisition systems that aims at overcoming the
disadvantage s of the data being limited to a certain location of the river and the lack of
context are the systems that although are deployed at fixed locations, they can communicate
with each other or with a central authority so that the entire system produces a more accurate
and relevant model than individual and independent sensors would. Usually, these systems
use wireless communication for message exchange between nodes because it is more robust
and sing wires in open spaces would be cumbersome.
A good example of how a hierarchical sensor network is implemented is the work of
Elizabeth B asha and Daniela Rus from MIT [6 ], [7]. They designed an early warning flood
detection system based on a senso r network intended for developing countries affected by
hurricanes which was deployed on Aguan River in North -East Honduras . The river has a
basin covering 10 ,000 square kilometers and threatens at least 25 communities. The focus in
this kind of projects is prediction rather than detection: predicting an event is more important
and has to be done much earlier for the affected communities to be able to evacuate. Four
main tasks were identified as being important: event prediction, alerting communities, alerting

Chapter 3
9 authorities and evacuating the community. Figure 3.4 shows the proposed structure of the
system.

Figure 3.4 – Sensor network system architecture
The system uses two ways of communicating: For long distance communication
(approximately 25 kilometers) the system uses radio devices communicating on the 144 MHz
frequency band. For relatively short range communic ation (approximately 8 kilometers) the
system uses radio devices communicating in the 900 MHz frequency band. The system has
four different regimes of operation: sensing, computation, government and office interface,
and community interface. The flood dete ction module needs to collect information about state
of the river, soil condition, and meteorological conditions so the parameters that are measured
are river level, rainfall, and air temperature using nodes powered by solar panels. Figure 3.5
shows the a rchitecture of the system showing the three types of nodes and the way they
communicate.

Chapter 3
10
Figure 3.5 – Node and communication types
The sensors contain each an ARM7TDMI -S microcontroller based board whose se rial
ports were extended to 8 using a Xilinx CoolRunner -II CPLD configured as a serial router. A
mini-SD card and a Ferroelectric Random Access Memory (FRAM) are responsible for data
and configuration storage. To optimize energy consumption, most of the no des operate based
on a very simple pattern: wake -up, transmit, do work (such as take measurement from sensor),
sleep. The system was equipped with an on -board charging circuit which allows photovoltaic
charging of the 3.7V lithium -polymer battery as well a s measuring the charging current
(Figure 3.6). The software running on the microcontroller is written in C programming
language, using WinARM libraries.

Figure 3.6 – Structure of a sensing node
To minimize failure points, the number of computational nodes was limited but in the
same time redundancy was achieved by having the nodes that communicate over the 144MHz
band be used as computational nodes. Most of the nodes communicate over the 900MHz b and

Chapter 3
11 using an AC4790 wireless module which automatically handles retries, error detection and
peer-to-peer communication providing a transfer rate of 76.5 kilobytes per second (Figure
3.7). For river level measurement the pressure sensor option was chosen b ecause other options
were nonviable: resistance based sensors are subject to corrosion and ultrasonic sensors are
inaccurate during high winds. The prediction model that was developed for this particular
purpose is based on linear regression and is capable of auto -calibration, performs simple
operations and needs to store only the data necessary for training. The analysis and calibration
of the system was done using data acquired over the period of 7 years for a hydrological
system in the United States (Blu e River, Oklahoma).

Figure 3.7 – Structure of a computational node
When developing these systems one aspect to consider is the electrical power
consumption and the autonomy that can be achieved using batt eries. This is important
because, usually, the locations where the systems are deployed are isolated and therefore lack
the proximity to a power supply that is provided from the national power grid. In this way, the
following project aims at providing a un ified architecture for managing the power
consumption of a wireless sensor network. The Rivernet project [8 ] is a project proposal that
aims at providing a platform that supports for a variety of sensor networks such as digital
underwater cameras, hydrophon es, water quality sensors, thermometers, or geologic
equipment that can be powered using a robust energy source: a combination of solar energy
power, lithium -ion batteries and dedicated hardware for energy monitoring and performance
scaling based on availa ble power. The current prototype uses a low power and
computationally limited equipment to control more capable and higher power equipment. A
low-bandwidth, long -range radio is used to schedule the usage of an 802.11 radio and Linux –
based microcomputer. Th e platform will also provide remote troubleshooting capabilities
because as the network becomes large, the capability of quickly identifying a faulty node
becomes increasingly important. The ability to diagnose and correct troublesome software
over a contr ol channel is also desirable. The plan is to acquire, build and deploy a solar –
powered river network over a four mile stretch of Fort River in Amherst. The test bed will
involve a network of shore -based solar -powered wireless mesh nodes and wireless gatewa ys,
solar -powered multi -radio sensor platforms for opportunistic and robust data tra nsmissions,
interface boards and sensor platforms for data acquisition from monitoring sensors and
support infrastructure. Figure 3.8 shows the design of the energy harvest ing node. The
photovoltaic cell can be seen which is connected to a custom made power board that monitors
and manages the power consumption.

Chapter 3
12
Figure 3.8 – Energy harvesting node
The algorithm [9 ] running on the ARM based Gumstix processor used for managing power
consumption was developed in -house and shows good adaptability and performance
compared to other approaches.
Another thing to consider about a sensor network is the cost of building such a system.
If the price is too high, its market value will decrease, making it hard to be widely used. Some
research has been done in this area and a good example of a cheap system is the one proposed
by Raja Jurdak [10 ]: a network of acoustic underwater se nsors using cheap modules made
from generic hardware and running software modems that can communicate using sound
waves in order to transmit collected data to the main station using multi -hop communication.
Sensors are placed into latex membranes which pro vide separation of the hardware from the
water but in the same time maintaining acoustic coupling with the transmission medium
which is water. The speakers used have a low power output thus increasing the autonomy of
the system and minimizing interferences with the aquatic ecosystems as well. Modulating and
demodulating underwater signals requires dedicated hardware. Underwater acoustic
communication is a mature domain and there are plenty of acoustic modems available on the
market capable of reaching trans fer rates in the range of 100 bits per second to approximately
40 kilobits per second, operational distances up to a few kilometers and capable of running at
depths in the order of hundreds of meters . But the cost of such a modem starts somewhere at a
few thousands of US dollars. That is why implementing acoustic modems in software is
attractive and feasible , because of the reduced cost. Coupling acoustic modems implemented
in software with off -the-shelf microphones and speakers (for transmission and recept ion), the
necessity of buying expensive hardware disappears. The cost of modems implemented in
software is limited only to the development cost. Generic microphones and speakers can be
used that are water resistant connected to surface laptops for sending and receiving acoustic
signals modulated by software. To this day, rates of transfer in the order of tenths of bits per

Chapter 3
13 second were achieved over a distance of up to 10 meters. Figure 3.9 shows a possible
implementation of such a system.

Figure 3.9 – Possible implementation of an acoustic sensor network
Sometimes the sensors available on the market are too expensive for the application
being developed or the water constituent cannot be determined using any i n-situ sensor . A
project [11] which was developed in the lab and applied in the field on the Little Bear River in
north Utah proposes a sensor network for high frequency estimation of water quality
constituent fl uxes us ing surrogates. For many of the water constituents like sediments,
phosphorus, there are no sensors that can make high frequency concentration measurements
in-situ. For these constituents, it is impossible or not feasible collecting frequent s amples for
long periods of time because of cost constraints or logistics. Over time, there have been a
number of variables (e.g. discharge) used as surrogates to estimate other water quality
parameters using some statistical curves. Choosing a surrogate depends on the properties of
the constituent that is going to be estimated. For example, dissolved constituents are easier to
predict using specific conductance (a measure of the capacity of water of conducting electric
current) whereas constituents that are formed by su spended particles are more accurately
predicted using turbidity (an optical measure of light dispersion in water due to colloidal and
suspended matter). In principle, most of the commercial sensors that are on the market use a
surrogate. For example, measu ring dissolved oxygen is achieved by measuring the intensity of
the current that is produced when oxygen is reduced at a cathode because the intensity of the
current is directly proportional with the concentration of dissolved oxygen . Thus, the
surrogate s ensor, in tight connection with a specific mathematical relation that can convert the
value measured by the sensor into an estimation of the discharge or concentration, effectively
becomes a sensor for interest variables when no other in -situ sensor can pe rform that task.
The global architecture of a monitoring system using surrogates is depicted in Figure 3.10.

Chapter 3
14
Figure 3.10 – Architecture of a surrogate based monitoring system
Before they can be used, the obtained sensor data have to be passed through a set of
procedures specific to quality assurance and control to make sure the anomalies and false
values are eliminated. In-situ sensors that function in harsh environments may ma lfunction,
some are prone to fouling, and data loggers and communication systems can alter the data.
Uncorrected errors can affect in a negative way the data for scientific applications, especially
if the researchers are not directly familiarized with meas urement methods and the conditions
that might have produced these anomalies. Quality assurance and control generally include:
 Correction of out of range values
 Correction imposed by the measuring apparatus
 Correction of values that are anomalies
 Correction of any known bias in the acquired data
Figure 3.11 shows a few examples of data that contain errors that can be corrected using
quality assurance and control procedures.

Chapter 3
15
Figure 3.11 – Types of errors that can be corrected using Quality Assurance and Control
procedures: A – out of range values; B – calibration errors; C – anomalies
Out of range values are usually caused by equipment malfunction and except the
equipment has failed permanently, they are not pe rsistent, generally being limited to one or
two values and can be corrected through interpolation using adjacent data. If there is a known
and systematic bias in measurements, it can be corrected by adding an appropriate constant
value to the raw data. Fou ling occurs over time and a gap appears in the data whenever the
sensors are cleaned and recalibrated. This gap must be corrected and this is usually done by
first making assumptions about the nature of the drift (for example that it grows linearly in
time) and then using that assumption to apply a correction. Anomalies are values that are in
the measurement range but are significantly different from the adjacent values. The anomalies
can be artificial (for example, deposits on a turbidity sensor) but they can also be caused by
short legitimate events such as a sudden storm that increases the turbidity for a short amount
of time thus making them much harder to correct. Evaluating anomalies can be subjective and
requires expertise both in functioning of the s ensor and the processes that trigger the response
of the sensor. For identification of artificial anomalies, a comparison between the suspected
data and the data collected from other sensors in the same time period can be made. As with
the out of range val ues, the artificial anomalies can be corrected through interpolation using
adjacent values. After the collected surrogate data were corrected using quality assurance and
control procedures, they must then be converted to discharge and concentration using
surrogate relationships derived from the periodic measurements of discharge and water

Chapter 3
16 quality samples that have been collected. Statistical software can help in developing the
surrogate relations hips using least squares regression method.
Water quality man agement is not important only in rivers but also in sea water. Also,
monitoring for pollution is useless if no action is taken in the shortest possible time. For that,
the monitoring system has to have some capacity of interpreting the collected data, make a
decision about the status of the water quality and, if necessary, alert the appropriate
authorities. In another research project [12], Hatzikos et. Al. propose an expert system that
monitors sea water quality and pollution in Greece through a sensor network called
“Andromeda” which monitors data collected by the so -called Local Monitoring Stations,
processes it and draws conclusions about the current level of water suitability. I f the data are
deemed normal, no need for an alert arises, but when they do not fall within the preset
acceptable ranges for at least one of the possible aquatic uses, an appropriate message is
displayed. Figure 3.12 shows the architecture of the Andromeda network.

Figure 3.12 – Andromeda system architecture
The network consists of Local Monitoring Stations (LMS) that record and transmit aquatic
data to the main station and Main Station (MS) which initiates the communication process
with all the LMSs and stores the data in a database for future processing. A Local Monitoring
Station consists of a buoy that floats on the sea surface, a Programmable Logic Circuit by
Siemens, powerful radio modems, a six meter p illar for support of the antenna, four solar
cells, and high capacity rechargeable batteries. The sensors measure the following
hydrological parameters: water temperature, pH, amount of dissolved oxygen, percentage of
dissolved oxygen, conductance, turbidi ty, sea currents, and salinity. The Main Station is a
workstation that collects measurements from the LMSs and can visualize the results in a
SCADA environment. The Main Station is the “master” in the communication process,
meaning it is the one responsibl e for initiating the communication at predefined time intervals
using a handshake technique. A fuzzy logic algorithm implemented in MATLAB is
responsible for processing the data and determining if, based on the parameters’ values, it is
required to trigger an alarm. The user interface is implemented in LabVIEW which receives

Chapter 3
17 from the MATLAB environment a numerical identifier and a string containing the display
message as a result of running the expert system algor ithm using the supplied inputs.
3.3. Summary
As w e saw in the organization of this chapter, two main approaches to collecting data
from rivers or seas can be taken, each type being characterized by whether the sensors are
stationary or not. In the approach where the sensors either float and are driven by the water
flow or they are carried over the water using boats, the advantage is that the data collected
captures the status of the entire river (or at least, a relatively large part of it). Another
particularity of these types of systems is that they can be rapidly deployed when needed and
provide a fast way of collecting data but this also implies that the human interaction is needed,
either in steering the systems towards interest points, or in collecting the equipment after the
measurement process has e nded.
Using the other approach, where the systems are stationary, human intervention is rarely
needed in the data collection process but the measurements are localized to the deployment
site and it is usually required that many identical system be deployed at different locations in
order to be able to monitor an entire watershed. These systems also can be designed to
analyze the data and make decisions based on the findings such as raise an alarm when a
certain pattern is detected in the data. This type of systems can be used in conjunction with
others to perform a more elaborate function or to provide a service for the latter.
A particular case of the stationary systems are the sensor networks. These are systems that
are composed of several components called nodes deployed at different locations which can
communicate with each other or with a central node in order to centralize the information or
make a collective decision. This type of systems combines the high area coverage of collected
data with the lack of need for human intervention in the measurement process.
An important concern that is manifested when designing sensor networks is the ability to
function on alternative power supplies such as batteries, photovoltaic panels, or a combina tion
of these. Most of the works studied spend a considerable amount of time on finding a solution
to power the sensor networks without relying on the local electrical grid. Moreover, some
works have as their main focus this aspect. The same stands for the price of these systems.
Usually, the sensors networks, besides collecting data from the environment, are equipped
with computational power in order to interpret the data and formulate an opinion on the state
of the environment (which can be used to trigge r an alarm when certain “safe” values are
exceeded) or use the data to make assumptions of the future in the form of predictions and
provide help in warning about events that are going to happen.
All the works studied that implemented a sensor network used a form of wireless
communication protocol and that can be explained by thinking at the environment where these
systems have to operate. It would be unfeasible for the nodes to communicate over wired
media because of the price constraints and because the w ires would be exposed to
environment conditions.

Chapter 4
18 4. Analysis and Theoretical Foundation
4.1. Introduction
In this particular case of application and looking at the project requirements, first of all
a method for measuring discharge has to be chosen and then a wireless sensor network
platform that can support the requirements that are imposed by the method has to be
developed. For this application, Slope -Area Method for discharge measurement in open
channels using Manning’s formula was chosen and will be detailed in this chapter. As a
wireless sensor network, National Instrument’s Wireless Sensor Network (NI -WSN ) was
preferred due to the ease of development and integration using the graphical programming
language LabVIEW. This wireless sensor network provides a very powerful and fully
customizable platform with an easy learning curve and integration with other pr oducts using
the LabVIEW development environment and associated tools. As we will see later when
describing the Slope -Area method, an appropriate technique for measuring water stage is
required for determining the free water slope that will be used when co mputing the discharge
using Manning’s formula. Based on research in what known methods exist for measuring
water stage and what is being used for other applications , there were several te chniques that
could be used for this application. Among them there ar e floating systems, pneumatic pressure
sensors, diaphragm pressure sensors, downwa rd looking ultrasonic devices, and upward
looking ultrasonic devices. The method I found to be the most suited for this application is
using pressure transducers, a particula r type of the diaphragm pressure sensor. In the next
section I will detail used algorithms, protocols, and the logic and functional structure of the
application.
4.2. Conceptual architecture of the application
Figure 4.1 shows the skeleton of the system. Deplo yed in the river there are three
sensors that collectively will measure the slope of the water surface. These sensors
communicate with the gateway wirelessly to transmit the acquired data at regular time
intervals. The gateway is an embedded programmable d evice that aggregates, filters and
processes the data to compute the value of discharge based on the data. The gateway then uses
a GSM modem to transmit the data over -the-air through the internet to a storage server where
the value of discharge along with some metadata are stored in a table for later retrieval.

Chapter 4
19
Figure 4.1 – System conceptual architecture
4.3. Discharge
In hydrology, discharge is the volume rate of water flow, including any suspended
solids, diss olved chemicals and biologic material which are transported through a given cross –
sectional area (it is also called volumetric flow rate) . The SI unit for flow rate is m3s-1 (cubic
meters per second). It is usually represented using the symbol “Q”. The fundamental
definition of discharge is given by the following limit:

i.e., the flow of volume of fluid V through a surface per unit time t. Since thi s is only the time
derivative of volume, which is a scalar quantity, the volumetric flow rate is also a scalar
quantity. A more useful practical definition of discharge is given by the following formula:

In the above formula, v is the flow velocit y of the substance flowing and A is the cross –
sectional vector area. A vector area , A, is defined as a vector whose magnitude is equal to A
and whose direction is perpendicular to the plane, as determined by the right hand rule.
4.3.1. General ways of measuring discharge
Most devices measure discharge indirectly. Discharge measuring devices are
commonly into those that measure velocity and those that measure pressure or level. The level
or velocity is measured and then charts, tables, or equations are used to ob tain the discharge.
Some water measuring devices that use the measurement of level (head) or pressure to
determine discharge are weirs, flumes, orifices, or Venturi meters . Some devices that sample
or sense velocity are: float and stopwatch, current and pr opeller meters, vane deflection
meters. Since these devices generally don’t measure the average velocity for an entire flow
cross section, the relationship between sampled velocities and the mean velocity must be

Chapter 4
20 known, along with the cross sectional area to which the mean velocity applies. In practice,
measuring discharge is done similarly to what is shown in F igure 4.2. The river flow is split
into several sections that make up the channel’s cross section. Then , using a device called
current -meter, the velocity in each of the section s is measured. By doing this, basically the
total flow is split into multiple partial discharges computed by multiplying the measured
velocity to the approximated section area given by the section width and the water level. T he
total discharge is then calculated by summing all the partial discharges.

Figure 4.2 – Measuring discharge using the velocity -area method
Using several of these measurements, a rating curve can be constr ucted and when a certain
confidence level is achieved, the discharge can be deduced from the rating by only knowing
the water level, without having to measure the velocities.
In smaller rivers, simpler methods can be employed. One such method is using a
bucket of known volume and a stopwatch. For this method, a location along the river where
there is a wate rfall must be identified. If no such location exists, one can be created using a
weir. Then, using the stopwatch, the time it takes for the bucket to fil l is measured. The value
of the discharge is given by the ratio between the volume of the bucket and the time it took to
fill. Usually, several measurements are taken and an average is recorded.
Another simple method is using a floating object. First, the cross section of the river is
measured by sampling the depth in several points along the width of the river and adding
together the area of the sections obtained. Area of one section is approximated by a rectangle
of length equal to the depth and width equ al to the sampling interval. Then, the time it takes
for the floating object to travel along a predefined length section of the river is measured
several times, at different distances from the shore line, in order to get a more accurate
representation. The discharge value is thus given by the product between the average velocity
of the floating object (length of the section of the river over the time it took to cross it) and the
area of the cross section computed in the first step. Also, because the top of the stream flows
faster than the bottom, due to the friction with the river bed, the average velocity obtained
must be corrected by multiplying it with a friction factor depending on the type and conditions
of the river bed.

Chapter 4
21 4.4. Slope -Area Method for Discharge Measurement in Open Channels
This method of discharge measurement relies on knowing the topology of the channel
(its cross section, to be more precise) and determining the free surface slope of the water and
then using a formula to compute the discharge using these parameters. The formula is known
as the Manning formula, after the name of the Irish engineer Robert Manning who described
and published the formula in 1891 in a paper called “On the flow of water in open channels
and pipes”. The formula below shows how to compute the discharge using the Slope -Area
method.

Where:
 Q = discharge
 A = area of the channel’s cross section
 Rh = hydraulic radius defined as the area of the cross section divided by the wetted
perimeter
 S = slope of the water surface
 n = Manning’s Coefficient – a roughness factor depending on the characteristics of the
channel
The Slope -Area method is described by the International Organization for Standardization in
ISO 1070:1192. The standard describes several things to consider when using this method for
discharge measurement , detailed in the following .
4.4.1. Selection of site
The site where the measurement takes place is not chosen at random. Several criteria must be
accomplished in order for the site to be suited for such a measurement. First, there should be
no progressive tendency for the river to scour or to deposit sediment and the bed material
should be similar in nature throughout the reach . This is required because an initial cross
section survey of t he site is used in all subsequent computations so the cross section must be
relatively constant. Ideally, the river should be straight, with no large curvatures or meanders
and no abrupt change in the bed slope (as can occur in rocky channels). The cross s ection
should be uniform throughout the reach and free from obstructions. Preferably, vegetation
should be minimal and as uniform as possible throughout the reach (important when choosing
the roughness coefficient). The length of the reach should be chosen such that the difference
between the water levels in upstream and downstream should not be less than ten times the
uncertainty in the difference, if possible. If the uncertainty in both locations is similar, then
the distance should be sufficient for the fall to be not less than twenty times the uncertainty in
measurement at any one location. The flow in the measurement reach should not be affected
by significant disturbances due to the effect of tributaries. Another requirement is that the
flow in the cha nnel should be contained within defined boundaries. Finally, a converging
reach should be preferable to an expanding reach. Rapidly expanding reaches should be
avoided at all.
4.4.2. Devices for measurement of slope
There are several ways of determining the slop e of the water, depending on the
application. When using reference gauges, they shall comprise a well gauge, preferably

Chapter 4
22 incorporating a vertical gauge rather than an inclined one. The markings should be clear and
accurate and shall cover the range to be me asured. Water -level recorders can be used as well.
A crest stage gauge is suitable only when the peak stage attained during a flood has to be
determined. In extreme cases, high water marks such as drift on banks, wash lines, seed lines
on trees and mud lin es are also an option but should be considered as a poor alternative.
In some cases, the slope of the water surface can be replaced by the slope of the terrain
near the river, which can be obtained from a topographic survey of the area. This is not as
good as measuring the water surface slope, giving an error of 7 to 10% in the measured result.
A maximum error of 5% is considered very good result, but it comes with increased costs in
equipment.
4.4.3. Cross -sections of the stream
A minimum of three cross -sections of the selected measuring reach are generally
desirable each marked on the banks with easily identifiable markers. If, for any reason, it is
not possible to measure more than one cross -section, the central one only may be observed.
Rivers generally ha ve composite cross -sections as shown in Figure 4.3 .

Figure 4.3 – Example of composite cross -section
For these types of cross -sections, it may be appropriate to have different values for roughness
coefficien ts and calculate the discharge in each section and then sum the results.
4.4.4. Computation of the hydraulic radius
The hydraulic radius, R h, at a section is the ratio of the area of the flow to the wetted
perimeter. For computing the area of the cross -section and the wetted perimeter, a
discretization as seen in Figure 4.2 can be made and the following formulas , (2) and (3 ) can
be used with resp ect to the notations used in F igure 4.4:

∑
∑√

Where d 0 = d n = 0, d i are the sampled depths of the channel and b i are the distances between
the sample points. Using these formulas, the area of the section of the channel is
approximated as a sum of the areas of the rectangles determined by b i and d i and the perimeter
is computed as the sum of hypotenuses in squared triangles determined also by b i and d i.

Chapter 4
23
Figure 4.4 – Approximating the cross -section area and wetted perimeter
4.4.5. Value of Manning’ s Coefficient
One way of determining the value of Manning’s coefficient of roughness is to
extrapolate from discharge measurements taken using accurate methods provided that there
have been no subsequent changes in the channel characteristics. It should be noted that th e
greater the extrapolation of the data, the less reliable the result will be. In the absence of
measured data, values from different sources can be used based on the characteristics of the
channel, bed material, vegetation growth, etc. In [10], an example of coefficient selection
based on visual evaluation of the site is shown. The amount and type of vegetation was
assessed and the final roughness coefficient was chosen based on reference tables and
previous publications.
4.4.6. Uncertainties in flow measurement
No measurement of a physical quantity can be free from errors which may be
systematic (fixed), arising from a lack of accuracy in the measuring equipment, or random,
caused by a lack of sensitivity in the measuring equipment, etc. Syst ematic errors are
unaffected by repetition of the measurements and can only be reduced by employing more
accurate equipment. Repetition can, however, be used to reduce the uncertainty caused by
random errors, the precision of the average of m repeated meas urements being square root of
m times better than that of the individual points. A further distinction between the two types
of error is that whilst the random component can be fairly easily estimated statistically, the
magnitude of any systematic error ca n only be determined if the results obtained can be
compared with those for some error -free procedure. Looking at the formula used for
determining the discharge, it is clear that the overall uncertainty will include the uncertainty in
the estimation of the area, the uncertainty in the estimation of the slope, the uncertainty in the
estimation of the wetted perimeter and the uncertainty in the estimation of the coefficient of
roughness .
4.5. Wireless Sensor Network
For this project, the Wireless Sensor Network f rom National Instruments was chosen
because of some advantages and features that are suited for the application. The NI WSN
platform provides an easy way to monitor assets or the environment with reliable, battery –
powered measurement nodes that offer indus trial ratings and local analysis and control
capabilities. Also, the platform provides scalability because each wireless network can contain
from tens to hundreds of nodes and can be seamlessly integrated with existing wired
measurement and control systems . The architecture of a wireless sensor network consists of

Chapter 4
24 three main components: nodes, gateways and software. The spatially distributed measurement
nodes interface with different s ensors to acquire data, which are then transmitted wirelessly to
the gate way, which in turn can operate independently or connect to a system where you can
collect, process, analyze, and present the measured data using software. The wireless nodes
can operate as routers to extend the network’s distance and re liability. Figure 4. 5 shows the
possible architectures using the Wireless Sensor Network from National Instruments.

Figure 4.5 – Wireless sensor network architecture
The wireless end nodes are of two types: simple end nodes that can only acquire and send data
from the sensors and programmable end nodes that can also run a programmed algorithm,
respond to communication messages, send custom messages, do some preprocessi ng or
dynamically change the parameters of the node. Each of these types of end nodes can also
function as a router node, basically repeating the packets that are received to achieve a greater
distance or redundancy. The end nodes communicate wirelessly wi th gateways. These can be
either a simple gateway connected and controlled by a host computer, or embedded
programmable gateways running LabVIEW Real -Time applications. For the latter, a
connection to the host is optional. For applications that require the combination of high -speed
I/O (control) with distributed monitoring the C Series gateway is a perfect fit because of the
modular architecture of the CompactRIO to which this gateway plugs into. The wireless
sensor network provides the same quality and acc uracy as traditional wired measurement
systems, but with increased flexibility , lower cost and the ability to create smart systems using
the LabVIEW WSN module for programm ing the nodes and the gateways.

Chapter 4
25 4.5.1. Measurement Nodes
The measurement nodes feature dir ect sensor connectivity, reliable communication
and industrial ratings. The devices are battery powered, offering up to three years lifetime on
four AA batteries. Outdoor enclosures can be bought as accessories to provide long -term
outdoor deployment. With the programmable nodes, the LabVIEW programming
environment together with the LabVIEW WSN Module can be used to add intelligence to the
nodes to perform local analysis and control. Several types of nodes exist with different
capabilities, each suited for different applications:
 Analog Input Measurement Node – offers four ±10V analog input channels with
selectable input ranges and four bidirectional digital channels that can be programmed
for event detection or local control. The node also offers 12V, 20mA power output
that can be used for powering sensors that require it.
 Thermocouple Measurement Node – provides four 24 -bit thermocouple input channels
and four bidirectional digital channels and supports J, K, R, S, T, N, B, and E
thermocouple types.
 Voltage /RTD Combination Node – adds resistance -based measurements such as
resistance temperature detectors or potentiometers to the WSN platform. It offers four
analog input channels that can be individually configured as voltage or resistance
based inputs and fo ur bidirectional digital channels.
 Strain/Bridge Completion Node – brings waveform acquisition capabilities to the
WSN platform. It is ideal for structural health monitoring applications featuring four
analog channels that support quarter -, half -, and full -bridge completion as well as two
digital I/O channels.
 RS-232 Serial Node – features one RS232 port to communicate with serial -based
sensors and instruments and functions as an autonomous serial interface. The node
also features two digital I/O channels.
 RS-485 Serial Node – features one RS485 serial port to communicate with serial –
based sensors, instruments and control boards and i t also has two digital I/O channels
for event detection and control
All measurement nodes deliver -40˚ to 70 ˚C temperature ranges and industrial shock and
vibration ratings and provide up to 300 meters outdoor range with line of sight.
4.5.2. Gateways
The gateway acts as a network coordinator in charge of node authentication and
message buffering, collecting measurement data from no des and connects to the enterprise
network where that data can be collected, analyzed and displayed using NI software. The
network can have multiple gateways, each communicating with designated nodes on a
separate channel. There are three types of gateways :
 Programmable gateway – is a Real -Time controller and a WSN gateway, making it
ideal for embedded wireless data logging. It is equipped with dual Ethernet ports,
making it able to communicate with a variety of other devices in the network directly
from th e deployed real -time application. It features a 533 MHz processor, 2 GB of
onboard storage, and a 2.4 GHz IEEE 802.15.4 radio to communicate with up to 36
distributed measurement nodes in a mesh configuration. It also features an on -board
Web Server for re mote access to data.
 C Series gateway – delivers tight integration with the CompactRIO platform. It plugs
directly into any CompactRIO system slot so you can complement the existing
measurement and control system with wireless I/O.

Chapter 4
26  Ethernet gateway – this is a pass -through device that must be connected to a host
system. It does not possess any programmable capability and it features a 10/100
Mbps Ethernet port for connecting to a Windows or LabVIEW Real -Time controller
and a 2.4 GHz IEEE 802.15.4 radio to c ommunicate with the measurement nodes.
The network protocol used by the Wireless Sensor Network is a proprietary protocol based on
IEEE 802.15.4 and ZigBee technology. The IEEE 802.15.4 standard defines the Physical and
Medium Access Control layers of the networking model while the ZigBee builds on that layer
with the network and application layers to provide features such as device coordination,
reliability through mesh configuration and flexibility within the protocol.
4.6. LabVIEW Development Environment
LabV IEW (short for Laboratory Virtual Instrument Engineering Workbench) is a
system design platform and development environment for a visual programming language
from National Instruments. The programming language is referred to as “G” and is a dataflow
progra mming language, meaning that the program is modeled as a directed graph of the data
flowing between the operations, thus implementing dataflow principles and architecture. This
is in contrast with imperative programming where a program is modeled as a seri es of
operations that are then executed sequentially. LabVIEW is a graphical programming
environment, allowing the engineers to achieve great productivity without having to learn a
programming language. LabVIEW programs are called virtual instruments (VIs) and each
virtual instrument has 3 main components : front panel, block diagram and connector panel.
The front panel is built using controls and indicators and is designed to resemble the front
panel of a conventional instrument. The front panel acts as the user interface of the program,
controls being the inputs (they allow the user to supply information to the program) and the
indicators being the outputs (they display the results during and after the program’s execution
has ended). The block diagram is th e place where all the graphical source code is written.
Controls and indicator from the front panel are represented here as terminals and each
function or structure available from the palette can be dropped on the block diagram thus
achieving the desired f unctionality. Each such function, structure or operation is graphically
represented on the block diagram and is generally referred to as a node. Nodes are connected
to each other using wires to suggest the flow of data between the nodes. Finally, the conne ctor
panel allows setting up the external interface of the virtual instrument when used on the block
diagram of another VI. Figure 4.6 shows the block diagram and front panel of a Virtual
Instrument performing a simple addition operation.

Chapter 4
27
Figure 4.6 – The block diagram (left) and the front panel (right) of a simple VI
This programming environment which allows non -programmers to build programs by
dragging and dropping virtual representations of labora tory equipment with which they are
already familiar, along with the included examples and documentation, make it simple to
create small applications and is a benefit on one side but is also a certain danger to
underestimate the expertise needed to write hi gh-quality G code. For complex algorithms or
large -scale code it is important for the programmer to possess an extensive knowledge of the
syntax and topology of its memory management. Several benefits of using the LabVIEW
platform are presented next.
 Inter facing. This is one of the key benefits of LabVIEW over other development
environments: its extensive support for accessing instrumentation hardware. Drivers
and abstraction layers for many different types of instruments and buses are include or
available for plugging into the platform. The abstraction layers offer standard software
interfaces to communicate with hardware. The provided driver interfaces save
development time. Among others, the types of hardware supported by LabVIEW
include data acquisition devices, bench -top instruments, modular instruments and
FPGAs. Although providing sophisticated driver support for all NI hardware, there are
also over 10,000 drivers for connecting to third -party instruments available in the NI
Instrument Driver Network.
 Code Compilation. In terms of performance, LabVIEW includes a compiler that
produces native code for the CPU platform that is run under. The graphical code is
translated into executable machine code by interpreting the syntax and by compilation.
The syntax is enforced throughout the editing process and the compilation occurs
when requested to run or when the virtual instrument is saved. The compiled
executable is merged with the source code and is run using the LabVIEW run -time
engine which contains some pr ecompiled code to perform common tasks that are
defined by the G language. The run -time engine also makes the code portable across
platforms and helps reduce the compile time and assure a consistent interface to
various operating systems and hardware archi tectures.
 Large libraries. Many libraries with a large number of functions for data acquisition,
signal generation, advanced mathematics, statistics, signal conditioning and analysis
along with numerous graphical interface elements are provided in several package
options. Because signal processing is frequently needed after the data are collected to
transform the signal, remove noise or compensate for different effects, LabVIEW

Chapter 4
28 provides over 850 math and signal processing functions to be able to do all this
without having to write the procedures from scratch, thus significantly reducing the
development time.
 Code reuse. The fully modular character of LabVIEW code allows code reuse without
modification. As long as the inputs, outputs, and their data types are consistent, two
subVIs are interchangeable. The platform allows also creating standalone applications
as executable programs and distributing them an unlimited number of times but this
requires installing the run -time engine as well which is a minor incon venient
considering that the run -time and the libraries can be provided freely with the
executable. The platform independence of G makes the code portable on different
platforms and operating systems and among current available targets there are Phar
Lap o r VxWorks OS based real -time controllers, FPGAs, PocketPCs, PDAs, Wireless
Sensor Nodes and Lego Mindstorms NXT.
 Parallel programming. LabVIEW compiler and run -time automatically make use of
the parallel hardware where available. When multiple nodes are re ady to be executed
at the same time, they are executed on different threads. Also, the user can easily
develop a program that takes advantage of the parallelism by drawing two or more
separate while loops. This is a great benefit in system automation where it is common
to have processes like test sequencing, data recording and hardware interfacing
running in parallel .
 Ecosystem. Due to the longevity and popularity of the platform and the ability of users
to extend functionality, a large ecosystem for 3rd party add -ons has developed through
contributions from the community. This ecosystem is available online and is a
marketplace for both free and paid add -ons.
The basic LabVIEW program’s functionality can be extended through the numerous available
modules and toolkits. The most popular modules are:
 LabVIEW Application Builder – allows creation of stand -alone executables and
installers, shared libraries for distribution and helps protect intellectual property by
hiding the block diagram of created programs.
 LabVIEW MathScript Module – allows embedding of MathWorks and MATLAB
script files into the graphical programming environment of LabVIEW
 LabVIEW FPGA Module – extends the LabVIEW platform on FPGAs without the
user needing to know VHDL programming
 LabVIEW Re al-Time Module – allows designing applications that require real time
analysis and control.
 LabVIEW WSN Module – allows interfacing and programming the Wireless Sensor
Nodes and gateways to add intelligence to the nodes, perform custom acquisition or
exten d battery life by optimizing node behavior.
4.7. Real -Time Operating Systems
A Real -Time Operating System is, besides responsible with managing the hardware
resources of a computer and hosting applications that run on the computer (tasks performed
by a general purpose operating system), specially designed to run applications with very
precise timing and a high degree of reliability. To be considered real -time, an operating
system must have a known maximum time for each of the critical operations that it perform s
(some of which include OS calls and interrupt handling). Operating systems that can
absolutely guarantee a maximum time for these operations are referred to as “hard real -time”
while the systems that can only guarantee a maximum most of the time are refe rred to as “soft
real-time”. The main point is that, if programmed correctly, a Real -Time Operating System

Chapter 4
29 can guarantee that a program will run with very consistent timing. This is achieved by
providing programmers a high degree of control over how tasks are prioritized and typically
also allow checking to make sure that important deadli nes are met. The NI WSN Gateway
runs a real -time operating system.
4.8. LabVIEW Real -Time Module
The NI LabVIEW Real -Time module is an add -on component for the LabVIEW
developm ent system that you can use to create and debug reliable, deterministic applications
that run on stand -alone embedded hardware targets. With the LabVIEW Real -Time module,
one can develop applications for all NI real -time hardware targets including CompactR IO,
Single -Board RIO, PXI, vision systems, Compact FieldPoint, WSN Gateways, and standard
desktop PCs. The module embeds a real -time operating system with a single dedicated kernel
that provides maximum reliability and consistent timing for embedded applic ation s and also
contains several toolkits such as the PID and Fuzzy logic toolkit that provide sophisticated
control algorithms ready to run deterministically on any NI embedded target hardware. The
main concept introduced by the Real -Time module is the ti med loop. A timed loop is like a
while loop that executes the contents of its frame sequentially each iteration of the loop but at
a specified period. When wanting to achieve determinism on a real -time target it is crucial to
separate the tasks that need t o be deterministic from the ones that are not so crucial. This can
be achieved by separating deterministic tasks from non -deterministic ones using different
timed loops each set with a different priority; the higher the priority number, the greater
priorit y that loop has relative to other struc tures in the diagram. Figure 4.7 shows an example
of this practice.

Figure 4.7 – Achieving determinism by separating tasks in different timed loops

Chapter 4
30 The deterministic loop set to the higher priority of 100 performs a data acquisition task in
each of the iteration s of the loop, sharing the acquired data with the non -deterministic loop
using a shared variable. The shared variable is implemented as a FIFO to be able to
deterministically share data in the same VI without affecting the determinism of the entire VI.
The non -deterministic loop with a lower priority of 50 logs the acquired data that it reads
from the shared variable to disk.
4.9. LabVIEW Wireless Sensor Network (WSN) Module
The LabVIEW Wireless Sensor Network module extends the LabVIEW graphical
programming environment to create and deploy embedded applications to programmable NI
WSN measurement nodes. Among the reasons for embedding custom programs into wireless
measurement node s are extending battery life by optimizing node behavior, perform custom
analysis on acquired data or embed decision making or local control. The module includes
basic LabVIEW programming structures such as while loops, for loops and case stru ctures. It
also has support for floating point math analysis which eliminates the need for in -depth
knowledge of integer and fixed -point arithmetic. Along with hyperbolic, exponential and
trigonometric math functions, the module offers string processing ca pabilities for
customization of messages that are going to be transmitted to the gateway. Because the
measurement nodes feature a low power microcontroller that is optimized for long -term
deployment instead of processor speed, certain features available on other targets such as
highlighting the execution in debug mode or the ability to step through code at runtime are
missing. However, the module offers basic debugging support through the ability of sending
and receiving string -based messages. Also, the mod ule is limited to serial execution, so
parallel structured do not execute concurrently.
4.9.1. Execution Model
The WSN measurement nodes use an event -based execution framework that can be
extended using the LabVIEW WSN module to customize a node’s behavior. The framework
is designed to optimize battery life by putting the node to sleep until events need to be
handled (excepting the nodes that are configured as routers that can never sleep). The diagram
in Figur e 4.8 shows the relationship between execution states and the events that trigger their
execution. Events that occur during execution of another state are handled immediately
following the completion of the current state. In each of the states shown on the diagram and
described below, the user can insert cus tom behavior using graphical programming or even
ANSI C code.

Chapter 4
31
Figure 4.8 – LabVIEW WSN execution model
Here is a description of each of the states:
 Start – This state is called once by the framework when the node powers up and before
the node establishes a connection to the gateway and joins the network. In this state,
the sending of data, debug or user messages will fail because the node is not yet
connected to the network. Common operations in this state include the following:
setting the sample interval, configuring I/O (thermocouple types, voltage ranges, etc.),
initializing programming structures.
 Sample – This is generally the primary execution state and is called when the sample
interval timer expire s. The sample interval can be configured in the start state
programmatically or from the node’s property page in the LabVIEW project. In this
state, common operations include: reading and writing I/O, sending data using radio
channels, performing threshold , deadband, or averaging logic to conserve power by
transmitting less often, changing the node’s sample rate if battery voltage reaches
critical levels, interfacing with sensor by converting raw data into engineering units.
 DIO Notification – This state is called when a value change event occurs on a digital
line that is configured with the “Generate Notifications” property. You can generate
events on rising or falling edges. When a digital value change event occurs, the DIO
Notification state is queued to run. Subsequent value change events that occur before
the case begins to run are ignored. In this state, the following operations are common:
event counting, waking up to handle and respond to an event.

Chapter 4
32  Network Status Change – This state is called when the node establishes or losses the
connection with the gateway. In this state common operations include the following:
notifying the host that a connection is established (upon connection), changing the
behavior of a node until a connection is re -established.
 Receive – This state is called when a user message is received. User messages are sent
from the host and stored in the gateway. The gateway delivers a message to the node
during the next radio activity that occurs with the node. This includes data
transmi ssion, or a heartbeat (using a heartbeat timer, the node powers up the radio and
sends regular heartbeat messages to the gateway to maintain the network connection;
the timer is reset when any radio transmission occurs). Sensing user messages to the
node i s not guaranteed to be lossless. In this state common operations include:
receiving and parsing commands, updating parameter values, transmitting requested
information.
4.9.2. Communication methods
LabVIEW WSN provides a simple API for exchanging data between th e host and the
node. This includes support for sending I/O values, string -based messages, and node
information such as battery voltage. On the WSN node, the Radio Messages item is used to
send and receive all data. Reading and writing to the Radio Messages item causes the radio to
wake up and transmit or receive the data, after the execution of the current state completed.
Each channel on the Radio Messages terminal can only be written to once during the
execution of a state because the data are not sent un til the state exits. If the Radio Messages
item is not used, the radio is not powered on except to p erform the heartbeat. Figure 4.9
shows an example of transmission and reception of data in the WSN measurement node.

Figure 4.9 – Sending and receiving radio messages on the measurement node

On the host, I/O variables are used to send and receive all data except for user and debug
messages, which are communicated with a set of WSN Host VIs from a W indows PC. In most
cases, the gateway is able to transfer user and debug messages between the gateway and
nodes; however, delivery of user and debug messages to and from the node is not guaranteed.
When a message is sent from the host to a node, it is stor ed in a FIFO memory buffer on the
gateway which has room for 40 messages. The gateway then attempts to deliver each message
to the appropriate node. If the FIFO is full when the host attempts to send a user message, an
error is returned through the WSN Hos t VI. The FIFO is emptied one element at a time as
each element is sent to the node. When a user or debug message is sent from the node to the

Chapter 4
33 host, it is stored in a circular buffer on the gateway. This circular buffer is shared among all
nodes and has ro om for 40 messages. These messages are stored in the gateway until
overwritten or until the gateway is rebooted.
4.10. Pressure sensors and transducers
A pressure transducer is a pressure sensor that generates a signal as a function of the
pressure imposed. Thi s signal is usually an electric signal. The pressure transducers are
typically designed to measure pressure of gases or liquids. Pressure is an expression of the
force required to stop a fluid from expanding and is usually stated in terms of force per unit
area. Pressure sensors can be classified in terms of pressure ranges they measure, temperature
ranges of operation, and most importantly the type of pressure they measure. Using this latter
criteria there are several categories of pressure sensors:
 Absolu te pressure sensors – measure the pressure relative to perfect vacuum.
 Gauge pressure sensors – measure the pressure relative to the atmospheric pressure.
An example is the tire pressure gauge; when it indicates zero, then the pressure it is
measuring is e qual to the ambient pressure.
 Differential pressure sensors – measure the difference between two pressures, one
connected to each side of the sensor. Technically speaking, most of the available
pressure sensors are differential pressure sensors; for exampl e a gauge sensor is a
differential pressure sensor in which one side is exposed to the atmospheric pressure.
 Sealed pressure sensors – similar to the gauge pressure sensor, but they measure
pressure relative to some fixed pressure instead of the atmospheri c pressure (which
may vary depending on the weather conditions or altitude)
Another important classification is based on the pressure -sensing technology:
 Piezoresistive strain gauge – uses the piezoresistive effect of bonded or formed strain
gauges to dete ct strain due to applied pressure. Common technology types are Silicon,
Polysilicon Thin Film, Bonded Metal Foil, Thick Film, and Sputtered Thin Film.
Generally, these technologies are suited to measure absolute, gauge and differential
pressures.
 Capacitiv e – uses a diaphragm and pressure cavity to create a variable capacitor to
detect strain due to applied pressure. Common technologies use metal, ceramic and
silicon diaphragms and are best suited for low pressures.
 Electromagnetic – measures the displaceme nt of the diaphragm by means of changes
in inductance, LVDT, Hall Effect or by eddy current principle.
 Piezoelectric – uses the piezoelectric effect of certain materials such as quartz to
measure the strain upon the sensing mechanism due to pressure. This technology is
best suited for measurement of highly dynamic pressures.
 Optical – techniques include the use of the physical change of an optic fiber to detect
strain due to applied pressure. This technology is best suited for applications where the
measure ment may be highly remote, under high temperature, or may benefit from
technologies inherently immune to electromagnetic interference.
 Potentiometric – uses the motion of a wiper along a resistive mechanism to detect
strain caused by applied pressure.
A pr essure transducer has, beside the pressure sensing equipment an integrated circuit that
measures the observed effect of the pressure and converts it to an electrical signal (voltage or
current) linearly proportional to the pressure. The usual output of pre ssure transducers is an
electrical signal, either in current or in voltage. One of the common output signals is the
4…20mA current loop output signal. The 4 …20mA current loop output signal is a type of

Chapter 4
34 electrical signal that is used in series circuit to provide robust measurement signal. The
pressure sensor acts as like a current source providing a constant current output signal for a
given applied pressure independent of supply voltage or circuit impeda nce. Unlike voltage
outputs, the current output is the same at any particular point in the circuit and is a relatively
high power analogue output which can be used in measurement circuits over long distances. A
typical output current is 4 to 20 mA in a two wire configuration, but there are three wire
configurations which can provide 0 to 20 mA or 4 to 20 mA current loop output signals with a
separate positive supply and output connection. The current can be converted to voltage
output for measurement purpos es at any point in the circuit by adding a load resistor in series.
The voltage drop across the resistor will then vary proportionally with pressure and current.
For example, a 250 ohm resistor will produce a 1 to 5 volt output signal with 4 to 20 mA
curre nt loop signal. This type of output is used extensively throughout the process control
industry and is also being used in manufacturing, aerospace, and automotive applications
because of the convenience of the two wire connectors, robustness to radio frequ ency
interference and the reduction in size of pressure transmitters in recent years.
4.10.1. Accuracy of pressure transducers
The term accuracy has many different definitions but the commonly accepted one is
that it is the sum of the errors due to linearity, hys teresis, and repeatability at room
temperature. Some manufacturers use the root sum square of these three error sources.
Linearity refers to the maximum deviation of the sensor output from a best -fit straight line
measured with increasing pressure only. A typical linearity error of ±0.2% is illustrated in
Figure 4. 10 (left) .

Figure 4.10 – Example of linearity error (left) and hysteresis error (right)
Hysteresis is the maximum difference in sensor output at a pressure when that pressure is first
approached with pressure increasing and then approached with pressure decreasing during a
full span pressure cycle. An example of hysteresis of 0.02% is shown in Figure 4.10 (right) .
Finally, repeatability is the maxi mum difference in output when the same pressure is applied,
consecutively, under the same conditions and approaching from the same direction.
Repeatability is determined by two pressure cycles. An example of 0.01% repeatabili ty error
is shown in Figure 4.1 1.

Chapter 4
35
Figure 4.11 – Example of repeatability error

Chapter 5
36 5. Detailed Design and Implementation
5.1. System architecture
Based on the conceptual architecture and the theoretical foundation from the previous
chapter, it is almost clear how the components and software will map to the conceptual
architecture and how the different modules will interact. Figure 5.1 shows the design of the
system with its main components and how they interact.

Figure 5.1 – System architecture
The sensor network used is the Wireless Sensor Network from National Instruments detailed
in the previous chapter. Three measurement nodes collect analog data at predetermined time
intervals from pressure transducers that are deployed in the river. The measurement nodes and
pressure transducers are connected using a sealed wire to isolate the elect rical signals that are
produced by the pressure transducer. The measurement node sits above the water, in a
waterproof case, and in the vicinity of the pressure transducer to minimize the length of the
wire connecting the two components. The pressure trans ducer measures the level of water and
by sensing the pressure of the water that is above it and creates a current loop output signal in
the range 4 to 20 mA that is sampled by the measurement node. After converting the analog
signal into a digital one, the measurement node sends this data over the wireless
communication link to the gateway which has a logical connection to all the measurement
nodes that are deployed in its vicinity. These data are processed to identify and eliminate
possible errors and then are used as an input to the algorithm that computes the discharge
using the slope -area method which is implemented on the gateway. After the value of
discharge is computed, it is sent over the network link that is provided by the GSM modem

Chapter 5
37 attached to the gateway. The intended receiver of this value is a database server which will
store the value along with some metadata that the gateway sends.
5.1.1. Water Slope Measurement
One of the variables in the equation for computing discharge using the slope -area
method is the slope of the water surface , S. The slope of a line is defined as the ratio between
the altitude change and the horizontal distance between any two points on the line.

Figure 5.2 – Computing the slope of a line
In Figure 5.2 the slope of line l, can be computed as

. The slope can also be
related to the angle that the line makes with the horizontal , α, through trigonometry from the
definition of the tangent. Using that formula, the slope can be defined as .
Consequently, the slope of the water surface is the slope of the line that approximates the
water surface from a longitudinal section of the river. Figure 5.3 shows how the pressure
sensors that measure water depth are used to determine the slope of water.

Figure 5.3 – Computing the slope of the water surface
Suppose we have the pressure sensors placed in a section of the river at different depths from
the river bed. Each of the sensor will measure the height of water above it (here it is assumed

Chapter 5
38 that the measured depth starts from the tip of the sensor, which is true for most sensors) but
each measurement (h 1, h2, h3) will be relative to the sensor’s own random coordinate system.
A way to bring all these measurements together must be found and this is done by simply
choosing a point P in space to which all othe r measurement will be relative to. This means
that the sensors are now placed relative to the chosen point and their location is known
relative to that point. Now, with the point P as the origin of a new coordinate system, we can
measure the slope consider ing this coordinate system as an absolute coordinate system. As I
said earlier, the slope is the ratio between the altitude change and the horizontal distance
between two points. One might ask now why there are three measurement points since for
determinin g the slope two p oints are enough. To answer this question it is important to
consider the real -world scenario of a river. On a real river, usually, the water surface slope is
not the same between any two points, so in order to increase the accuracy and sa mple a larger
section of the river, three points were chosen and the slope is measured between any two
consecutive points. This means we will have two values for the river slope and to combine
them, the average is chosen. Considering this, and the absolute coordinate system I mentioned
earlier, the difference in altitude we need for determining slope is computed taking into
consideration the altitude difference between the sensors and the point P as well. The
horizontal distance is the distance at which the sensors are placed. So, looking again at Figure
5.3, the first slope is given by
, the second one is
,
and the final slope that is used in Manning’s formula is
.
5.1.2. Cross -section Computational Model
The other parameters in the slope -area discharge formula (except for the roughness
coefficient) are related to the cross section of the river channel. Thus, a way to model the
cross -section of the channel to be able to compute the area and the hydraulic radiu s must be
devised. Moreover, that model has to allow changes in the level of water, thus making it
important to model the whole channel, to the part where we think that the water can never get
to. In the following, I will explain the model that I used, wit h the help of Figure 5.4.

Figure 5.4 – Illustration of the cross -section computational model

Chapter 5
39 Suppose we have the cross -section of a river channel as in Figure 5.4. Depth samples are
taken at regular interva ls and stored as numerical values. Depth is relative to a point that we
consider being zero, and in this case the zero point is the highest level the water can achieve,
or the highest point on the river bank (specific to each site). So the actual model sto red by the
program is an array of real values each representing the depth of the river channel in a
sampling point. Another parameter that must be stored as part of this model is the sampling
interval, which is the distance between the sampled depth points . This can be constant (i.e.
sample at regular intervals for the entire channel width) or it can be variable (i.e. sample more
often when the channel changes or take only one sample for a section of the channel that has
constant depth). The first option ha s the advantage of conserving storage space because only
one value for the sampling interval must be stored since all intervals are equal but you might
have to store the same depth value if the channel has a section where the depth is constant.
Also, the c omputations using this option are easier. Using the latter option, the storage space
needed increases since each depth sample must be accompanied by another value which
represents the distance from the previous sample (or the distance from the first sample ) but for
sections of the channel where the depth is constant, only one sample can be taken. Each
method having its advantages and di sadvantages, the most suited method should be chosen
based on the characteristics of the river cross -section.
Having this model, we can now compute the parameters that are needed in the slope –
area formula for discharge. Th ese are the area of the cross section and its hydraulic radius.
First, let’s consider the area of the cross section. Looking back at Figure 5.4, we can see that
the depth samp les along with the level of the water split the cross -section of the river channel
into sections that can then be approximated by right -angled trapezoids (or in some cases by
rectangles). Consequently, the area of the cross -section is th e sum of all areas of the
trapezoids. The area of a trapezoid is given by
, where a and b are the lengths of
the parallel sides (in this case, two consecutive depth samples) and h is the height of the
trapezoid (in this case, the distance between samples).
Now let’s consider the hydraulic radius. The hydraulic radius is defined as the ratio
between the cross -sectional area and the wetted perimeter,
. We already know how to
compute the area, and the wetted perimeter is defined as the perimeter of the cross -sectional
area that is wet (the surface of the channel bottom and sides that is in direct contact with the
aqueous body). Figure 5.5 shows in red the wetted perimeter of a trapezoid channel.

Figure 5.5 – The wetter perimeter of a trapezoid channel (red)
Looking again at Figure 5.4, we can approximate the perimeter as the sum of the lengths of all
section bottoms. Each sectio n of the final perimeter can be computed by considering it as the

Chapter 5
40 hypotenuse in the right angled triangle that is determined by the difference in depth between
two consecutive depth samples and the distance between samples.
As the magnified portion of Fig ure 5.4 suggests, there is a certain amount of error that
is introduced by using this model for computing the area and the hydraulic radius but it is not
much. Furthermore, this error can be reduced by taking more samples, i.e. decreasing the
sample interv al.
5.2. Components choice
5.2.1. Pressure transducer
The system uses three pressure transducers for determining the slope of the water
surface. Each of the transducer is used to measure the height of water above it. Usually, the
pressure trans ducers are manufactured to function within a specified measurement interval.
This is why it is important to estimate what the maximum height of water will be above the
sensor. The pressure transducer doesn’t have to sit on the river bed but it has to have water
contact at all ti mes to measure the level even when the river is at its lowest. Of course, the
lowest limit cannot be known but it can be approximated. Another important aspect to
consider when choosing the measurement interval is the sensitivity of the sensor. Choosing
the largest interval available for a small river will result in a poor sensitivity because the
sensor ’s entire scale will not be used and small changes might not be detected. After
determining these constraints, the pressure transducer can be chos en with the appropriate
measurement interval.
For this application, the pressure transducer s that were chosen are the Nivopress NPK
series from Nivelco (Figure 5.6) . These types of sensors are designed to measure the level in
clean or contaminated liquids. The actual pressure sensor is located at the bottom of the probe
and it measures the differential pressure between the hydrostatic pressure on one side, and the
atmospheric pre ssure on the other which is led to the sensor through a breathing capillary
equipped with a moisture filter that prevents the moisture reaching and damaging the
electronic components. The range of the sensors can be chosen when orderin g and it can go
up to 200 meters . The transducer produces an output in the range 4 to 20 mA proportional to
the level of water that is above the sensor. The relation between the current output and the
level is linear the lower range of output (4 mA) corresponding to 0 meters a nd the upper range
(20 mA) corresponding to the maximum level allowed by the sensor. These types of sens ors
also provide HART (Highway A ddressable Remote Transducer Protocol) protocol which is
provided on the same output wires that are used by the current loop output. Using this
interface some of the parameters of the sensor can be changed but it is addressed to advanced
users and is out of the scope of this application. The sensor has to be powered using a voltage
that is between 12 and 30 Volts. The tempe rature range in which the sensor can work is
between -10 to 60 ˚C and guarantees a linearity of ±0.25%. The power and output cables,
along with the breathing capillary are all bundled under a shielded cable to protect them and
provide electrical insulation.

Chapter 5
41
Figure 5.6 – The Nivopress NPK -4110 pressure transducer from Nivelco
5.2.2. Measurement nodes
In the previous chapter I was detailing the measurement nodes available from the
National Instruments as part of their Wireless Sensor Network. For this application, the type
of nodes that was chosen is the NI WSN -3202 (Figure 5.7) analog input node which provi des
four analog input channels.

Figure 5.7 – NI WSN -3202 m easurement node
These nodes have up to 3 years battery life , making them suitable for long term
deployment . The analog input channels can be set to one of different measurement ranges:
±0.5, ±2, ±5 and ±10 V. The measurement node also features 4 bidirectional digital channels,
configurable for input, sourcing output or sinking output. The operating temperature is -40 to
70˚C with a humidity ranging from 10 to 90% RH, noncondensing and up to 50 g shock and 5
g vibration are supported. The 2.4 GHz, IEEE 802.15.4 radio module provides up to 300
meters outdoor communication range. The data rate achieved on this communication link is
about 250 kilobits per second. In order to avoid interferences, the operating frequ ency band is
split in several channels that can be changed from the configuration page of the node. The
measurement nodes use an analog to digital converter for transforming the analog voltage
signal into a digital one which has a resolution of 16 bits (or 65536 different values). The
node can be programmed using the LabVIEW graphical programming environment to add
intelligence to the node. The minimum sampling interval that can be set on the node is 1

Chapter 5
42 second. The nodes are powered using 4 AA alkaline batte ries with a voltage range between
3.6 and 7.5V having a power consumption of 0.5 mW when running the default firmware , at
60 second sampling interval and the sensor power is not used. The nodes can also be powered
from an external power supply through a 2 -position “mini-combicon ” power input mating
connection that delivers a vo ltage in the range of 9 to 30V. The nodes also have some
resources for user programming. For configuration storage , the user has available 248
kilobytes of flash memory that can suppo rt 100,000 erase cycles per sector.
When a node powers up, it scans for available networks, locates either a gateway or a
router node, and attempts to join the network. When it joins the network, it downloads the
latest configuration from the gateway and begins its normal operation of acquiring
measurement data, controlling digital I/O, and transmitting back to the gateway for
processing, alarming and visualization.
5.2.3. Gateway
The gateway is the piece of hardware that sits between the measurement nodes and t he
host. It is the equipment to which all measurement nodes connect; they only know to
communicate to a gateway. There are several gateway options available from National
Instruments, each suited for a particular use -case. Som e options might not require th e
connection to the host as being mandatory but rather optional, in case there is a special need
for it. This is the case for the gateway that I chose for this application. The NI -9792 is a
programmable WSN gateway that comes as a small and rugge d LabVIEW Real-Time
controller (Figure 5.8).

Figure 5.8 – NI-9792 WSN Gateway
The gateway manages the wireless network of distributed measurement nodes and can
communicate with other hardware through a variety of ope n communication standards such as
TCP/IP, Modbus and serial. The gateway features a 533 MHz Freescale MPC8347 real -time
processor with 2 Gigabytes of onboard storage for local data logging and 256 MB DDR2
RAM. The 2.4 GHz IEEE 802.15.4 radio allows the gat eway to communicate with up to 36
distributed WSN measurement nodes (in a mesh configuration) achieving a data rate of 250
kilobits per second and splitting the frequency band over 14 channels . The controller also
features dual Ethernet ports to provide fl exible connectivity to other devices in the system
such as enterprise networks or wired I/O systems. In addition, a built -in Web server is
bundled to be able to host measurement data and view it from remote locations with the help
of a browser.

Chapter 5
43 The gatewa y can be programmed using the LabVIEW graphical programming
environment but it requires the LabVIEW Real -Time module as the applications that are
deployed are running under a real -time operating system. The programming environment is
useful for application s that require measurement data collection, alarm triggering through e –
mail or SMS, and even remote viewing of data.
The operating system running on the gateway incorporates a fault -tolerant file system
in order to provide increased reliability for data l ogging. The 2 Gigabytes on -board storage
can be extended th rough the Hi -Speed USB port that the controller provides.
The gateway is powered from external sources through the redundant power supply
connector with a voltage in the range of 9 to 30V DC (mini mum 9V are required at start -up
but after that the device can operate with as little as 6V) drawing a maximum power of 15W
(9.5W typical) . The operating temperature range is from -40 to 70 ˚C and a 50g shock rating is
guaranteed.
5.2.4. From electrical current to depth
The pressure transducer outputs a current value between 4 and 20 mA proportional to
the water depth above it. The measurement node’s analog input channel s can measure onl y
voltage in several ranges, the main one being ±10V. So how does the depth sig nal go from
electrical current, to voltage, to a digital value and then to the actual value of depth in meters?
The answer is that through several conversions.
The first conversion that has to be made is from electrical current to voltage, because
the pre ssure transducer outputs an electrical current and the WSN measurement node can only
sense voltage. So to achieve this, the electrical current that is output by the pressure
transducer is passed through a load resistance. The resistance is added to the cir cuit in a series
configuration and the voltage measured by the measurement node is the voltage drop across
the resistor which will vary proportionally with the current. Figure 5.9 shows the design of the
electrical circuit.

Figure 5.9 – Electrical circuit schema of the measurement installation
The value of resistance R was not chosen at random, but such as the voltage measured
by the measurement node falls into a range of measurement that the node suppor ts. Taking the
maximum current output by the sensor, which is 20 mA, and using Ohm’s law we can
calculate the value of the resistance R for the different ranges of measurement:
 ±0.5V measurement range →

Chapter 5
44  ±2V measurement range →

 ±5V measurement range →

 ±10V measurement range →

When choosing the value of the resistance, it is important to consider the power dissipated
over the resistance. The power dissipated must be kept as low as possible to avoid the heating
of the resistance (which would cause inaccuracies in the value of the resistance) , or any other
unwanted phenomena . The maximum power dissipated over the resistance in each case is:
 ±0.5V measurement range →
 ±2V measurement range →
 ±5V measurement range →
 ±10V measurement range →
From these calculations, it is clear that the most suitable interval for meas urement is the
±0.5V because then the power dissipated is kept at a minimum. From this it follows that the
value for the resistance R is 25 Ω.
The next conversion, which is transforming the signal from analog to digital, is done
by the measurement node it self. The analog measurement nodes feature a 16 -bit analog to
digital converter. This conversion involves quantization (the process of mapping a large set of
input values, i.e. the analog signal, to a smaller set, i.e. the 65536 different values the analog
to digital converter can output) of the input, so it inherently introduces a small amount of
error.
After the signal has been converted to a digital form, it is passed to the gateway which
handles converting the digital value into a meaningful one, which in case of this application is
the depth in meters. To be able to do this, we have to take into consideration the pipeline of
conversions that we have done so far and the initial sensor specifications. Suppose the sensor
has a range of depth of 0 to x meters. That means that sensing a current of 4 mA corresponds
to 0 meters and sensing 20 mA corresponds to x meters, and every value in between has a
linear correspondence. Considering that the current signal is converted into voltage, those
limit values have to be converted into voltage as well. Using the 25 Ω resistance, the limit
voltages become (using Ohm’s law) 0.1V and 0.5V respectively. Now, we have to consider
the analog to digital converter. The 0 to 0.5V range is split across the 65536 values that the
16-bit resolution analog to digital converter can s upport. That means that we have another
linear dependency where the 0 value of voltage corresponds to a zero value in the digital
domain and a 0.5 value of voltage corresponds to a value of 65536 in the digital domain. So
the actual voltage that is read is deduced from this linearity relation. Luckily, the
measurement node already does this transformation for us, returning a real (double) value for
the voltage level measured corresponding to the measurement range. Now, taking this real
value, we have to con vert it into depth. We do that by using the linearity relation given by the
level sensor, where a value of 0.1 (V) corresponds to 0 meters and 0.5 (V) corresponds to x
meters. After this step, the value can be used in calculating the slope, as described ea rlier in
this chapter.
5.3. Installation issues
Before actual installation of the system, the site where the system will be deployed
must be carefully chosen. Ideally, the chosen reach should be as straight as possible, and have
no tendency of depositing sedim ents. This is because the cross -section should be as constant
as possible. Also, no artificial constructions such as weirs, flumes, or dams should be present

Chapter 5
45 in the reach and neither any natural drops in the channel such as those that occur in rocky
beds. The vegetation growing on the banks should be taken into consideration, because it
influences the value of the roughness coefficient. Choosing a reach with minimal or uniform
vegetation is ideal because only one coefficient is needed for the entire cross s ection. If the
vegetation is not uniform, the several roughness coefficients will be needed, depending on the
level of the water (if it reaches the denser vegetation or not). Once the selection of the site has
completed, cross -sections normal to the direct ion of flow should be chosen and the entire
reach should be marked using clearly visible and identifiable markers placed on both banks.
Before installation, the pressure transducers should be placed in a special designed
casing (Figure 5.10).

Figure 5.10 – Longitudinal section through the installation housing
The installation casing is basically a PVC pipe provided with holes for the water to be
able to pass and rise to equalize the level in the outside of the pipe. This design also creates a
turbulence free environment for increasing the stability of the measu rement without affecting
the true level of the water. The pressure transducer must be placed in the tube such that when
the river is at its lowest level, the tip of the pressure transducer is still in contact with the
water. The measurement node is placed at the top of the pipe to avoid the contact with the
water and pipe should be capped for the same reason. Only the antenna of the measurement
node should be brought outside of the housing in order not to affect the range of the wireless
communication. Figure 5.11 shows the sensor wired to the measurement node and the PVC
housing that will protect the equipment when deployed in water.

Figure 5.11 – Press sensor connected to the node (left) and the PVC h ousing (right)

Chapter 5
46 After the sensors have been placed in the water, and anchored in the river bed, the next
step is to take a topographic survey of the site. As I was explaining at the beginning of this
chapter, measuring the slope requires that all the depth measurements be correlated to a
common coordinate system. By using the theodolite to take the topographic survey, then the
position of the theodolite becomes the origin in this coordinate system, and all measurements
are relative to it. After the topograp hic survey has been made, some computations have to be
made in order to transform the topographic survey data into values that can be used by the
computing algorithm.
5.4. Software application
The software application is completely written in LabVIEW graphical programming
environment and the overall architecture is split into three main components, based on the
location where the code is executing. These three components are the WSN measurement
node, the WSN gateway and the server that gets the data and logs it to a file. In the following,
each of the components will be detailed and the most important parts of code will be
explained.
5.4.1. Measurement Node Software
The measurement node has a custom execution model that was detailed in the previous
chapter of this doc umentation. The states that are executed by the firmware are Start, Sample,
DIO Notification, Network Status Change, and Receive. In the LabVIEW programming
environment this is implemented as a single Virtual Instrument that has a case structure which
has a case for each of the state mentioned above. When a change occurs, such as the sampling
timer interval has elapsed or one of the digital inputs has changed its value, the VI is executed
and the case that is about to execute is selected based on a state va riable that is the input of the
case structure selector. Figure 5.12 shows the “Start” case, which is executed once, at the
start-up of the measurement node.

Figure 5.12 – The “Start” case on the measurement node
In this case, the initial sampling interval is set to the value of 5 minutes. It will be
shown later that the interval can be programmatically changed, in case an event occurs.
The next state is the Sample stat e (Figure 5.13 ). For this case, only the actual code
inside the case structure is shown, since the other part of the code is the same as in the
previous “Start” state.

Chapter 5
47
Figure 5.13 – Content of the “Sample” case on the measurement node
This state is called every time the sampling interval timer expires. In this state, all the analog
and digital inputs are read and published as shared variable in the wireless network. The left
part is called an I/O node and is the LabVIEW representation of physical I/O. In the right part,
there are several so -called shared variables. These are resources that can be bound to a
specific project and their value can be read and written from multiple locations just by using
this ref erence. The LabVIEW platform is responsible for keeping the values synchronized
when there are multiple different accesses to the same variable and when these accesses occur
from different physical locations. By writing the values read from the I/O nodes t o the shared
variables, these values can be later read from the gateway.
The next state is “Rec eive” state shown in Figure 5.14 .

Figure 5.14 – Content of the “Receive” case on the measurement node

Chapter 5
48 This st ate is called whenever the measurement node receives a user message from the
gateway. As it has been mentioned in the previous chapter, there is no possibility to directly
debug code that is running on the measurement nodes. So, for that reason, debug mess ages
can be sent through the radio from the measurement node to the gateway. In this state we can
see that any received message is appended a short string and then sent back to the gateway as
a debug message. This way we can make sure that the message was indeed received by the
node. One other functionality provided by the messaging framework is the ability to
programmatically change the sampling interval by the gateway. If the message received can
be decoded into a value that is different from zero, then t hat value will be set as the sampling
interval. Any other message that is sent by the gateway is used as a battery status request as
we can see in the “False” case of the case struct ure that is shown in Figure 5.15 .

Figure 5.15 – The “False” case of the nested case structure
Here, the battery voltage is read and the value is formatted into a string along with the
“Battery voltage:” string and sent back to the gateway.
Next is the “Network status change” state that is called whenever the node loses or
regains connectivity with the gateway, and might be used to handle connection problems. For
this case, only a debug message is sent announcing that the node has conne cted to the gateway
(Figure 5.16 )

Figure 5.16 – Content of the “Network status change” on the measurement node
The last state is the “DIO Notification” state but since the digital inputs are not used
for this application, nothing happens in this case (i.e., the case is empty).
5.4.2. Gateway Software
Since the gateway is capable of running Real -Time applications and can be deployed
in the field for large periods of time , this is where most of the software algorithm is
implemented. The basic arch itecture of the software that is designed to run on the gateway is
that of a top -level VI that runs indefinitely with the help of a loop which is calling into other
helper subVIs to perform differ ent functionalities. Figure 5.17 shows the high -level overvi ew
of the top -level VI that is running on the gateway (specific functionality is detailed below).

Chapter 5
49
Figure 5.17 – A high -level overview of the top -level VI running on the gateway
LabVIEW is a dataflow progra mming language, meaning that the programmer wires
the components together and when running, the data “flows” between nodes from left to right
in the block diagram. This top -level VI contains a timed loop that is set to execute at one
second intervals. Othe r parameters of the loop are set by the initialization block that is
attached to the left side of the loop (Figure 5.18 ). Before the loop begins executing, the data
related to the river channel (mostly resulted from the topographic survey) is initialized b y the
leftmost subVI and passed as an input to the timed loop. All the data is bundled inside a
cluster data type for convenience and to improve the readability of the code.

Figure 5.18 – Data initializatio n, filtering, and computation of the cross section area and the
hydraulic radius in the top -level VI
Then, the loop starts executing. The first thing that it does is to retrieve the value
measured by the sensor that is placed in the middle from the three sensors, the one that is
placed where the river cross -section was surveyed. Then, it converts the sensor reading to
depth in meters using a helper subVI. The resulted value is added together with the difference
in altitude of the sensor from the chosen ref erence point. The sum is then fed into another
helper subVI that filters the depth samples so that only the ones that are in contact with the
water are left. Then, using the depth samples that have passed the filtering stage, the cross –

Chapter 5
50 sectional area of th e flow is computed. Using the same depth values, but also the value of the
area, the hydraulic radius can now be computed, which is done, again, with the help of a
subVI.
The next part of the top -level VI is concerned with the compu tation of the slope
(Figure 5.19 ).

Figure 5.19 – Computation of the slope in the top -level VI
To compute the slope, another helper VI is used, that takes as input the absolute
height of the water of two consecutive sensors ( with respect to the reference point) along with
the distance between the sensors and computes the slope between the two points. The absolute
height of the water is computed by adding the level of water measured by the sensors
(converted to meters) with the relative altitude difference between the sensor’s position and
the reference point. Having three measurement points, there are two values of the slope that
are obtained, between the first two points and the last two points. These two values are then
avera ged together before being used in the final formula for determining discharge. After
having all the parameters in the slope -area formula, these are multiplied together to obtain the
discharge. But first, the hydraulic radius is raised to the power of 2/3 a nd th e slope is raised to
the power o f 1/2 by using the square root primitive.
In the final section of the top -level VI, the timed loop is set to stop if an error occurs or
if the user presses the stop button on the front panel.
In the next section, the subVIs that are used by the top -level VI are presented. First,
the VI that provides the topographic parameters of the river cross -section. These parameters
are bundled together into a cluster data type for simplicity and to improve readability of the
code. The cluster contains the following data (Figure 5.20 ):
 An array of real values representing the depth samples across the river cross section.
 An array of real values representing the altitude difference between each sensor and
the chosen reference point.
 A real value representing the difference in altitude between the chosen reference point
and the river bank (the point having a value of 0 in the depth sampling process)

Chapter 5
51  The depth sampling interval. It is supposed that the cross section is sampled at regula r
distance intervals.
 Manning’s roughness coefficient.

Figure 5.20 – Initializing the cluster with topographic data
These values are provided as constants that are bundled together into a cluster. The
cluster is a type definition and t his approach was chosen to provide an easy way to change the
parameters. When needed, this VI can be duplicated and the constants can be changed to
make them describe another channel’s cross section or different configurations of the same
channel can also be saved in separate VIs. Then, to change the channel configuration that is
used, it is enough to swap the used VI with another one; the output of the VI being a type
definition, the new values will map to the type and the res t of the algorithm is designed not to
make any assumption of the size of the data so the arrays’ dimensions can be changed.
The next VI is the one that filters the depth samples based on the curr ent level of
water. (Figure 5.21 )

Figure 5.21 – Filtering the depth samples
The VI takes as input the absolute water level from the sensor that is placed at the cross
section, and the topographic data cluster and tries to keep only the depth sample points th at
are u nder the water level by iterating through the depth sample points array and comparing the
values to the water level considering the difference in altitude of the river bank as well. The
topographic data cluster is updated with the new values before being o utput.

Chapter 5
52 The next VI uses the filtered data to compute the effective area of the flow cross –
section (Figure 5.22 ).

Figure 5.22 – Computing the cross -section area
This VI only needs as input the filtered topo graphic data. The sections of the cross –
section are approximated as trapezoids and the area of each one is computed using the
formula
where a and b are the lengths of the parallel sides (in this case, these are
two consecutive depth samples) and h is the height of the trapezoid (in this case, the distance
between the depth samples). The partial areas obtained are added together to obtain the area
of the cross section. This VI also outputs the filtered topographic data unchanged to be used
more conveniently in downstream nodes of the top -level VI.
Next is the VI that computes t he hydraulic radius (Figure 5.23 ).

Figure 5.23 – Computing the hydraulic radius
This VI needs as input the same topographic data that the one that computes the area
but it also needs the value of the area given by the previous VI. The wetted perimeter is first
computed by splitting the whole perimeter into segments that are approximated as
hypotenuses in right -angle d triangles determined by the difference in depth between two
consecutive sample points on one side and the distance between samples on the other side.
Pythagoras’s theorem is used for calculating the hypotenuse. Finally, the hydraulic radius is
computed a s ratio between the area and the wetted perimeter obtained before.
One important helper VI is the one that converts the voltage values read by the
measurement node to depth in meters. The conversion, being linear, is modeled as a linear
function , where x is voltage and f(x) is depth and a and b are the function’s
coefficients and are computed using another helper VI (Figure 5 .24).

Chapter 5
53
Figure 5.24 – Converting voltage to depth (left) and computing the conversion function
coefficients (right)
The actual conver sion VI only implements the function using the a and b parameters
received by the helper VI. The coefficients are computed based on the parti cularities of the
sensor installation. Basically, the information needed for finding the coefficients is related to
the sensor range of measurement (minimum and maximum depth), the output current range
(minimum and maximum values) and the value of the resi stance used for transforming the
current into voltage. This information is modeled as constants in this VI and it provides a
centralized location for adapting the software in case the sensor installation changes.
Finally, the VI that computes the slope be tween two absolute referenced po ints is
presented in Figure 5.25 .

Figure 5.25 – Computing the slope
The VI is pretty straight forward, based on the fact that the slope is the ratio between the
difference in altitude and the horizontal distance. One thing to notice is that the VI is designed
not to care about the order of the depth inputs , because it takes the absolute differe nce
between the two points.

Chapter 6
54 6. Testing and Validation
Testing is the process of validating and verifying that the system meets its
requirements, that it works as expected, and that it satisfies the needs of the stakeholders.
Another view of the testing activity is that with the goal of improving quality. This is
important because low -quality software can cause huge losses in mone y and time for the
people or organizations that use it.
Looking at the requirements of the application, the main requirement that must be
tested is the actual continuous measurement of discharge and the accuracy of the values
obtained. In this case, this i s no easy task since it is hard to determine the level of accuracy of
the data just by looking at the obtained values. For this, a theoretical model has to be used that
models a certain real -life situation and where, using some input values, the output val ues can
be easily obtained and where these outputs are known to be correct, even if they are only
theoretic and would apply to an ideal world. Then, feeding the same inputs to the algorithm
that is tested, the results obtained are compared to the ones from the theoretical model and the
degree of accuracy is then established based on the results of the comparison.
For this application, two theoretical models were used for testing the accuracy of the
system. One of them is a half -pipe (Figure 6.1, left) while the other one is a trapezoid channel
(Figure 6.1, right) . For both models, different depths were tested and different diameters /
channel widths were used.

Figure 6.1 – The two cross -section models used f or testing
Since very different configurations for the slope of the channel were also tested, an
easy way to simulate the values read by the measurement nodes had to be found. For this,
another piece of hardware was used that can be programmed with LabVIE W to generate
analog signals: the NI PCIe -7852R. This is a PCI -Express expansion card that can be plugged
in any free PCI -Express port of a computer that has the LabVIEW platform installed. The
board features, among others, eight independent 16 -bit analog output channels, more than
enough for the purpose of this testing. A simple VI was written for this purpose, shown in
Figure 6.2. The VI provides control for writing directly to the analog outputs of the board.
The data type of the output is a 16 -bit signe d integer and the range that can be output is ±10V.
Thus, the 16 -bit integer that is provided in the control of the VI is scaled so that the range of
the integer is spread over the range of the possible voltages.

Chapter 6
55
Figure 6.2 – Block diagram of the VI used for generating analog outputs
The configurations of the channel were provided by duplicating the
“GetTopographicData.vi” VI and modifying the constants to match the configurations that
were tes ted. Another thing to note is that different sampling intervals were tested, to see the
impact of the sampling interval over the results. The configurations used and the results for
each type of channel are presented below.
First, the results for the half -pipe are presented. The different configurations of the
channel and the results obtained for each one are summarized in Table 6.1.
Pipe radius
(m) Water
Level (m) Slope (%) Depth
Sampling
Interval (m) Theoretical
Discharge
(m3/s) Obtained
Value
(m3/s) %
Difference
5 1 6 0.1 21.1386 21.39 +1.18
3 5 0.2 181.0014 172.99 -4.42
8 4 3 0.1 343.4461 341.83 -0.47
7 1 0.2 573.5397 568.84 -0.81
Table 6.1 – Summary of tested configurations and the results obtained for the half -pipe
channel

Looking at the results , we can see that the obtained values are in the proposed 5%
error margin. As we would expect, having a larger sampling interval leads to poorer results
because this leads to inaccuracies in the approximation of the cross -section area and hydraulic
radius.
Next, the results for the trapezoid channel are presented. The different configurations
of the channel and the obtained results are provided in Table 6.2. Again, the tests with larger
value of the depth sampling rate yielded worse results than the ones with a smaller rate. One
of the tests even broke the 5% error margin but that can be attributed to the inaccuracies
caused by the approximation of the channel cross -section area and the hydraulic radius.

Chapter 6
56 Bottom
Width
(m) Side
Angle ( ˚) Water
Level
(m) Slope
(%) Depth
Sampling
Interval
(m) Theoretical
Discharge
(m3/s) Obtained
Value
(m3/s) %
Difference
3 120 2 1 0.1 25.15 25.78 +2.50
130 5 2 0.2 248.95 265.52 +6.65
10 140 3 1 0.1 191.20 195.53 +2.26
150 4 2 0.2 517.90 540.90 +4.05
Table 6.2 – Summary of tested configurations and the results obtained for the trapezoid
channel

Chapter 7
57 7. User’s manual
7.1. Deployment and installation
After carefully choosing the deployment site, the actual installation of the equipment
in the river follow s. Each of the three probing installations has to be secured to the river bed,
in order to resist a large flow of water. It is important for the sensors not to move because
once they are in place, and the topographic survey is taken, the data is considered not to
change unless a significant event takes place (which implies that a survey must be performed
again). Optionally, a maximum water indicator such as a crest stage gauge can be installed
along with the pressure transducers to have a way o f verifying t he sensor data. The simplest
form of a crest stage gauge is a vertical wire passing through the middle of a cork cap. When
the water rises, the cap floats as with the water and rises to the same level. When the water
level starts to fall, the cork adheres to the wire and maintains the highest level the water has
reached.
After the installation of the measurement node is done, a location for the gateway has
to be found. The location of the gateway has to be somewhere in the range of the
measurement nodes, s o that the wireless connectivity with them can be achieved. If possible,
the gateway should be placed in an enclosed space, such as a stream gauging station which is
often provided with a small enclosed space connected to the power grid. After installing a nd
powering the gateway, the connectivity with the measurement nodes has to be tested. The
LabVIEW platform offers a helper application for managing the network where the status of
the connection with the measurement nodes can be checked (Figure 7.1)

Figure 7.1 – Checking the connection status of the measurement nodes
Each node sends a “Node connected…” message to the gateway when the connection
is established and the debugging messages window shows also the node’s identifier from
where the message was sent.
After the successful physical installation of the nodes, a topographic survey of the site
has to be made. With the help of a theodolite, which serves as a reference point, the relative
location of the installed measurement stations has to be determined. Another tool that can be
used for this purpose is a LIDAR which uses the laser technology and analysis of the reflected
light to produce a 3D model of the environment. A cross section measurement of the river, at
the location where the middle one of the three sensors has been placed, has to be performed.
The depth samples can be taken with the help of a graded vertical bar or slate which is rested
on the bottom of the river and the depth is measured rela tive to the top of the river bank or the
highest point the water is expected to reach. The measuring interval on the width of the cross
section has to be constant and has to be chosen such that it captures the particularities of the

Chapter 7
58 channel and the error i n approximating the cross section is as low as possible . As a general
rule, the smaller the sampling interval, the better the accuracy of the resulting model is. This
will be used by the software application in combination with the level of the water to
determine the cross sectional area and the hydraulic radius.
After the topographic data has been collected, a short computation phase follows, to
transpose that data into the constants that are used in the software running on the gateway.
The required data by the software is the relative altitude and horizontal distances of the
sensors with respect to the river bank (or the point that was considered as having zero depth
when sampling the channel cross section) and between the sensors themselves.
7.2. Using the so ftware application
The software application is started by opening the LabVIEW project where all the
hardware and software is centralized (Figure 7.2)

Figure 7.2 – The LabVIEW project
The project shows the hardware and software components in a logical hierarchy. The
initial step before running the application is setting the cross section topographic model by
first opening the “ GetTopographicData.vi” under the NI -NI9792 gateway module. The front
panel of the VI opens. Then, the block diagram of the VI must be opened by pressing the

Chapter 7
59 “CTRL+E” keyboard combination or by selecting the “Show block diagram” option from the
“Window” menu. The block diagram shows up like in the Figure 7.3.

Figure 7.3 – Editing the topographic data
Here, the user has to edit the constants from the left side of the block diagram to match
the desired cross section model, and set the roughness (Manning’s) coefficient, or to make
sure that the existing data is correct. Alternatively, if the user wants to preserve the current
setting for later use, it can duplicate the VI and modify the values in the new one. In this case,
it would also have to replace in the top -level VI the current VI with the new one.
Before starting the application, the software application has to be deployed on the
measurement nodes. To do this, in the project window, the user has to right click any of the
WSN nodes and choose “Deploy All” from the context menu that app ears (Figure 7.4)

Chapter 7
60
Figure 7.4 – Deploying the software on the measurement node s
A new window will appear, showing the progress of the current operation. For this
operation to complete successfully the nodes and the gateway must be powered and the nodes
connected to the gateway.
LabVIEW provides deployment modules called “Build Specifications”. These are
deployment packages on the gateway target that have certain settings for a particular build
such as the top -level VI to start after deployment, pre – and post -build events, optimizations,
target filenames and directories, etc. The current project already contains a build specification
that has set as start -up the “Gateway.vi” VI. In order to deploy a nd start the application, the
user must right click the build specification called “DischargeMeasurementApplication” and
select “Run as Startup” from the context menu that appears (Figure 7.5).

Chapter 7
61
Figure 7.5 – Setting the start -up application on the gateway
LabVIEW will build, deploy and start running the application on the gateway. The
progress of the operation is shown in a separate window that opens after the user selects the
operation. Moreover, if the gat eway is restarted, the same application will start running upon
the starting and initialization of the target.

Chapter 8
62 8. Conclusions
8.1. Contributions and achievements
A new system based on a wireless sensor network that can monitor in real -time the
discharg e of a river was developed which uses the slope -area method based on Manning’s
equation . The system can be ea sily deployed and maintained and can functio n for long periods
of time on batteries without the need for a human operator to supervise its operation. Also, the
system can be easily integrated into larger systems that require the value of discharge in their
algorithms. The accuracy of the system is v ery good considering its price but it can only be
achieved by paying attention to the other factors that influence the error such as the
topographic data.
Testing has revealed that an increase in the distance between the depth sample points in
the cross section can cause an increase in the final error because it would be hard and resource
consuming to try and accurately model a real -world cross section. Stil l, by carefully choosing
topographic data parameters, the resulted error in the value of discharge can be kept in the
proposed ±5% range which is considered very good in this domain.
Configuring and maintaining the system can be done remotely, so no need f or going to the
deployment site if the user wants to adjust some of the software parameters. Also, the resulted
data can be accessed from a remote location, and possibly be distributed or made public
through a web site.
8.2. Further Development
Data about the w ater quality in rivers should be public information because it impacts
every citizen of a country and the nations as a whole. Currently, the system exposes the data
only to the user of the system. A possible future improvement of the system would be to
provide a standardized access to the acquired data. A possible way of doing this is by
designing and implementing a government administered website where information about all
water resources of a country is centralized. Another way that would also allow prog rammatic
access to data for applications that need to use it, is by exposing a web service with
documented methods for accessing the data . This could work along with the website which is
intended for the regular user who just occasionally needs to check so me of this information.
Another possible improvement of the system is to equip it with other sensors for water
quality measurements in order to increase the amount and breadth of collected data. This can
be achieved with minimal effort, since the measureme nt nodes have multiple analog and
digital inputs. By having multiple parameters, the system could also adjust its measurement
behavior based on the read values or have multiple preconfigured personalities.

Bibliography
63 Bibliography
[1] M. Muste, D. Bennett, S. Secchi, J. Schnoor, A. Kusiak, N. Arnold, S. Mishra, D.
Ding, U. Rapolu . End-To-End Cyberinfrastructure for Decision -Making Support in
Watershed Manag ement . Journal of Water Resources Planning and Management , Jan.
2012.
[2] A. Tinka, I. Strub, Q. Wu, and A. Bayen. Quadratic Programming based data
assimilation with passive drifting sensors for shallow water flows . International J ournal
of Control, Aug. 2 010.
[3] http://sine.ni.com/cs/app/doc/p/id/cs -14176
[4] Susquehanna River Basin Commission . Remote Water Quality Monitoring
Network . Available online: http://mdw.srbc.net/remotewaterquality/methods.htm
[5] Edel O’Connor, Alan F. Smeaton, Noel E. O’Connor . A multi -modal event
detection system for river and coastal marine monitoring applications . OCEANS, 2011.
[6] E. Basha and D. Rus, “Design of early warning flood detection systems for
developing countries”, Proceedings of the Conference on Information and
Communication Technologies and Development, Bangalore, India, pp. 1 -10, December
2007.
[7] E. Basha, S. Ravela, and D. Rus, “Model -based monitoring for early warning
flood detection”, Proceedings of the 6th ACM Conference on Embedded Networked
Sensor Sys tems (SenSys), Raleigh, NC, pp. 295 -308, November 2008.
[8] http://rivernet.ncsu.edu/index.html
[9] C. Vigorito, D. Ganesan, and A. Barto, “Adaptive control for dutycycling in
energy harvesting -based wireless sensor networks.,” Proceedings of the Fourth Annual
IEEE Communications Society Conference on Sensor, Mesh, and Ad Hoc
Communications and Networks (SECON 2007), San Diego, CA, June 2007.
[10] Raja Jurdak . Software Driven Underwater Acoustic Sensor Networks . Auerbach
Publications, Taylor and Francis, CRC Press, April, 2008.
[11] J.S. Horsburgh, J.A. Spackman, D.K. Stevens, D.G. Tarboton, and N.O. Mesner,
“A sensor network for high frequency estimation of water quality constituent fluxes
using surrogates”, Environmental Modelling and Software, vol. 25 ( 9), pp. 1031 -1044,
2010.
[12] Hatzikos, E. V., Bassiliades, N., Asm anis, L. and Vlahavas, I. , Monitoring water
quality through a telematic sensor network and a fuzzy expert system. Expert Systems,
24: 143 –161. doi: 10.1111/j.1468 -0394.2007.00426.x , 2007.