CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
WATER LEAK DETECTION
A graduate project submitted in partial fulfillment of the requirements
for the degree of Master of Science in
Electrical Engineering
By
Teddy Ariyatham
December 2014
The project of Teddy Ariyatham is approved:
Dr. Xiaojun Geng
Date
Professor Hamid Gholami
Date
Dr. Ali Amini, Chair
Date
California State University, Northridge
ii
TABLE OF CONTENTS
SIGNATURE PAGE ………………………………………………………………………...…. ii
LIST OF FIGURES ……………………………………………...…………………………...… v
LIST OF TABLES …………………………………………………………………………….. vii
ABSTRACT ………………………………………………………………………………....... viii
CHAPTER 1: Introduction ……....…………………………………………………………….... 1
1.1 Leak Detection……...……………………………….………………………………..1
1.2 API RP-1130………………………...….…………………………...………………. 2
1.3 Leak Characterization………….…………………………………………………… 3
1.4 Detecting a Leak on a Pipe versus Determining a Local Area of a Leak ……………4
1.5 Externally Based Leak Detection Systems ………………………………………..…4
1.6 Internally Based Leak Detection Systems……………………………………………6
1.7 Project Focus – Flow Monitoring and Balancing Methods…..………………………7
CHAPTER 2: Design Methodology .……..…………………………………………………….... 9
2.1 Approach ………………………………………………….…..…………………...…9
2.2 Small-scale Pipeline Run …………….…………………………..……………….....10
2.3 Water Pump …………….…………………………..……………………………… 13
2.4 Flow Meter ………..…………….…………………………..………………........… 14
2.5 Custom Flow Meter Microcontroller ………..……………..……………….........… 14
CHAPTER 3: Implementation Theory ..……………………………………………………….. 26
3.1 Basic Code Flow Chart ......…………...……..……………..………………........… 26
3.2 Master and Slave Flow Chart ......…………...……………..……………….........…27
3.3 Error Calculation Flow Chart ......…………...……………..………………........… 29
CHAPTER 4: Experiment and Results ..…………………………………………………….…. 31
4.1 Normal Flow Results .........…………...……..……………..………………........… 31
iii
4.2 Little Leak Flow Results .....…………...……..……………..………………........… 34
4.3 Big Leak Flow Results …....…………...……..……………..………………........… 37
4.4 Result Comparisons ……....…………...……..……………..………………........… 41
CHAPTER 5: Observation and Conclusion ….…......……………………………….…………. 45
5.1 Observation ……………......…………...……..……………..…………..…….....… 45
5.2 Conclusion ……………......…………...……..……………..…………………....… 45
REFERENCES ………………………………..…......…………………………………………. 47
APPENDIX A: SUPPLY …...…………………………..…....…………………………………. 48
APPENDIX B: SOURCE CODE .…….………………..…....…………………………………. 49
iv
LIST OF FIGURES
Figure 1-1 Ruptured Oil Pipe………….………………………………………………………..… 1
Figure 1-2 Leak Levels ………………………...………………………………………………… 3
Figure 1-3 External Leak Detection System – Thermal Infrared Display ……………………….. 5
Figure 1-4 Overviews of Internally Based Systems …………………….……………………….. 6
Figure 2-1 Prototype PVC Pipeline ….………………………………….……………………. 10
Figure 2-2 Final Design PVC Pipeline ….………………..….………….…………………….... 11
Figure 2-3 Brass Pipe Ends ……………...………………..….………….……………………….12
Figure 2-4 Leak Valve …...……………...………………..….………….……………………….12
Figure 2-5 Hydor Seltz L20 …...……………...…………..….………….……………………….13
Figure 2-6 Flow Meter ………...……………...…………..….………….……………………….14
Figure 2-7 Arduino Duemilanove ………...……………....….………….……………………….16
Figure 2-8 Boarduino …..……...……………...…………..….………….……………………….16
Figure 2-9 Xbee Module Series 1 ………...……………...…………..….………….…...……….17
Figure 2-10 HD44780 16x2 LCD ………...……………...…………..….………….…...……….18
Figure 2-11 9V Battery inside socket ………...……….....…………..….………….…...……….19
Figure 2-12 Prototype Flow Meter Microcontroller Board ………...……….....………..……….20
Figure 2-13 Final PCB Schematic ………………………..………...……….....………..……….22
Figure 2-14 EAGLE Trace and Route ……………………………...……….....………..……….23
Figure 2-15 Water Flow PCB ……..................……………………...………....………..……….24
Figure 3-1 Basic Code Flow Chart …...……...……………………...………....………..……….26
Figure 3-2 Master and Slave Flow Chart …...……...……………...………....………..………... 27
Figure 3-3 Error Calculation Flow Chart …...……...……………...………....………..………... 29
Figure 4-1 Normal Flow Graph ………..…...……...……………...………....………..………... 31
v
Figure 4-2 Real Time Flow Readings ………..…...……....………………....………..……….... 33
Figure 4-3 Little Leak Valve Setting ………..…...……...….……………....………..………..... 34
Figure 4-4 Little Leak Flow Graph …....……..…...……...………………....………..………..... 35
Figure 4-5 Leak Detected Alert …….....……..…...……...………………....………..………..... 36
Figure 4-6 Big Leak Valve Setting …....……..…...……...………………....………..………..... 37
Figure 4-7 Big Leak Flow Graph …....……….…...……...………………....………..………..... 38
Figure 4-8 Water Levels in Bucket Reservoir …....…..….…...……...………..……..………..... 40
Figure 4-9 Comparison Flows of Pipe 1 and Pipe 2 …....…..….…...……...………..……..….... 41
Figure 4-10 Comparison Flow Graphs ……….......…..….…...……...………..……..………..... 42
vi
LIST OF TABLES
Table 2-1 Hydor Seltz L20 Water Pump Specifications ………….…………………………..… 13
Table 2-2 Flow Meter Specifications ……………………………………………………..…….. 14
Table 2-3 Arduino Duemilanove Specifications ……….…………………………..……..…….. 15
Table 4-1 Normal Flow Chart ………….…………………………………………..……..…….. 31
Table 4-2 Little Leak Flow Table …...……………………………………………..……..…….. 35
Table 4-3 Big Leak Flow Table ……..……………………………………………..……..…….. 38
vii
ABSTRACT
Water Leak Detection
By
Teddy Ariyatham
Master of Science in Electrical Engineering
The purpose of this project is to explore the field of water leak detection and to model
and demonstrate one of many different methods that utilize field instrumentation to
determine a leak. Leak detection systems, or LDS, are generally used in pipeline
networks and assist pipeline controllers to detect and localize leaks. To understand leak
detection, an overview of different methods that are used is studied as well as an
explanation between the differences of detecting a leak in a pipe and determining the
local area of a leak. This project seeks to focus on water leak detection systems and to
show the importance of finding a leak in a small scale pipe network. The project also
seeks to utilize wireless communication to talk between devices while performing these
tasks.
More specifically, in this project, two custom devices are built to act as a master and
slave unit between two water flow meters. Each meter monitors the current flow rate of
water passing through the pipe it is located. The master device acts as the “base” which
simulates the origin of the water while the slave acts as any arbitrary pipe that is located
down the pipeline. The device is created utilizing an Arduino Microcontroller and Xbee
wireless device, IEEE 802.15.4. An LCD screen is also used on each device to display
the current flow rate as well as show an alert if a leak is detected. Design details of the
system are addressed.
viii
Chapter 1: Introduction
1.1 Leak Detection
Leak detection is a current field of technology that is used alongside standards and
practices to help monitor and maintain continual operation of transporting oil, gases, and
other fluid products. Pipeline networks that run across long distances are the safest as
well as the most economic mode of transportation. Since many of these products are
required to be used by the population nonstop, pipelines that are used as long distance
transporting tools must have high demands of reliability, safety, and efficiency. Pipelines
can last without leaks if properly maintained and well monitored. Pipelines that are not
properly maintained begin to weaken structurally. As shown in Figure 1-1, with time,
pipes will eventually corrode and a leak will occur along the pipe. It is up to the leak
detection system needed to quickly compute the issue and alert operators. Leaks can also
come from other reasons such as accidents, particularly from excavation equipment, acts
of
terrorism,
geographical
issues
such
as
earthquakes,
or
even
sabotage.
Figure 1-1 Ruptured Oil Pipe from Kalamazoo Oil Spill, NTSB.
1
The principal purpose of a leak detection system is to assist operators in detecting
and localizing the area of a leak. A good system should quickly alarm operators of the
location and display related data in order to aid in decision-making. Speed is essential
because the products that are transported are sometimes volatile and can cause harm if
left unmonitored. For example, gas pipelines can lead to explosions if not quickly dealt
with. Inspections of pipelines are a time consuming tasks so a reliable system should be
able to help decrease inspection as well as providing minimal downtime. Further
information about leak detection may be found in [4].
1.2 API RP-1130
API RP-1130, short for the American Petroleum Institute – Recommended Practice
1130, is a standard for computational pipeline monitoring for liquids. This standard,
although created with petroleum in mind, applies for any liquid transportation. The
practice focuses on the design, implementation, testing and operation of leak detection
systems that use an algorithmic approach. See [6].
As opposed to having a human operator calculate, standby and read data at different
areas of pipelines, “computational pipeline monitoring” seeks to use machines to gather
data efficiently and use algorithms to infer a leak. While a human operator is ultimately
the one that makes decisions, computational pipeline monitoring allows for continuous
safety operations and to minimize as much downtime as possible. Computers assist the
operators to prevent leaks. If a leak has already occurred and cannot be prevented in time,
gathered data should be able to help coordinate and lead operators to which sections of
the pipelines are leaking the most and which sections can be safely turned off to prevent
any greater problems.
2
1.3 Leak Characterization
Leaks have different sizes which can affect how fast an operator can respond to the
situation. Figure 1-2 shows the different types of leaks. While the most ideal situation is
preventing even the tiniest leaks in pipes, sometimes these leaks go unnoticed. Generally,
the smaller the leaker, the longer it might take for operators to notice the problem. With
miles of pipelines traveling across the country, operators and safety inspectors might not
always be able to catch and see smaller leak locations. Computers as well might not catch
them because a smaller leak might not have much fluctuation in the volume being moved
during transportation. Computers algorithms are also programmed to have tolerances in
volume as well which will cause them to neglect small leaks. For the most part, leak
detection systems yield to these situations. The preferred situation for these systems to
operate is the midlevel leaks. Midlevel leaks have fluctuations that are enough to create
deviations from the norm and alarm operators. From that point, it is up to operators to act
quickly enough to prevent further complications. Past midlevel leaks are catastrophic
leaks. Leaks that have gone to this point are critical situations as human lives could
possibly be endangered or ecosystems ruined due to leak runaways. Leak detection
systems by this point will be in full alarm and operators must quickly bring the situation
under control. More information can be found in [5].
Figure 1-2 Leak Levels from API RP-1130.
3
1.4 Detecting a Leak on a Pipe versus Determining a Local Area of a Leak
Despite what the name seems to imply, leak detection systems mainly determine the
local area of a leak, not actually detect the specific point of a leak on a pipe. However,
there are more advanced and expensive leak detection systems which can monitor the
entire pipe and determine the exact location of a leak. These systems are not typically
used in long pipeline runs due to costs and complexity of installations. Leak detection
systems mainly seek to localize the area of a leak. What this means is for every portion of
pipeline runs, there is a leak detection system that is monitoring and gathering data. Each
run passes data between each other and there is a base or master system which is where
the operator resides. Computational monitoring and algorithms can infer a leak is
occurring when it detects any abnormality between the pipeline runs. From that point on,
the operator will be alerted that for that particular pipeline run, there is a possible leak in
that location. The more closer the leak detection systems are to each other, the more safe
the pipeline run is. If the leak detection systems are miles apart, it can take operators a
long time to determine where in those miles of pipes the leak is occurring. It is up to the
company and its regulations to determine how closely monitored and regulated the
material their transporting is.
1.5 Externally Based Leak Detection Systems
Externally based systems are mainly local meaning the material to be monitored is in
close proximity. These types of systems use dedicated sensors to monitor the pipes. The
advantage of these types of systems is that they can locate the exact point a leak is
occurring. They can be sensitive and highly accurate. The disadvantage is that these types
4
of systems are not cost efficient and require complex installation methods. The dedicated
sensors must be aligned and maintained properly to ensure the system is operational.
External based systems are used in high risk areas where the subject being monitored
must be under heavy surveillance. Examples of external based leak detection systems are:
digital oil leak detection, infrared radiometric pipeline testing, acoustic emission
detectors, vapor-sensing tubes, and fiber-optic leak detection.
Figure 1-3 External Leak Detection System – Thermal Infrared Display from
Pipeline Mapping, int-radar.com.
In the example shown in Figure 1-3, a thermal infrared display is pictured. Inside is
actually a gas pipeline. The uniqueness of this image is that gas pipelines display a
different color temperature from its surroundings. If the gas pipelines are properly
maintained, there should be no noticeable temperature difference coming from around the
gas pipeline. If there is a difference, it can be inferred that the area where the thermal
5
shift occurs is a possible leak location. This is very useful for locating the exact spot the
leak is occurring.
1.6 Internally Based Leak Detection Systems
Internally based systems, which will be what this project is based and what is
referred to from this point on, are systems that utilize field instrumentation to monitor
pipelines and use gathered data to infer a leak. These kinds of leak detection systems are
the ones that are used for standard safety requirements because the system cost is
efficient and the complexity of building these systems are moderate with the existing
field instrumentation. Examples of internally based leak detection systems are:
pressure/flow monitoring, acoustic pressure waves, balancing methods, statistical
methods, RTTM (short for Real-Time Transient Model) methods, and bubble emission
method. Figure 1-4 shows how the different methods are related.
Figure 1-4 Overviews of Internally Based Systems.
6
1.7 Project Focus – Flow Monitoring and Balancing Methods
The type of method that will be demonstrated in this project is a mix of flow
monitoring and balancing methods. Flow monitoring is the use of a flow meter to locally
monitor a pressure or flow at a singular point. Readings over time will change which give
standard data to the algorithm and any abnormalities will be used to point out a leak. This
method however is limited and useful only in steady-state conditions. Balancing methods
use the principle of conservation of mass. In a steady state, the reading at one leak-free
pipe will be balanced with a reading at a later pipe. Any imbalance between the two
points may indicate a leak. The balancing methods can use a number of field
instrumentation at the same time to adhere to the principle of conservation of mass to
create redundancies. An example is using flow, volume, and density readings together to
help determine if a leak is present.
The project is combining both because it is mainly a small-scale design simulating a
pipeline run and due to relative cost and field instrumentation availability. The starting
pipe where the liquid enters will be considered the “master or base” pipe and the flow
meter will gather data at that point and communicate wirelessly with the another pipe,
considered the “exit” pipe. The exit pipe will be used to read the fluid data and between
the base and exit point, compute if there is any imbalance between the two. In between
both flow meter pipes is another pipe which is connected to a valve. This pipe acts as a
“leak” by opening the valve to allow fluids to escape. By doing so, there should be an
imbalance created from the reading at the base pipe and a lesser mass of fluids at the exit
pipe. Computational algorithms written in C-language on the Arduino development
environment will infer a leak when the imbalance occurs and display to the user on an
7
LED screen of the situation. This basically acts like an alarm in the real-life situation
where an operator must be alerted of a possible leak.
The rest of the report is organized as follows. Chapter 2 presents design
methodology as well as the different components that will be used in the microcontroller.
There is also insight on how the microcontroller is laid out and designed. Implementation
theory and code flow is discussed in Chapter 3. This will detail how the two
microcontrollers are functioning and what they do when communicating with each other.
Chapter 4 explains the experiment results and analysis. Data collected after running the
devices is shown and presented to clarify what was expected and not expected. Lastly,
Chapter 5 will detail what could have been done differently and how the project was
concluded.
8
Chapter 2: Design Methodology
2.1 Approach
The approach taken in this project was based on trying to make a leak detection
system that was able to be run real-time, meaning no external data calculations, and be
able to have devices that communicate wirelessly. Due to cost and field instrumentation
availability, only flow meters would be used as the tool to measure fluids. Other tools
such as density readers would not work well in this pipeline design while some tools that
were capable of being hooked up to the boards were well out of the price range. Using
only flow meters would mean a lack of “redundancy” but the project itself is not trying to
prove a method but to simulate a type of system. Because of this, the type of system
chosen was an internally based leak detection system that uses a combination of flow
monitoring and balancing methods. These methods in particular would mean that the
project did not focus on finding an exact location of a leak on a pipe but instead figuring
out if a system in a pipeline run could infer a leak. The system itself would be an
algorithm written to gather the data between the two points to help infer the leak.
Wireless communication is used to help further show that the two points are not supposed
to be “together” locally but located at different points. While that is technically not true
because the project is small-scale, trying to properly simulate every little bit helps bring
more immersion.
9
2.2 Small-scale Pipeline Run
The small-scale pipeline run is essentially a set of PVC pipes cut out to make a square
pattern as seen in Figure 2-1. The fluids enter from the right side of the pipes and come
back from the left side. The left and right side both have a flow meter attached directly to
the PVC pipes. The middle pipe, in Figure 2-4, has a valve attached to act as the “leak”.
Over the course of creating the PVC pipeline, it was eventually noticed that the PVC
pipes themselves had leaks at the joints. This is because PVC material is not cut and
joined perfectly. Special PVC glue and PTFE tape, also known as plumber’s tape, was
used to seal the joints from leaking. This created the ideal situation: a PVC pipeline that
would have no leaks except for the designated valve.
Figure 2-1 Prototype PVC Pipeline.
10
Figure 2-2 Final Design PVC Pipeline.
As shown in Figure 2-2, the PVC pipeline went through prototyping and was
eventually placed on a wooden board. The board along with metal hinges is used to
secure the pipeline. This is crucial to ensure the pipes themselves did not vibrate from
other external forces other than the fluid movement. This creates the steady-state to
ensure that no other factors other than the valve leak are present. The finalized design
also uses brass pipe ends, seen in Figure 2-3, because these connect better to the vinyl
tubing and also are a lot sturdier and smoother than plastic pipe ends.
11
Figure 2-3 Brass Pipe Ends.
Figure 2-4 Leak Valve.
12
2.3 Water Pump
The pipes use an aquarium water pump to act as the device moving the water. This is
especially useful because the water pump has a dial which can help set the speed
preferred. This is used in the experiment to help keep tabs on the water flow at different
flow rates. The exact pump used in this experiment is the Hydor Seltz L20 Aquarium
Water Pump. This is shown in Figure 2-5 and Table 2-1.
Model
Hydor Seltz L20
Max Flow Rate
185gph
Power
11W
Tubing
½”
Max Head
50”
Dimensions
3 ½” x 3 ¼” 2”
Table 2-1 Hydor Seltz L20 Water Pump Specifications.
Figure 2-5 Hydor Seltz L20.
13
2.4 Flow Meter
The flow meter, detailed in Table 2-2 and Figure 2-6, is the most important part of
the pipeline. The sensor sits in the line of the pipes and uses a pinwheel sensor to measure
the amount of liquid passing through. It uses the Hall Effect to track fluid movement. The
red wire is 5-24VDC, black is ground, and yellow is Hall Effect pulse output. The sensor
is a cost efficient device but it is not a precision flow meter device. It is however suited
for the tasks required in this experiment. Source and configuration information are shown
in [7].
Working voltage
Max current draw
Working flow rate
Working temperature range
Working humidity range
Maximum water pressure
Output duty cycle
Flow rate pulse characteristics
Pulses per liter
Fitting
Size
5 to 18VDC
15mA @ 5V
1 to 30 Liters/Minute
-25 to 80°C
35%-80% RH
2.0 MPa
50% +-10%
Frequency (Hz) = 7.5 * Flow rate(L/min)
450
½”
2.5” x 1.4” x 1.4”
Table 2-2 Flow Meter Specifications.
Figure 2.6 Flow Meter.
14
2.5 Custom Flow Meter Microcontroller
The device used to measure and compute flow values are actually a combination of
components combined together. The end result is a device that can read the pulses from
the flow meter, compute necessary data, transmit that data across wireless
communication, and also display relevant data to the operator on an LCD screen.
The base microcontroller device used is an Arduino Duemilanove, seen in Figure 27. In this version, the Duemilanove has been crunched down to essential components in a
series known as the Boarduino (Figure 2-8). The microcontroller uses an ATmega328 IC
for its logic processing and features 14 digital input/output pins, 6 analog inputs, 16 MHz
crystal oscillator, power jack, and a reset button. The most important feature of these
microcontrollers from Arduino is their availability and open source hardware and
software. This gives the user a lot of freedom to manipulate their own design and
program many different end uses for the device.
Microcontroller
Operating Voltage
Input Voltage
(recommended)
Input Voltage (limits)
Digital I/O Pins
Analog Input Pins
DC Current per I/O Pin
DC Current for 3.3V Pin
Flash Memory
SRAM
ATmega168
5V
7-12V
6-20V
14 (of which 6 provide PWM output)
6
40 mA
50 mA
16 KB (ATmega168) or 32 KB (ATmega328)
of which 2 KB used by boot loader
1 KB (ATmega168) or 2 KB (ATmega328)
512 bytes (ATmega168) or 1 KB
(ATmega328)
Clock Speed
16 MHz
Table 2-3 Arduino Duemilanove Specifications.
EEPROM
15
Figure 2-7 Arduino Duemilanove.
Figure 2-8 Boarduino.
More information about the Arduino Company may be found in [1] and about the
Duemilanove in [2].
16
The chosen wireless communication device, shown in Figure 2-9, was an Xbee
Module Series 1. The Xbee works on the IEEE 802.15.4 protocol. It is very power
efficient and only requires 1mW of power output to function. The device-to-device range
is up to 300 feet and the receiver sensitivity is -92 dBm. The device only requires a 3V
supply voltage to be powered. This is in line with the microcontroller design because the
microcontroller itself could feed it power. Two of these devices are used in the
experiment, one on each custom flow meter microcontroller board.
Figure 2-9 Xbee Module Series 1.
The Xbee units were programmed to function with the Arduino units. On the first
attempts of communicating and passing on flow meter data between the two boards, it
was found that the two were not in sync with each other. It was noticed that the speed of
the flow meter updating over and over could not be passed on the default 9600 bps baud
rate. However, changing it to 57600 bps solved the issue. It was found that too low of a
baud rate would leave the devices out of sync because data could not be transmitted to
each other fast enough. Configuration details are presented in [3].
17
The display device used was the HD44780 16x2 Green Screen LCD. The HD44780
was sufficient for the project because the user only needs to see the basic flow meter
readings on each board and the potential alert signal for when a leak is inferred. The
HD44780 is a well known and very standardized LCD that is used industry wide. Once
again, the power consumption plays a role because the HD44780 only requires a 5V
power supply which again the microcontroller can provide. The data that is being
transmitted during flow meter calculations is the same as the one that as shown on the
LCD. This gives the user a real-time experience. Schematic and wiring configuration
information is presented in detail in [8]. Figure 2-10 shows an example model of the
LCD.
Figure 2-10 HD44780 16x2 LCD.
18
The devices are all powered by a 9V battery when used in mobile mode. It was
determined to be the best source of power for when the microcontroller is detached from
a computer USB source. Also looked at was a set of multiple AAA or AA batteries but
those were found to be clunky and added more weight. In the end, a 9V battery along
with a battery socket was used. The socket also has an on and off switch which could
conveniently function as the power switch for the microcontroller board. In the end, the
Arduino could be powered from a 9V battery while functioning completely and convert
some of the power source into 5V and 3V. These would then be passed along to the Xbee
device and the HD44780 LCD.
Figure 2-11 9V Battery inside socket.
Figure 2-11 shows the exact 9V battery socket and the on and off switch. The sockets
were lightweight which made it ideal for this project.
19
Figure 2-12 Prototype Flow Meter Microcontroller Board.
The prototype is a combination of all the components added together and placed on a
standard breadboard. The device can be connected to a computer to upload new programs
by using a USB FTDI cable. This cable also functions as a power source for the
Boarduino which then feeds power into the Xbee and LCD. However, because it lacks
trace routings, many additional wires are used to connect the devices together. The
prototype can also be used in a mobile mode by disconnecting the FTDI cable and
connecting the 9V with socket to the power jack located on the Boarduino. Most of the
experiment was done using the prototype because it was easier to design and program
constantly before deciding on a finalized microcontroller design. As shown in
Figure 2-12, the LCD is well lit and displays data to the user. When running in the actual
experiment, the top line displays the flow rate being read as the water is passing through
the pipe.
20
The finalized design was a more in depth task because it also involved laying out a
schematic, seen in Figure 2-13, converting the schematic into a trace routed board
design, Figure 2-14, and then creating a gerber out of the data. The gerber would then be
sent to a PCB fabrication supplier which would send back the actual PCB design.
To start, the schematic was laid out in a user friendly and well documented software
called CadSoft EAGLE PCB Design Software. This software was partially chosen
because of it free cost and because it provided a free license that would allow the user to
design a small square-shaped PCB that could contain two layers. In this project, a two
layer design was all that was needed to make the board function. EAGLE was used to lay
and connect the Boarduino, Xbee, and HD44780 LCD together. It should be noted that
the Boarduino, being part of the Arduino open source library, had a schematic readily
available so there was no need to recreate a microcontroller, only manipulate the current
design to fit the specifications. These specifications included making the power drawn
from the Arduino feed into the Xbee and the LCD. Also required was laying out open
drill holes for component placement and properly routing traces to make the devices
communicated with each other properly. After the schematic is laid out, EAGLE then
processes that information into the gerber and trace routing mode. During this mode, the
user must properly lay out components into the square-shaped PCB and then lay out the
traces in a manner where they do not interfere with each other. This is where organization
and neatness on a PCB can make or break a design. The design was carefully laid in an
organized manner and included the display by itself to take up the bottom half of the
PCB. The remaining open spaces of the board contained the ATmega328 IC, the Xbee,
and many passive components. In the top left of the board is the 9V power socket.
21
22
Figure 2-13 Final PCB Schematic.
23
Figure 2-14 EAGLE Trace and Route.
Figure 2-15 Water Flow PCB.
24
The final custom design PCB was named “Water Flow PCB Rev 1.0” and it was
chosen to have the PCB manufacturer company, IMAGineering, etch this information
onto the backside of the PCB copper layer. This can be seen in Figure 2-15. Other
identification information along with an “EE M PRJ” (Electrical Engineering Master’s
Project) etching was also done. It was decided the PCB would be created with throughhole only parts for ease of soldering and removal as opposed to SMD packages. The
Xbee wireless device and ATmega328 processor would be placed into sockets for ease of
removal and programming. The switches ended up being 3 pin headers and shunts. This
was more convenient and easier to implement. The water flow sensor is able to be
connected to a 3pin header on the left side of the PCB. Just above it is the battery jack for
the 9-volt battery. In the end, it was chosen to have the board professionally soldered at
Accurate Electronics, an electronics contract manufacturing facility located in
Chatsworth, CA. All parts and services used are detailed in the Appendix A: Supply.
25
Chapter 3: Implementation Theory
3.1 Basic Code Flow Chart
Program Initialization
- Set Baud Rate
- Initialize Pins
- Set Variables
Set Timer – Wait until
1 second has passed
Count pulses from
Hall Effect flow meter
Time Reached –
1 second passed
Calculate liters per
minute from amount
of pulses collected
Print to LCD
- Display whole number
- Display fraction number
Figure 3-1 Basic Code Flow Chart.
The basic code flow chart, Figure 3-1, details essentially what both devices will be
doing at the same time. This means both will perform calculations and output the flow
liters per minute to the LCD for the pipe they are located on. What differs between the
two devices is what follows after the calculations of the display to the LCD. The master
device is the “sender” which will tell the other pipes down the same network of what
flow it is reading. This pipe is considered the golden copy because the source of the flow
is coming through this pipe. The slave device, or the “receiver”, is the one down the
26
pipeline and it must receive this data to determine if the flow is still on par with what is
being sent from the source.
3.2 Master and Slave Flow Chart
Take calculations and
divide into proper data
packets
Sender
Send initialization
header packet
Send data packets of
calculations
- #1 whole number
- #2 fraction number
Wait for initialization
packet to begin
receiving data
Initialization header
packet received,
Prepare to flow data
packets
Receiver
Receive flow data packets
Parse values into integers
and store variables
Perform calculations
Print to LCD
- Display master flow
liters per min
Figure 3-2 Master and Slave Flow Chart.
27
In Figure 3-2, the flow explains how the master and slave device relate to each other.
The master device, which is the source of the flow, splits the calculations into packets to
send over the Xbee device. It first sends an initialization header and then transmits the
data packets which are separated into the whole number value and the fraction number
value. The slave device is actively waiting for the initialization header because it will not
process any values until it receives them. When the initialization header packet is
received, it then prepares to receive separated data packets, one for the whole number and
one for the fraction value. When it receives those values, which are done in serial bits, it
will then parse them properly into integers to store as variables in its calculations. It then
takes those values and also displays them onto its own LCD.
28
3.3 Error Calculation Flow Chart
Compare current
calculations of flow
versus received
calculations of flow
Are the values different too
from each other?
This depends on the flow
tolerance allowed
NO
YES
Water flow should be in good
standing
Spike tolerance counter
checked – if necessary, reset
bad standing counter
Counter is started
This is a timer to
determine how long the
flow is in bad standing
Counter increases every
second flow tolerances are
too different
Print error message to
LCD to alert of water
flow issue
30 seconds passed – bad
standing confirmed –
initiated error message
Figure 3.3 Error Calculation Flow Chart.
29
The steps to determine error calculation are shown in Figure 3.3. The error
calculation is done on the receiver unit. By taking the received flow calculations and
comparing it to the current flow calculations at the pipe it is at, there can be a
summarized difference between the two. The user has the option to decrease or increase
flow tolerance to give the pipe some leeway for skips in flow or spikes in flow. The
tighter the tolerance is, the more possibility of an alert being obtained. This can be good
or bad because the user does not want false positives. When the flow tolerance is
violated, the receiver device will implement a counter to determine how long the flow is
in bad standing. If the flow returns to good standing and the water spike tolerance is
noted, the counter is reset. If the flow continues to be different than expected, when 30
seconds are reached, the flow is now considered bad and the device will display a
message to the user of the inferred leak.
Much of the heart of the leak detection system is done in the error calculation
programming. The user must not want false positives because that would throw the
reliability of the program away. At the same time, the program cannot have too high of a
tolerance because then a leak would go undetected. When a potential leak is detected, it
must then go through even more checks. A 30 second timer is done on purpose to make
sure that the flow is not having ordinary skips or spikes. Since fluids cannot move in
perfect shape 100 % of the time, skips and spikes are to be expected. Only after violating
the tolerance for a full 30 seconds does the program conclude possible leak detection.
To see the full project resource code, see Appendix B: Source Code.
30
Chapter 4: Experiment and Results
4.1 Normal Flow Results
The normal flow results, represented in Table 4-1 and Figure 4-1, are the expected
results that all the pipes should be reading when under normal operations. This is
basically the control value of the experiment.
Normal Flow
High
Med
Low
Pipe 1
(M) L/m
7.8
5.0
1.9
Pipe 2 (S)
L/m
7.7
4.9
1.4
Leak
Detected?
N
N
N
Tolerance
L/m
+/- 0.5
+/- 0.5
+/- 0.5
Table 4-1 Normal Flow Chart.
Normal Flow
8
Liters per minute
7
6
5
4
Pipe 1 (M)
3
Pipe 2 (S)
2
1
0
High
Med
Flow Rate
Low
Figure 4-1 Normal Flow Graph.
31
The water pump used was able to control the amount of water taken in with a dial so
these values were recorded as the normal flow values. This helps give an idea what the
flow rates should normally be when there are no leaks present. The water flow rate is
recorded in liters per minute. It was noted that both the high and medium flow rate
settings had close values between the two pipes. However the low setting which had a
steady value of about 1.9 L/m at the master pipe had a fall off at the exit pipe. The exit
pipe only recorded 1.4 L/m. This was most likely because there is less water pressure and
overall liquid flow moving around the pipe decreases by the time it reaches the exit pipe.
The value however was still in line with the tolerance allowed, +/- 0.5 L/m, so there was
no false positive alert created.
32
Figure 4-2 Real Time Flow Readings.
Pictured in Figure 4-2 is the real time shot of the master and exit pipe readings. The
master device is pictured on the top and the calculations and output are being sent to the
slave device which is seen on the bottom. That is why the operator can see both 7.7
L/min on both screens.
33
4.2 Little Leak Flow Results
Figure 4-3 Little Leak Valve Setting.
The little leak valve setting, Figure 4-3, is created by turning the valve to a point
where only a small amount of water can escape. The valve is at around 15 – 20 degrees
from its default position. The pipeline is still run at the three water pump flow rates from
high to medium to low.
34
Little Leak
High
Med
Low
Pipe 1
(M)
8.3
5.3
2.1
Pipe 2 (S)
7.4
3.3
1.0
Leak
Detected?
Y
Y
Y
Tolerance
+/- 0.5
+/- 0.5
+/- 0.5
Table 4-2 Little Leak Flow Table.
Liters per minute
Little Leak Chart
9
8
7
6
5
4
3
Pipe 1 (M)
Pipe 2 (S)
2
1
0
High
Med
Flow Rate
Low
Figure 4-4 Little Leak Flow Graph.
The little leak experiment involved trying to see if the device would alert the user if a
little leak was present in the pipeline. The results, shown in Table 4-2 and Figure 4-4,
were that all three flow rates were successful in showing this. While the master pipe held
the original source flow rate, the amount of fluids loss through the leak valve was
demonstrated when the calculations were performed at the exit pipe. These pipes all
35
showed a decrease in liters per minute. It was noticeable that the medium and low
settings showed a decrease to almost half of their original value. Only the high flow rate
showed a smaller loss and this was most likely because a little leak could not be enough
to drastically change the high flow rate. Another trend to note is that the master flow
values for all three rates actually increased versus their normal control values. This is
because the little leak acts as an escape point where pressure is trying to burst through the
leak. Since the water is trying to also escape the valve as fast as possible, this actually
increases the liters per minute at the master pipes. Figure 4-5 demonstrates an alert.
Figure 4-5 Leak Detected Alert.
The little leak has a lot more “spiking” involved in the water flow rates so it was seen
that the values between both pipes would move wildly until the pressure was equalized.
This plays a role in determining the leak because the code must be able to allow for large
shifts in calculations but still continue to interpret a possible leak. This is done internally
through the “water spiking tolerance” code that can be seen in the Appendix B: Source
Code.
36
4.3 Big Leak Flow Results
Figure 4-6 Big Leak Valve Setting.
The big leak valve setting, Figure 4-6, is created by turning the valve parallel or
basically a full 90 degrees from its starting position. The big leak is essentially the valve
being completely open. The example shown in Figure 4-6 shows a lot of water pouring
out of the valve which means little water is passing through to the exit pipe.
37
Big Leak
High
Med
Low
Pipe 1
(M)
10.7
6.3
1.7
Pipe 2 (S)
5.2
2.1
0.7
Leak
Detected?
Y
Y
Y
Tolerance
+/- 0.5
+/- 0.5
+/- 0.5
Table 4-3 Big Leak Flow Table.
Big Leak Chart
12
Liters per minute
10
8
6
Pipe 1 (M)
Pipe 2 (S)
4
2
0
High
Med
Flow Rate
Low
Figure 4-7 Big Leak Flow Graph.
38
The effect shown with the big leak, Table 4-3 and Figure 4-7, is dramatic across all
three flow rates. Because there is essentially an open hole in the pipeline where the water
can escape freely, the flow rates at the exit pipes are halved in all flow rate experiments.
There is a “bursting dam” effect on the master pipe which also increases their initial flow
rates before the pressure is equalized. The tolerance used in these experiments is still +/0.5 L/m which is more than enough to differentiate between any spikes in the big leak.
All three pipeline results were able to detect the big leak. This means the leak detection
system inferred the correct leak. Unlike the little leak experiment were the high flow rate
brushed off the little leak in the valve, here the high flow rate showed a large decrease in
water flow from the master pipe to the exit pipe. Water flows where there is least
resistance so exiting the leak valve is more expected. This forces any of the high flow
rate experiment to lose water much more dramatically than in the little leak were the
opening is tiny and not much water can escape.
39
Figure 4-8 Water Levels in Bucket Reservoir.
The effect of the big leak in the pipeline can be seen in the water levels of the bucket
reservoir in Figure 4-8. The water drains so fast that within a couple of seconds the
bucket is nearly empty.
40
4.4 Results Comparisons
Comparison
Pipe 1 (M)
Normal
L/m
High
Med
Low
*Avg*
7.8
5.0
1.9
4.9
Comparison
Pipe 2 (S)
Normal
L/m
High
Med
Low
*Avg*
7.7
4.9
1.4
4.7
Little
Leak
L/m
8.3
5.3
2.1
5.2
Little
Leak
L/m
7.4
3.3
1.0
3.9
Difference
Big Leak
L/m
Difference
0.5
0.3
0.2
0.3
10.7
6.3
1.7
6.2
2.9
1.3
-0.2
1.3
Difference
Big Leak
L/m
Difference
-0.3
-1.6
-0.4
-0.8
5.2
2.1
0.7
2.7
-2.5
-2.8
-0.7
-2.0
Figure 4-9 Comparison Flows of Pipe 1 and Pipe 2.
It can be noted that when comparing the results, Figure 4-9, between the master pipe,
there is an average gain resulted from both the little leak and big leak. The gain itself is
the increase in liters per min on the master pipe. Likewise, there is an average loss
resulted from the little leak and big leak on the exit pipe. This behavior helps to fuel the
code behind how to interpret the data readings from the pipes. The little notes in spikes
and skips during the experiment also helped to determine the tolerance values when
programming the algorithm. It is preferred that the tolerance value be able to disregard
skips and spikes but still be able to notice a deviation of water flow that stays
permanently.
41
Flow Rate Trend - Pipe 1 (M)
12
11
10
9
High
7
Med
6
Low
Liters per minute
8
Linear (High)
5
Linear (Med)
4
Linear (Low)
3
2
1
0
Normal L/m
Little Leak L/m
Big Leak L/m
Flow Rate Trend - Pipe 2 (S)
9
8
Liters per minute
7
6
High
Med
5
Low
4
Linear (High)
Linear (Med)
3
Linear (Low)
2
1
0
Normal L/m
Little Leak L/m
Big Leak L/m
Figure 4-10 Comparison Flow Graphs.
42
The comparison of the data gathered between all water pump flow rates with a little
leak and big leak are shown on the charts and graphs in Figure 4-9 and Figure 4-10. By
examining and comparing the data, the operator can observe and notice trends that are
occurring in the measured flow rates between the master and exit pipe. The two most
noticeable trends shown are an increase and decrease in flow rate (liters per minute).
The increase is shown in the master pipe. Going from normal flow which has no leak
present to little leak and then to big leak, it can be seen that the water flow rate rises. The
comparison flow graphs in Figure 4-10 are shown with a trend line to demonstrate this.
The one example where this does not come true is when the water flow on the pump is set
to low. This can be interpreted in that the low setting does not have much impact on the
flow of water and that the water is just flowing freely. When flowing freely, it can
gravitate toward the leak valve and the second pipe equally. On the medium and high
settings of the water pump, all flow rates begin to rise upwards. This was seen as the
“bursting” effect when the water finds an escape point. When the pressure is equalized
however, the water flow was seen to subside to a steady value.
The decrease in the water flow can be seen in the exit pipe. All three pipes showed a
decline in water flow rate at all three pump settings. One interesting observation in the
data collected is that the high flow water pump setting combined with the little leak
showed less decrease than the other two settings. This was interpreted as that water
would want to flow to the path of least resistance. Since a high flow rate of water cannot
easily exit through a little leak, the path of least resistance would be to actually go toward
the exit pipe. However, when the big leak is introduced, the path of least resistance for all
three pump settings would then become the big leak exit. This is especially seen when
43
comparing the data going from Pipe 1 to Pipe 2 (master to exit pipe). The water flow rate
drops dramatically, basically by half. It is important to remember what was mentioned
earlier. Little leaks in high flows generally go unseen in leak detection systems. This
project is using small-scale pipes and much lower flow than real life pipelines. In this
case, even though the little leak and high flow combination was able to be detected, in a
real life system, this is the case where it might go undetected. This was the point
explained during “Leak Characterization”.
Nonetheless, the point of the project was to see how water behaved with a leak and to
use a computer programmed algorithm to interpret a leak. All leaks whether little or big
were intercepted by the program. This means the program alerted the operator of a “Leak
Detected”.
44
Chapter 5: Observation and Conclusion
5.1 Observation
Some observations for the project included a future idea of the use of a GPS. If a
larger scale model of the project was built, it could have a GPS inserted into the device.
This can actually be seen in the final design Water Flow PCB picture, Figure 2-15. If a
pipeline were miles long, a GPS could theoretically interpret the location of where a leak
was present thus creating an even better localizing method. The GPS will also provide a
time stamp on data which is useful for analyzing and determining when a leak might have
occurred. Another observation is the inclusion of different balancing methods. Due to
cost, the current experiment only used a single water flow meter. Multiple devices could
be introduced to help provide redundancy and further strengthen the inference of a leak.
If a water flow meter can help infer a leak, multiple devices inferring a leak could help
the operator determine if a leak is real or merely a false positive alert.
5.2 Conclusion
Overall, the Water Leak Detection device was very successful. It was able to interpret
leaks through a computer programmed algorithmic approach as specified in API RP-1130
standards and procedures. The device created was also not a device that existed on the
market. While methods of leak detection are already documented and exist, the device
created and finalized into a real printed circuit board assembly was built solely for this
project. The device was also built with wireless communication in mind so it could
interact with another device in the same proximity. This helped to mirror the real life
model of a pipeline because detection systems are generally spaced apart. Wireless
communication is the preferred method of communicating across great distances. When a
45
leak was present in the pipeline, the shared data and calculations between the devices
helped to infer a water leak and also alerted the operator of the event. One of the goals
was also to avoid false positives. By fine tuning the tolerances allowed and implementing
the code to allow water spikes, it was seen that all leak detections were actual leaks.
46
References
[1] “Arduino.” December 2013. <http://en.wikipedia.org/wiki/Arduino>
[2] “Arduino Duemilanove.” December 2013.
<http://arduino.cc/en/Main/arduinoBoardDuemilanove>
[3] “Configuring Xbee Radios with X-CTU.” December 2013.
<http://examples.digi.com/get-started/configuring-xbee-radios-with-x-ctu/>
[4] “Leak Detection.” December 2013. <http://en.wikipedia.org/wiki/Leak_detection>
[5] Byron Coy, PE. “Leak Detection APR-2008” February 2014.
<http://www.api.org/meetings/topics/pipeline/upload/byron_coy_phmsa.pdf>
[6] “API RP-1130” “February 2014”
<http://global.ihs.com/doc_detail.cfm?document_name=API%20RP%201130>
[7] “Adafruit Flow Meter” “February 2014” <https://github.com/adafruit/Adafruit-FlowMeter>
[8] “Connect A 16x2 LCD Display To An Arduino” “December 2013”
<http://www.instructables.com/id/Connect-A-16x2-LCD-Display-To-AnArduino/?ALLSTEPS>\
47
Appendix A: Supply
Item
Boarduino Kit
LCD
Xbee Series 1
Xbee Adapter Kit
Flow Meter
Water Pump
Small-scale Pipeline
PVC Board
PVC Connectors
Water Flow bare
PCB
Water PCB
Assembly
Description
Microcontroller Kit
16x2 Display
Wireless Device
Xbee Adapter
Flow Meter
Hydor Seltz Pump
PVC Piping
6x6 Wood Board
Brass Ends & Vinyl Tubing
Supplier
Adafruit
Sparkfun
Adafruit
Adafruit
Adafruit
Petco
Lowes
Lowes
Lowes
Bare PCB
IMAGineering
Accurate
Electronics
Supplier
Adafruit
Sparkfun
Petco
Lowes
IMAGineering
Accurate Electronics
Website
https://www.adafruit.com/
https://www.sparkfun.com/
http://www.petco.com/
http://www.lowes.com/
http://www.pcbnet.com/
http://accurate-elec.com/
Professional Soldering
48
Appendix B: Source Code
//TEDDY ARIYATHAM
//WATER FLOW PCB SENDER V1.0
//12/1/13
//PERFROM FLOW CALC, DISPLAY TO LCD, SEND TO RECEIVER
#include <LiquidCrystal.h>
LiquidCrystal lcd(9, 8, 4, 5, 6, 7);
byte sensorInterrupt = 0; // 0 = pin 2; 1 = pin 3
byte sensorPin
= 2; // the sensor pin from flow sensor (yellow wire)
volatile byte pulseCount;
float calibrationFactor;
float flowRate;
unsigned int frac;
unsigned long oldTime;
void setup()
{
Serial.begin(57600);
lcd.begin(16, 2);
lcd.print("Setup Initialize");
delay(100);
49
lcd.clear();
pinMode(sensorPin, INPUT);
digitalWrite(sensorPin, HIGH);
calibrationFactor = 7.5; //pulse freq, in L/min
pulseCount
flowRate
frac
oldTime
= 0;
= 0.0;
= 0;
= 0;
attachInterrupt(sensorInterrupt, pulseCounter, FALLING);
}
void loop()
{
if((millis() - oldTime) > 1000)
// Only process counters once per second
{
detachInterrupt(sensorInterrupt); //immediately stops caring for the sensor
flowRate = ((1000.0 / (millis() - oldTime)) * pulseCount) / calibrationFactor;
oldTime = millis();
frac = (flowRate - (int)flowRate) * 10;
lcd.clear();
lcd.setCursor(0, 0);
50
lcd.print(" ");
lcd.setCursor(0, 0);
lcd.print("Flow: ");
if(int(flowRate) < 10)
{
lcd.print(" ");
}
else
{};
lcd.print((int)flowRate, DEC); // Print the integer part of the variable
lcd.print('.');
// Print the decimal point
lcd.print((int)frac, DEC) ;
// Print the fractional part of the variable
lcd.print(" L");
lcd.print("/min");
//start packet
Serial.write(255);
Serial.print((int)flowRate);
Serial.write(254);
Serial.print((int)frac);
pulseCount = 0; // reinitiate sensor and start back at 0 counts
attachInterrupt(sensorInterrupt, pulseCounter, FALLING);
51
}
}
void pulseCounter()
{
pulseCount++; // Increment the pulse counter
}
52
//TEDDY ARIYATHAM
//WATER FLOW PCB RECEIVER V1.0
//12/1/13
//PERFROM FLOW CALC, DISPLAY TO LCD, RECEIVE DATA, ALERT LEAK
#include <LiquidCrystal.h>
LiquidCrystal lcd(9, 8, 4, 5, 6, 7);
byte sensorInterrupt = 0; // 0 = pin 2; 1 = pin 3
byte sensorPin
= 2;
volatile byte pulseCount;
float calibrationFactor;
float flowRate;
unsigned int frac;
unsigned long oldTime;
int incFlowRate[2];
int failCount;
int failSeconds;
int failToleranceNum;
int waterSpike;
int flowDiff;
boolean consecutiveFail = false;
53
void setup()
{
Serial.begin(57600);
lcd.begin(16, 2);
lcd.print("Setup Initialize");
delay(1000);
lcd.clear();
pinMode(sensorPin, INPUT);
digitalWrite(sensorPin, HIGH);
calibrationFactor = 7.5; //pulse freq, in L/min
pulseCount
flowRate
frac
= 0;
= 0.0;
= 0;
oldTime
= 0;
failSeconds
= 60; //user can change how long to wait before failure is imminent
waterSpike
= 0; //detects water flow spikes where it's an OKAY
failToleranceNum = 1; //user can detect how many water spikes allowed, otherwise a
continuous 60 secs of failure is triggered
flowDiff
= 50; //user can select the amount of water flow difference that triggers a
failcount (50 is .5L, default)
54
attachInterrupt(sensorInterrupt, pulseCounter, FALLING);
}
void loop()
{
if((millis() - oldTime) > 1000)
// Only process counters once per second
{
detachInterrupt(sensorInterrupt);
flowRate = ((1000.0 / (millis() - oldTime)) * pulseCount) / calibrationFactor;
oldTime = millis();
frac = (flowRate - int(flowRate)) * 10;
// print code
printToLCD("Flow1:", (int)flowRate, (int)frac, 0);
//read packet
if (Serial.available())
{
byte header = Serial.read();
if (header == 255){
incFlowRate[0] = Serial.parseInt();
incFlowRate[1] = Serial.parseInt();
}
55
}
// print code
printToLCD("Flow2:", incFlowRate[0], incFlowRate[1], 1);
// fail startup
int slaveVal = flowRate*10;
int masterVal = incFlowRate[0]*10 + (incFlowRate[1]);
if ( masterVal*10 - slaveVal*10 > flowDiff) //more than - .5 difference in water flow
{
failCount++;
}
else
{
if (waterSpike++ == failToleranceNum)
{
failCount = 0;
waterSpike = 0;
}
else
{
waterSpike++;
}
56
}
//failCount 60 implies roughly 60 seconds of missed results
if (failCount == failSeconds)
{
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("LEAK DETECTED");
while(1)
{
//loop
}
;
}
pulseCount = 0;
attachInterrupt(sensorInterrupt, pulseCounter, FALLING);
}
}
void pulseCounter()
{
// Increment the pulse counter
57
pulseCount++;
}
void printToLCD(String devU, int leftDigit, int rightDigit, int cursorRow)
{
lcd.setCursor(0, cursorRow);
lcd.print(devU);
if(int(leftDigit) < 10)
{
lcd.print(" ");
}
lcd.print(leftDigit); // Print the integer part of the variable
lcd.print('.'); // Print the decimal point
lcd.print(rightDigit) ; // Print the fractional part of the variable
lcd.print(" L");
lcd.print("/min");
}
58