Low Cost Wireless Water Meter using Atmega328P microcontroller
Автор: ZIMBANGO POMERAI, ZIBAYIWA MORELIFE

Water Telemeter System Design 
Highlights
In this project a water usage telemeter system was introduced. It consists of a cellular network enabled water meter and associated receiver unit making up a complete wireless telemetry system. The data receiving unit is not more than just a single input cellular to LAN interface which ferries the received GSM text data into the local database system. Graphical User Interface (GUI) to interpret database contents into useful monitoring information is part of the data receiving section. The focus is to address data collection challenges particularly within council-managed water supply and distribution systems. Access to real time data about water consumption and supply levels is of major importance to the management council of every city or town. Measuring actual water consumption would made it possible for the council to put in place a sound tariff policy for long term and stable development of water supply and sanitation systems [1]. The principal operation of the developed water meter is based on the counting of Hall Voltage pulses generated from the embedded flow sensor as the water passes through it. Turbine flow sensors have the capability to accomplish this goal and are used in most industrial instrumentation and telemetry systems for flow measurements purposes [2]. The completed work is partly related to a system developed by an inventor Tao Xaing in which a final data destination mobile terminal is interfaced wirelessly with a remote server of which the remote server is connected to a gsm enabled water meter via a cellular network [3]. Ability to accurately measure water usage, transmit data via third part cellular network with backup redundancy and manage usage using online servers and platforms were major breakthroughs in this project. As the water usage instances and cellular signal availability are indeterministic events, innovative mechanism to counter all chances of data loss were skilfully crafted and implemented on the final product. Multiple experiments to study fluid mechanics that would affect accuracy of the meter were carried out. With parallel processing capability, this meter had the ability to handle external conditions independently archiving smooth data capturing, onboard processing and transmission. The data processing speed in multithreading mode registered the design to be one of highest performing meters over a wide range of fluid flow variations. Overall performance analysis of this meter unit has covered various important aspects that influence the applicability of the meter in the industrial domain. Lack of a PCB printing machine has forced required PCB designs to be realized on an ordinary Veroboard using traditional soldering techniques. Industrial model based on the current version of the prototype considers to come up with a standardized fabrication process of casings, the PCB and assembling of turbine flow sensor of various diameters.
 
Fig. 1.2: System Conceptual diagram [3,4]

The Transmitter
The Water Meter Unit consists of two (2) ATmega328P microcontrollers,1602 LCD, GSM SIM 900 and a Turbine Water Flow Rate Sensor [5,6,7,8]. It works on the Hall Effect principle in which the flow of water causes the rotation of flow sensor turbine which results in the generation of signal pulses. Frequency of these pulses form the basis at which the flow rate and quantity of flow is computed. Detection of water usage data from the sensor is random.  Apart from random sensor inputs, GSM network signal availability is not deterministic, it is random as well.  To avoid loss of data at metering and at transmission, parallel processing is necessary for the meter to handle metering and transmission independently as both tasks depend on different external conditions. This means that the first microcontroller is committed to carry water flow metering while the second microcontroller carries the transmission upon network availability. This technique of parallel processing employs the principle of Inter Processor Communication technology as given by the reference [5]. An LCD display is included to display water flow related quantities. The meter is a GSM enabled water meter in the sense that it has an ability to transmit metered data via a cellular network to a remote storage server in the form of a text message. The meter itself can store the data of up to 1.024 Kilo Bytes. And 100% of the data stored onboard is equivalent to the data submitted to the remote server. The telemetry operation of this meter is near real time as the cellular transmission is dependent on operator’s signal strength at any given time, transmission delay is obvious. 
 
 
 
 
 
 

Receiver unit
Central control subsection is the destination of the data in question. It resides at the location where the data is required for further computation. Technically this subsection consists of receiver telemetry system components with the purpose to receive telemetry data from remote locations in the form of GSM text. The nature of the components used and principal operation of this device is such that it receives data via cellular network, process it to identify transmitter number and measured value and pass this information to a database system via LAN connection. It uses a 32-bit ESP8266 RISC microcontroller board created by a Espressif. Reference [6] identifies many features of merits including the fact that it has 2.4GHz of up to 72Mbps Wi-Fi capability and it falls under the family of ultra-low-power microcontrollers consisting of several devices featuring different sets of peripherals targeted for various applications [6]. Due to its small hardware size, yet efficient, the ESP8266 was chosen to play a role of collecting and interpreting GSM data from the SIM900 module for logging into the online server through TCP/IP protocols. GSM SIM900 reveals that it is a Quad-band GSM/GPRS solution that delivers 850/900/1800/1900 MHz performance for text, voice, data and Fax, featuring an industry-standard interface [7]. The chip itself is multi-functional as indicated earlier, however this development targets its performance in receiving data in the form of a text.  The choice of the high-speed microcontroller is to ensure that no information bottleneck can occur between the reception process and transfer for storage process as the incoming of messages from remote meters is not deterministic. WiFi-based C-LAN device could ferry the data into the server at a maximum speed of 72Mbps. The designed C-LAN modem was required to have more I/O, more flash memory, ethernet or Wireless capability and fast memory access for data logging and retrieving during the course of operation. 
 
 
 
Database/Server System
This system was developed and tested using MySQL Relational Database Management System. It is an open-source software designed to allow the creation of a database and many tables to store and manipulate data and define the relationship between each table [8]. Each database has one or more distinct APIs for creating, accessing, managing, searching and replicating the data it holds. Other kinds of data stores can also be used, such as files on the file system or large hash tables in memory but data fetching, and writing would not be so fast and easy with those types of systems [8]. 
 
Figure 3.8.  XAMPP: An open-source cross-platform web server running Apache and MySQL [8]
Reference [8] described a Relational DataBase Management System (RDBMS) is a software that: Enables users to implement a database with tables, columns and indexes, guarantees the Referential Integrity between rows of various tables, updates the indexes automatically Interprets an SQL query and combines information from various tables. Instead of MySQL, other relational database management softwares can be used to serve the same purpose, only some important key aspects must be addressed prior to implementation. Key aspects include robust security measures, compatibility with other applications and programs, document control, capabilities and flexibility, simplicity in setting up and reviews from other users [9].
Hardware requirements are such that any special computer hardware that can handle processing of large volumes of data at a recommendable speed sufficient to support real time data communication among many users (e.g., city residents and industries) can be employed. For example, a system network with an Administration Server and SQL Server on different devices and designed to carry 100 000 devices, minimum specifications of the Administration Server are; CPU with 8 cores operating at 2.13Ghz, 8GB RAM, 1TB hard drive, and network adapter at 1Gbit, and that of SQL Server are: CPU with 8 cores, running at 2.53 GHz, 26GB RAM, 500GB SATA RAID hard drive and network adapter at 1Gbit [28].
3.3.3 Web Software Package
System monitoring portal offers detailed and clear system monitoring in a customizable environment. This helps the user to minutely track the performance of the Central Receiver Devices, to react quickly to abnormalities and to secure the process of getting data from remote meters. It is a web-based interface that can be hosted from any local server and used to manage large volume data reception processes, simply by comparing received bytes versus processed bytes for a given interval of time. Data about cellular network intensity, receiver to server link speed, power levels at the receiver unit as well as the actual main database is also part of the monitoring portal. The main purpose of this interface is to allow the technical personnel to have the view of all the processes taking place at the receiving equipment and ensure any abnormality is dealt with, so quickly before it results in any data losses. 
3.3.4 Development Tools Used.
3.3.4.1 Computers and Integrated Development Environment (IDE) used
The development of the software designed required laptops that are perfect for coding, that offer plenty of power, with modern multi-core processors and plenty of RAM, as this will allow developers to quickly compile the code, test it, and have multiple apps running at once. Dell XPS 15 (2020) is the best selection of a laptop to run this task, comfortable to code on for hours on end. Minimum Specifications are here stated [36]: CPU: 10th-generation Intel Core i5, Graphics: Intel Iris Plus Graphics, RAM: 8GB, Screen: 15.6" FHD+ (1920 x 1200) IPS, Storage: 250GB
Visual Studio (vs code) 2021 is currently the latest and stable release from Microsoft [10]. It is featured with an AI to learn from the code being written, and allows the developers to collaborate as a team, live and remotely when editing and debugging a code. VS code also allows sharing of servers, terminals, and comments among the developers. Therefore, Visual Studio was the best selection for the development of this software, as it comes with interesting features that make the programming process easy and simple.
3.3.4.2 Languages employed in Software development
Languages for web application development are basically chosen based on whether it is a front-end development or backend development. Frontend development is the part of a web application that the user interacts with directly. It is also referred to as the ‘client side’ of the application. It includes everything that users experience directly: text colors and styles, images, graphs and tables, buttons, colors, and navigation menu. HTML, CSS, and JavaScript are the languages used for Front End development. Backend is the server-side of the web application. It stores and arranges data, and also makes sure everything on the client-side of the website works fine. It is the part of the website that one cannot see and interact with. It is the portion of software that does not come in direct contact with the users. The parts and characteristics developed by backend designers are indirectly accessed by users through a front-end application. PHP, Python, Java, and JavaScript are the four best selections of languages used interchangeably for the development of all backend programs [10].
System Characterization
 
1. Effect of temperature on Flow rate and the Hall Voltage Frequency at constant pressure - Experimental Results.
 
Figure  Effect of temperature on flowrate and frequency Excel Experimental Data Collection.
 
Figure Oscilloscope presentation of turbine sensor pulses
 
 
Figure Effect of temperature on flow rate graphical analysis.
 
Figure Effect of temperature on pulse frequency graphical analysis.

4.3 Effect of fluid pressure on Flow Rate and Hall Effect voltage frequency at constant temperature - Experimental results
 
Figure Effect of pressure on flowrate and frequency Excel Experimental Data Collection.
 
Figure 4.6 Effect of pressure on flowrate graphical analysis
 
Figure Effect of pressure on pulse frequency graphical analysis
.
4.3 Transmitter - Flow Sensor Calibration and testing.
By counting the pulses from the output of the sensor, one could easily calculate water flow. Each pulse was approximately 2.25 millilitres. The pulse rate could vary a bit depending on the flow rate, fluid pressure and sensor orientation. Careful calibration was necessary for better than 10% precision stated by the sensor manufacturer. The pulse signal is a simple square wave so it’s quite easy to log and convert into litres per minute. 
Flow rate can be determined inferentially by different techniques like change in velocity or kinetic energy. The flow rate was determined by change in velocity of water. Velocity depends on the pressure that forces the through pipelines. As the pipe’s cross-sectional area is known and remains constant, the average velocity is an indication of the flow rate. The basis relationship for determining the liquid’s flow rate in such cases is Q=v*A, where Q is flow rate/total flow of water through the pipe, v is average velocity of the flow and A is the cross-sectional area of the pipe (viscosity, density and the friction of the liquid in contact with the pipe also influence the flow rate of water).
The experimental results on the relationship between flowrate and pulse frequency have showed that there is direct proportionality with a constant of 6.5 at constant pipe cross-sectional area. Therefore, the following calculations were used and included in the firmware code.
F(Hz) = 6.5 * Q,
Q = F / 6.5
L = Q *  t/(60 )
=  F/6.5*t/60   
T =  1/F 
Q =  (F  )/6.5=  1/(6.5 * T)  =  1/(15 * L) 
Where Q = flow rate in Litres/minute
F (Hz) =  Pulse frequency
T = Pulse return period (seconds)
L = Litres
Table Practical Examination on flow rate detection of the sensor digital output values
Trial    Actual flowrate Q = V/t    Meter flowrate Q = F/6.5
1    1ml/sec    Not detected
2    2.66 ml/sec    Not detected
3    3.43 ml/sec    Not detected
4    4.76 ml/sec    Not detected
5    5.37 ml/sec    Not detected
6    6.57 ml/sec    0.64 l/sec fluctuating
7    8.21 ml/sec    0.07 l/sec
8    11.96 ml/sec    0.26 l/sec
9    18.29 ml/sec    0.8 l/sec
10    23.56 ml/sec    1.43 l/sec
11    29.02 ml/sec    2.10 l/sec

4.4 Transmitter - Water meter PCB testing.
 
Figure   Water meter PCB testing and In-Circuit Debugging 

4.5 Transmitter - Finalized prototype of a water meter
 
Figure  Finalized Water meter device testing and accuracy confirmation
4.7 Transmitter – Water Meter Performance
The performance of the developed meter prototype is a key aspect of this project. The desire was to come up with the most accurate meter device that can maintain accuracy over a wide range of variable physical parameters such pressure, temperature and fluid flow rate. The following table outlines major performance metrics that were measured while the device was in operation.
Table 4.1. Water Meter Performance metrics analyzed.


4.6 Receiver - Finalized prototype of a C-LAN receiver

4.8 Receiver - Finalized prototypes of cellular data receiver RTUs
 
 
Figure 4.11 Finalized WiFi-based C-LAN receiver RTU


4.9 Receiver - Software User Interfaces
 
Figure 4.12 Finalized MySQL database configuration for telemetry data recording.

 
Figure 4.13 Finalized admin-side user login page

 
Figure 4.14 Finalized admin-side data presentation Dashboard.
 
Figure 4.15 Finalized admin-side RTU device selection page.

 
Figure 4.16 Finalized admin-side telemetered water usage data presentation page.

Conclusion and Future work
1 Conclusions
A complete water usage telemeter system was designed, developed and presented. The developed water meter works on the Hall Effect principle in which the flow of water causes the rotation of flow sensor turbine which results in the generation of signal pulses. Frequency of these pulses form the basis at which the flow rate and quantity of flow is computed. It uses microcontroller-based data processing electronics which conveys turbine flow sensor data into human understandable form. An LCD display is included to display water flow related quantities. It is GSM enabled water meter in the sense that it has an ability to transmit metered data via a cellular network to a remote storage server in the form of a text message. The meter itself can store the data of up to 1.024 Kilo Bytes. And 100% of the data stored onboard is equivalent to the data submitted to the remote server. The telemetry operation of this meter is near real time as the cellular transmission is dependent on operator’s signal strength at any given time, transmission delay is obvious.
Impactful benefits of the said project, such as improved data collection efficiency, near-real-time water usage monitoring and insightful data presentation platforms were implemented and presented. Mathematical background of the fluid dynamics was studied as they had major influence on the calibration of the turbine flow sensor. Further technical objectives of the system were fully identified, and addressed as presented in the previous chapter. 
2 Future Study
Few shortcomings that need further research were observed during testing. The YF S201 turbine flow sensor used cannot restrict reverse flow leading to an error, careful installation mechanisms are necessary to be examined if best accuracy is required. The embedded electronics responds to external interrupts if triggered through the flow sensor regardless of what causes them. It cannot detect whether it is due to water liquid flow or pressurized air. Need for liquid detection mechanisms to attain better accuracy in air prone flow situations.  Cavitation issues were not part of this study, however industrial requirements would need this be addressed prior to deployment as it affects metering performance. Data transmission methods are restricted to GSM only, an economically feasible redundant transmission line is necessary if exact real time is required.
 

Файлы: