Contents

1 Introduction 1

2 Literature Survey 3

3 Software Requirements Specification 5

3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Problem/Requirement Analysis . . . . . . 5
3.1.2 Requirement Specification . . . . . . . . . 5
3.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Functional Requirements . . . . . . . . . . . . . . 6
3.4 Non Functional Requirements . . . . . . . . . . . 7
3.4.1 Usability . . . . . . . . . . . . . . . . . . . 7
3.4.2 Reliability . . . . . . . . . . . . . . . . . . 7
3.4.3 Performance . . . . . . . . . . . . . . . . . 7
3.4.4 Availability . . . . . . . . . . . . . . . . . 7
3.4.5 Maintainability . . . . . . . . . . . . . . . 7
3.4.6 Scalability . . . . . . . . . . . . . . . . . . 7
3.5 Software Requirements . . . . . . . . . . . . . . . 8
3.6 Hardware Requirements . . . . . . . . . . . . . . 8

4 Components Description 9
4.1 Hardware Used . . . . . . . . . . . . . . . . . . . 9
4.1.1 Raspberry Pi . . . . . . . . . . . . . . . . 9
4.1.2 Arduino . . . . . . . . . . . . . . . . . . . 12
4.1.3 pH Sensor . . . . . . . . . . . . . . . . . . 15

iii
 4.1.4 Dissolved Oxygen Sensor . . . . . . . . . . 18
4.1.5 Temperature Sensor . . . . . . . . . . . . 19
4.1.6 Turbidity Sensor . . . . . . . . . . . . . . 21
4.1.7 Salinity Sensor . . . . . . . . . . . . . . . 22
4.1.8 Total Dissolved Solids Sensor . . . . . . . 23
4.1.9 Smartphone . . . . . . . . . . . . . . . . . 25
4.2 Software Used . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Raspbery Pi OS . . . . . . . . . . . . . . . 27
4.2.2 Arduino IDE . . . . . . . . . . . . . . . . 29
4.2.3 Firebase . . . . . . . . . . . . . . . . . . . 31
4.2.4 MIT App Inventor . . . . . . . . . . . . . 34
4.2.5 Android . . . . . . . . . . . . . . . . . . . 36

5 System Design 40
5.1 Use Case Diagram . . . . . . . . . . . . . . . . . 40
5.2 Activity Diagram . . . . . . . . . . . . . . . . . . 41
5.3 Class Diagram . . . . . . . . . . . . . . . . . . . . 41
5.4 Sequence Diagram . . . . . . . . . . . . . . . . . 41
5.5 Block Diagram . . . . . . . . . . . . . . . . . . . 43

6 Coding 44
6.1 Raspberry Pi 3 Code . . . . . . . . . . . . . . . . 44
6.2 Arduino Code . . . . . . . . . . . . . . . . . . . . 47

7 Test Results 52
7.1 IoT Sensor System . . . . . . . . . . . . . . . . . 52
7.2 Cloud Implementation . . . . . . . . . . . . . . . 53
7.3 Mobile Application . . . . . . . . . . . . . . . . . 54

8 Conclusion 60
8.1 Future Scope . . . . . . . . . . . . . . . . . . . . 61

iv
List of Figures

1 An example of the results of a lab test . . . . . . ii

1.1 Parameters affecting fish life and quality . . . . . 1
4.1 Raspberry Pi 3B Board . . . . . . . . . . . . . . . 9
4.2 Arduino Board . . . . . . . . . . . . . . . . . . . 12
4.3 pH Sensor . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Dissolved Oxygen Sensor . . . . . . . . . . . . . . 18
4.5 Temperature Sensor . . . . . . . . . . . . . . . . . 19
4.6 Turbidity Sensor . . . . . . . . . . . . . . . . . . 21
4.7 Salinity Sensor . . . . . . . . . . . . . . . . . . . 22
4.8 Total Dissolved Solids Sensor . . . . . . . . . . . 23
4.9 Smartphone . . . . . . . . . . . . . . . . . . . . . 25
4.10 Raspbery Pi OS Logo . . . . . . . . . . . . . . . . 27
4.11 Rasberry Pi OS desktop . . . . . . . . . . . . . . 28
4.12 Screenshot of the Arduino IDE showing a blink
program . . . . . . . . . . . . . . . . . . . . . . . 29
4.13 Firebase Logo . . . . . . . . . . . . . . . . . . . . 31
4.14 Firebase Cloud System . . . . . . . . . . . . . . . 32
4.15 App Inventor’s design editor . . . . . . . . . . . . 34
4.16 App Inventor’s blocks editor . . . . . . . . . . . . 35
4.17 Commercial logo as used by Google, since 2019 . 36
4.18 Android 11 home screen with Pixel Launcher . . . 37
5.1 Use Case Diagram of the Developed System . . . 41
5.2 Activity Diagram of the Developed System . . . . 42

v
5.4 Sequence Diagram of the Developed System . . . 42
5.3 Class Diagram of the Developed System . . . . . 43
5.5 Block Diagram of the Developed System . . . . . 43
7.1 IoT Sensor System . . . . . . . . . . . . . . . . . 52
7.2 IoT Sensor System Probe . . . . . . . . . . . . . . 53
7.3 Database Readings . . . . . . . . . . . . . . . . . 53
7.4 Home Page of the Mobile Application ”Oh Fish!” 54
7.5 Live Readings the IoT System Sensors are displayed 55
7.6 ”Choose Fish” Selection Screen . . . . . . . . . . 56
7.7 Results are displayed . . . . . . . . . . . . . . . . 57
7.8 About Fish page . . . . . . . . . . . . . . . . . . 58
7.9 About Parameters page . . . . . . . . . . . . . . . 59

vi
List of Tables

3.1 Functional Requirements of the System . . . . . . 6

vii
 Abstract

Fish farmers raise fish within enclosures such as ponds or in

tanks for commercial purposes like food. To achieve the op-
timum quality of the farm, there are several factors in which
the fish are cultivated in (eg. water salinity, PH, light, dissolved
oxygen, chemical composition, etc). Farmers generally test sam-
ples from their waters, stock and environments once a month or
every couple of weeks by taking it to a lab. After analysis, they
then see to the conditions of the produce in the farms and al-
ter the conditions accordingly so as to maintain optimum levels
and healthy conditions of the fish, as well as good quality of the
produce.
The objective is to create a IoT circuit of various sensors
which are required for testing conditions and to collect the data
from these sensors which will help derive the quality of the fish
to make a diagnostic report on the conditions and recommend
any insights for the farmers.
This can be implemented at as a real time system be eas-
ily accessible on an interface, instead of being conducted every
month or so and taking water to a facility some distance away.
This will help in cutting down costs in testing and in transmute
and transport.
The following figure shows an example of a test done in a
laboratory upon a sample taken from a pond. The idea is to
recreate the same result through our IoT system.
Figure 1: An example of the results of a lab test

ii
Chapter 1

Introduction

Large-scale cultivation and intensive farming have resulted in

the demise of water qualities and the decrease in quality of the
of aquatic life. Therefore, water quality management technology
improves the quality of the fish farming ponds and increase.
This project makes a use of water quality sensors such as
Dissolved Oxygen (DO), pH, Temperature, Salinity, Turbidity
and Total Dissolved Solids (TDS) sensors and then uploads them
into the Firebase cloud service. We use an Arduino UNO to
retrieve the sensor data and a Raspberry Pi3 is used to upload
the sensors’ values into the Firebase cloud database. We can
view the results of the sensor values on an application which
helps the users, farmers, to build conclusions about the readings
for pisciculture.

Figure 1.1: Parameters affecting fish life and quality

1
 The breeding, rearing, and transplantation of fish by artificial
means is called pisciculture, in other words, fish farming. It is
the principal form of aquaculture, while other methods may fall
under mariculture. It involves raising fish commercially in tanks
or enclosures, usually for food.
Internet of things, IoT, is an important part of the new gen-
eration of information technology, and has developed rapidly
both in theory and practice since proposed and has initiated
many applications such as smart home, intelligent environmen-
tal monitoring, etc. IoT has not only liberated a large amount
of manpower, but also has achieved a standardized, automated
management.
The Arduino Uno is a microcontroller board based on the
ATmega328. It has 14 digital input/output pins (of which 6 can
be used as PWM outputs), 6 analog inputs, a 16 MHz ceramic
resonator, a USB connection, a power jack, an ICSP header, and
a reset button. It contains everything needed to support the
microcontroller; simply connect it to a computer with a USB
cable or power it with an AC-to-DC adapter or battery to get
started.
The Raspberry Pi 3 Model B+ is the latest product in the
Raspberry Pi 3 range, Broadcom BCM2837B0, Cortex-A53 (ARMv8)
64-bit SoC @ 1.4GHz1GB LPDDR2 SDRAM 2.4GHz and 5GHz
IEEE 802.11.b/g/n/ac wireless LAN, Bluetooth 4.2, BLE,faster
Ethernet, and PoE capability via a separate PoE HAT The dual-
band wireless LAN comes with modular compliance certifica-
tion, allowing the board to be designed into end products with
significantly reduced wireless LAN compliance testing, improv-
ing both cost and time to market.

2
Chapter 2

Literature Survey

[1]IoT Based Aquaculture

Aquaculture, also known as aqua farming, is the farming of
aquatic organisms such as fish, crustaceans and crabs by us-
ing the various sensors to reduce the risks. Water problem is
the major effect for the growth of fish. Monitoring is essential
for water quality. This can help to save number of lives. The
proposed work supports remote monitoring of the fish farming
system based on Internet of Things (IOT) for realtime monitor
and control of a fish farming system. This will be helpful to
be aware of the danger and can take necessary safety measures.
IoT is used in this project helps updating the information about
water quality through mail. pH sensor, Water level Indicator,
Temperature Sensor and Turbidity sensor is used to measure the
water quality level. Esp32 takes the information and sends the
information through the mail if the water quality is not in the
given thresholds suitable for aquatic organisms.

[2]eMatsya – An Innovative Data Acquisition System

To Collect Fish Catch Data From Reservoirs And Other
Inland Water Bodies
Collection of real-time fish catch data from inland water bod-
ies of India has been a huge challenge for a multiplicity of fac-

3
tors – a large number of inland water resources and their scatter
being the most important among other things. To overcome
this problem, making use of mobile communication technology,
an Electronic Data Acquisition System (eDAS) was developed
along with an Android Application - eMatsya that was imple-
mented on smart mobile phones of fishery friends (knowledge-
able fishers who could send data using eMatsya) to collect fish
catch data from inland water bodies. The data sent by fish-
ery friends using eMatsya would get populated in the database
MySQL in the webserver. Trial-implementation of eMatsya in
selected reservoirs of Karnataka and Jharkhand (Indian states)
not only yielded promising results but also proved that the
scaling-up of this eDAS implementation is easy and when done
at the national level would result in a continuous flow of au-
thentic information on inland fish catch data. The eMatsya a
would significantly reduce the time, cost of collection of data
and would facilitate in developing a database of the inland fish
catch of the Indian reservoirs.

[3] IoT for Aquaculture 4.0 Smart and easy-to-deploy

real-time water monitoring with IoT
While aquaculture and IoT have exponentially grown in the
world in the last years, the combination of both domains still
remains at its early stage. Although water monitoring is at
the center of the aquaculture activity, its complexity can of-
ten push fish farmers to neglect it. We believe that developing
user-friendly IoT tools for fish farming will lead to a new era of
connected, responsible and efficient aquaculture. IoT for aqua-
culture needs to be smart, affordable, easy to deploy, reliable and
highly efficient. Artificial Intelligence processing key data given
by IoT can also provide new services addressing new challenges
facing aquaculture (e.g be efficient but green).

4
Chapter 3

Software Requirements
Specification

3.1 Purpose
The SRS phase consists of two basic activities

3.1.1 Problem/Requirement Analysis

Process is order and more nebulous of the two, deals with un-
derstand the problem,the goal and the constraints.

3.1.2 Requirement Specification

Here, the focus is on specifying what has been found giving anal-
ysis such as representation, specification languages and tools,
and checking the specifications are addressed during this activ-
ity. The Requirement phase terminates with the production of
the validate SRS document. Producing the SRS document is
the basic goal of this phase.

Role of SRS The purpose of the Software Requirement Specifi-

cation is to reduce the communication gap between the clients
and the developers. Software Requirement Specification is the
medium though which the client and user needs are accurately

5
specified. It forms the basis of software development. A good
SRS should satisfy all the parties involved in the system.

3.2 Scope
SRS provides easy and seamless integration of business solutions
with the Blockchain technology. We help simplify complex pro-
cesses with innovative Blockchain and other technologies and
its maintain the medical history of patient. The affordances of
this new technology make it well suited to solving some of the
most complex problems in health data, health financing, and
health care. Consider specifically Protection of privacy, Protec-
tion against fraud, Interoperability across diverse systems and
data formats.

3.3 Functional Requirements

After analysis, it is determined that the functional requirements
of the system are as follows:
Functional Re- Functional Requirement Description
quirement No.
FR1 System must be connected to a power source at all
times
FR2 Probe must be placed in water
FR3 Connection to cloud must be established by connecting
the system to WiFi
FR4 Data must be transferred from system to cloud
FR5 User should be able to get live parameter readings of
water through mobile application
FR6 User should be able to view conclusion based on selec-
tion of fish through mobile application

Table 3.1: Functional Requirements of the System

6
3.4 Non Functional Requirements
3.4.1 Usability
The system should be very easy to use where the user must have
to use a limited number of buttons. Interface should be simple
and easily understandable.

3.4.2 Reliability
The system should consistently send data from all sensors to the
cloud and retrieve the same to the application.

3.4.3 Performance
The system should provide accurate readings of each parameter
at all times. It should not cease to send data to the cloud and
the application should not fail to receive the live reading.

3.4.4 Availability
The system should work continuously as long as it is connected
to a power source and the cloud exists.

3.4.5 Maintainability
The system should be very easy to be changed according to the
users’ requirement, either for type of fish or for parameters.

3.4.6 Scalability
The system should be able to upload as much data as need to
the cloud as required and be able to implement any additional
sensors if wanted.

7
3.5 Software Requirements
ˆ Operating System: Raspbery Pi OS, Andriod

ˆ IDE: Arduino IDE, MIT App Inventor

ˆ Cloud service: Firebase

ˆ Programming Languages: Python 3, C, Blockify

3.6 Hardware Requirements

ˆ Raspberry Pi 3

ˆ Arduino UNO

ˆ pH sensor

ˆ DS18B20 Temperature sensor

ˆ Dissolved Oxygen sensor

ˆ Turbidity sensor

ˆ Salinity sensor

ˆ Total Dissolved Solids sensor

ˆ Smartphone

8
Chapter 4

Components Description

4.1 Hardware Used

4.1.1 Raspberry Pi

Figure 4.1: Raspberry Pi 3B Board

Description

Raspberry Pi is a sequence of small single board computers de-

veloped in the United Kingdom by the Raspberry Pi Founda-
tion. It was released to encourage basic computer education in
schools and developing countries. There are several generations

9
of raspberry that were released. All models has a Broadcom
Chip (SoC) system with included ARM processor and integrated
graphics processing unit.

Features

ˆ Hardware Storage
Raspberry Pi hardware has been transformed by many versions
introducing variations in memory capacity and support around
the device. Models A, A+, Pi Zero miss Ethernet and USB
hub. In models A, Pi Zero and A +, the USB port is directly
connected to the system on a single chip. In models Pi 1 Model
B + and later, the USB and Ethernet chip enclose a five point
USB hub and four ports are available, While Pi 1 Model B
provides only two ports.
ˆ Processor
The Broadcom BCM2835(single chip) used in the first gen-
eration of Raspberry Pi is Somewhat same as the chip used in
the first generation of modern smartphones. In form of graphics
processing unit (GPU) and RAM. It has a level 16 (L1) cache
of 16 KB and 128 KB of level 2 cache (L2). Level 2 cache is
mainly used by the GPU.
ˆ Performance
Raspberry Pi 3, has Cortex-A53 quad-core processor, and is
equivalent to 10 times the Raspberry Pi model 1 in terms of per-
formance. Performance tests have shown Raspberry Pi model 3
is about 0.8 times faster than Raspberry Pi model 2 in paralyz-
ing activities. Raspberry Pi model 2 has a quad-core(Cortex-A7)
processor with 900 MHz and 1 GB of RAM. He is explained as
4-6 times stronger than his predecessor. Raspberry Pi model 2
is up to 14 times faster than a Raspberry Pi Model B + in terms
of parallel benchmarks.

10
 ˆ Overclocking

First and second generation Raspberry Pi CPU card does

not require cooling, like a fan and heat sink, but problem of
overclocking arises, Raspberry Pi model 3 generate more heat
in overclocked. Most of the Raspberry Pi can be overclocked at
800 MHz, and where as some can be overclocked at 1000 MHz.

ˆ RAM

On more seasoned Beta Model B cards, 128 MB was dissem-

inated of course to the GPU,leaving 128 MB for the CPU. On
the initial (and Model A) rendition and 256 MB modelB, three
unique divisions were conceivable. The default share was 192
MB (RAM for CPU),which ought to be sufficient for indepen-
dent 1080p video deciphering, or for straightforward 3D.For the
more up to date B display with 512 MB of RAM at first, there
were new standard split memory documents discharged. The
Raspberry Pi 2 and Raspberry Pi 3 have 1 GB of RAM.The
Raspberry Zero W and Pi Zero have 512 MB of RAM.

ˆ Networking

The model A, Pi Zero and A + models don't support

Ethernet circuit, and are commonly combined with a system
utility such as USB or Wi-Fi connector. B and B + models, the
Ethernet port is provided with an incorporated USB Ethernet
connector exploiting the SMSC LAN9514 chip. The Raspberry
Pi model 3 and Pi Zero are outfitted with WiFi 802.11n 2.4 GHz
and Bluetooth 4.1in light of Broadcom BCM43438 Full MAC
chip without official help for Monitor mode, however actualized
by informal firmware settle.
ˆ Power Pins

11
The header gives 5V on Pin 2 and 3.3V on Pin 1. The 3.3V sup-
ply is restricted to 50mA. The 5V supply draws current specifi-
cally from your microUSB supply so can utilize whatever is left
finished after the board has taken its offer. A 1A control supply
could supply up to 300mA once the board has drawn 700mA .

4.1.2 Arduino

Figure 4.2: Arduino Board

Description

The Arduino board exposes most of the microcontroller’s I/O

pins for use by other circuits. The Diecimila, Duemilanove, and
current Uno provide 14 digital I/O pins, six of which can produce
pulse-width modulated signals, and six analog inputs, which can
also be used as six digital I/O pins. These pins are on the top
of the board, via female 0.1-inch (2.54 mm) headers. Several
plug-in application shields are also commercially available.

Features

ˆ High Performance, Low Power AVR® 8-Bit Microcontroller

12
ˆ Advanced RISC Architecture

– 131 Powerful Instructions – Most Single Clock Cycle

Execution
– 32 x 8 General Purpose Working Registers
– Fully Static Operation
– Up to 20 MIPS Throughput at 20 MHz
– On-chip 2-cycle Multiplier
ˆ High Endurance Non-volatile Memory Segments

– 4/8/16/32K Bytes of In-System Self-Programmable Flash

program memory(ATmega48PA/88PA/168PA/328P)
– 256/512/512/1K Bytes EEPROM (ATmega48PA/88PA/168PA/328P)
– 512/1K/1K/2K Bytes Internal SRAM (ATmega48PA/88PA/168PA/328P)
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
– Data retention: 20 years at 85°C/100 years at 25°C(1)
– Optional Boot Code Section with Independent Lock
Bits
– In-System Programming by On-chip Boot Program
– True Read-While-Write Operation
– Programming Lock for Software Security
ˆ Peripheral Features

– Two 8-bit Timer/Counters with Separate Prescaler and

Compare Mode
– One16-bitTimer/Counter with Separate Prescaler, Com-
pare Mode, and Capture Mode
– Real Time Counter with Separate Oscillator
– Six PWM Channels

13
 – 8-channel 10-bit ADC in TQFP and QFN/MLF pack-
age Temperature Measurement
– 6-channel 10-bit ADC in PDIP Package Temperature
Measurement
– Programmable Serial USART
– Master/Slave SPI Serial Interface
– Byte-oriented 2-wire Serial Interface (Philips I2C com-
patible)
– Programmable Watchdog Timer with Separate On-chip
Oscillator
– On-chip Analog Comparator
– Interrupt and Wake-up on Pin Change
ˆ Special Microcontroller Features

– Power-on Reset and Programmable Brown-out Detec-

tion
– Internal Calibrated Oscillator
– External and Internal Interrupt Sources
– Six Sleep Modes: Idle, ADC Noise Reduction, Power-
save, Power-down, Standby, and Extended Standby
ˆ I/O and Packages

– 23 Programmable I/O Lines

– 28-pin PDIP, 32-lead TQFP, 28-pad QFN/MLF and
32-pad QFN/MLF
ˆ Operating Voltage:

– 1.8 - 5.5V for ATmega48PA/88PA/168PA/328P

ˆ Temperature Range:

14
 – -40°C to 85°C
ˆ Speed Grade:

– 0 - 20 MHz @ 1.8 - 5.5V

ˆ Low Power Consumption at 1 MHz, 1.8V, 25°C for AT-
mega48PA/88PA/168PA/328P:
– Active Mode: 0.2 mA
– Power-down Mode: 0.1 µA
– Power-save Mode: 0.75 µA (Including 32 kHz RTC)

4.1.3 pH Sensor

Figure 4.3: pH Sensor

15
Description

A pH sensor helps to measure the acidity or alkalinity of the

water with a value between 0-14. When the pH value dips be-
low seven, the water starts to become more acidic. Any number
above seven equates to more alkaline. Each type of pH sensor
works differently to measure the quality of the water. To mea-
sure the pH of a solution, the electrodes are used as probes,
which are dipped into the test solutions and held there suffi-
ciently long for the hydrogen ions in the test solution to equili-
brate with the ions on the surface of the bulb on the glass elec-
trode. This equilibration provides a stable pH measurement.
The Analog pH Sensor Kit is specially designed for Arduino
controllers and has a built-in simple, convenient, and practical
connection and features. It has an LED that works as the Power
Indicator, a BNC connector, and a PH2.0 sensor interface. To
use it, just connect the pH sensor with the BND connector, and
plug the PH2.0 interface into the analog input port of any Ar-
duino controller. If pre-programmed, you will get the pH value
easily. Comes in a compact plastic box with foams for better
mobile storage

Common Applications

ˆ Water quality testing

ˆ Aquaculture

Cautions

Please use an external switching power supply, and the voltage

as close as possible to the +5.00V. More accurate the voltage,
the higher the accuracy!
Before the electrode in continuous use every time, you need
to calibrate it by the standard solution, in order to obtain more
accurate results. The best environment temperature is about

16
25 , and the pH value is known and reliable, close to the mea-
sured value. If you measure the acidic sample, the pH value of
the standard solution should be 4.00. If you measure the al-
kaline sample, the pH value of the standard solution should be
9.18.Subsection calibration, just in order to get better accuracy.
Before the pH electrode measured different solutions, we need
to use water to wash it. We recommend using de-ionized water.
Connect equipment according to the graphic, that is, the pH
electrode is connected to the BNC connector on the pH meter
board and then use the connection lines, the pH meter board is
connected to the analog port 0 of the Arduino controller. When
the Arduino controller gets power, you will see the blue LED on
board is on.
Upload the sample code to the Arduino controller.
Put the pH electrode into the standard solution whose pH
value is 7.00or directly shorted the input of the BNC connector.
Open the serial monitor of the Arduino IDE, you can see the pH
value printed on it, and the error does not exceed 0.3. Record
the pH value printed, then compared with 7.00, and the differ-
ence should be changed into the Offset in the sample code. For
example, the pH value printed is 6.88, so the difference is 0.12.
You should change the # define Offset 0.00 into # define Offset
0.12 in your program.
Put the pH electrode into the pH standard solution whose
value is 4.00. Then wait about one minute, adjust the gain
potential device, let the value stabilize at around 4.00. At this
time, the acidic calibration has been completed and you can
measure the pH value of an acidic solution.

Specifications

ˆ Input Supply voltage (VDC): 5

ˆ Module Size (mm): 50 x 47 x 16

17
 ˆ Measuring Range: 0 - 14 pH

ˆ Measuring Temperature : 0 - 50 ◦ C

ˆ Accuracy: 0.01 pH

ˆ Response Time: 1 min

ˆ Cable Length (cm): 75

ˆ pH sensor size (mm) : 150, 12

4.1.4 Dissolved Oxygen Sensor

Figure 4.4: Dissolved Oxygen Sensor

Description

For aquaculture, if DO level falls too low then the fish will suf-
focate as a consequence. In a sewage treatment plant, bacteria
will decompose the solids. If DO level is too low, then the bac-
teria will die and the decomposition will cease; if DO level is too
high, then the energy will be wasted through the aeration of the
water. In industrial applications, including boilers, the make-up

18
water must have low DO levels in order to avoid corrosion and
boiler scale build up. Monitoring dissolved oxygen content is es-
sential for ensuring process efficiency, because boiler scale build
up inhibits heat transfer. A high DO level in water improves the
taste of drinking water. However, high DO levels will increase
corrosion in water plumbing and transport lines.

Common Applications

ˆ Fish farming and aquatic environment health

ˆ Live fish transport

ˆ Waste water treatment

ˆ Industrial make up waters

ˆ Corrosion control

4.1.5 Temperature Sensor

Figure 4.5: Temperature Sensor

19
Description

The DS18B20 is a 1-wire programmable Temperature sensor

from maxim integrated. It is widely used to measure tempera-
ture in hard environments like in chemical solutions, mines or
soil etc. The constriction of the sensor is rugged and also can
be purchased with a waterproof option making the mounting
process easy. It can measure a wide range of temperature from
-55°C to +125° with a decent accuracy of ±5°C. Each sensor
has a unique address and requires only one pin of the MCU to
transfer data so it a very good choice for measuring temperature
at multiple points without compromising much of your digital
pins on the microcontroller.

Specifications

ˆ Programmable Digital Temperature Sensor

ˆ Communicates using 1-Wire method

ˆ Operating voltage: 3V to 5V

ˆ Temperature Range: -55°C to +125°C

ˆ Accuracy: ±0.5°C

ˆ Output Resolution: 9-bit to 12-bit (programmable)

ˆ Unique 64-bit address enables multiplexing

ˆ Conversion time: 750ms at 12-bit

ˆ Programmable alarm options

ˆ Available as To-92, SOP and even as a waterproof sensor

20
4.1.6 Turbidity Sensor

Figure 4.6: Turbidity Sensor

Description

It is very efficient; the Arduino Turbidity Sensor is able to de-

tect and verify the quality of the water, making the turbidity
measurement, where it is possible to verify the results by means
of digital or analog signal next to the corresponding pins in the
accompanying electronic module.
The Turbidity Sensor emits at its end an infrared light, im-
perceptible to human vision, capable of detecting particles that
are suspended in water, measuring the light transmittance and
the dispersion rate, which changes according to the Amount of
TSS (Total Suspended Solids), increasing the turbidity of the
liquid whenever levels increase.
In general, the Arduino Turbidity Sensor is applied in projects
involving the monitoring of water turbidity in rivers, streams,

21
lakes, water bodies, catchment and research sites, laboratories,
tanks with liquids and so on. This Turbidity Sensor has an end
specially prepared for direct contact, having an electronic mod-
ule to amplify and send the received data to the microcontroller
of the project.

Specifications

ˆ Operating Voltage: 5VDC

ˆ Current: 30mA (MAX)
ˆ Operating temperature: -30°C to 80°C
ˆ Measuring Range: 0 ∼ 1000 NTU

4.1.7 Salinity Sensor

Figure 4.7: Salinity Sensor

22
Description

The Salinity Sensor easily and precisely measures the total dis-
solved salt content in an aqueous solution. Measure water with
a wide variety of salinities, from brackish water to ocean water,
and even hyper-saline environments. You can also study how
salinity affects buoyancy or monitor salinity values in estuaries
where fresh water mixes with ocean water.

Specifications

ˆ Salinity Range: 1 to 55 ppt ±1 ∼ (with calibration)

ˆ Conductivity Range: 1,000 to 100,000 µS/cm

ˆ Temperature Range: 0 to 50°C

4.1.8 Total Dissolved Solids Sensor

Figure 4.8: Total Dissolved Solids Sensor

23
Description

TDS = Total Dissolved Solids, is a measure of the dissolved com-

bined content of all inorganic and organic substances present in
water. Typically, the higher the TDS value, the more substances
dissolved in water. Hence, higher levels of Total Dissolved Solids
(TDS) can indicate that water has more contaminants that can
pose health risks.

Applications

ˆ TDS meter/TDS tester

ˆ Swimming pool

ˆ Aquarium

ˆ Well water

ˆ Hydroponics

Specifications

ˆ Grove - TDS Sensor

ˆ Input Voltage: 3.3/5V

ˆ Output Voltage: 0 ∼ 2.3V

ˆ Working Current: 3 ∼ 6mA

ˆ TDS Measurement Range: 0 ∼ 1000ppm

ˆ Power indication LED

ˆ Connection Interface: Grove 4-Pin / XHB 2.54mm 2P

24
4.1.9 Smartphone

Figure 4.9: Smartphone

Description

A smartphone is a mobile device that combines cellular and mo-

bile computing functions into one unit. They are distinguished
from feature phones by their stronger hardware capabilities and
extensive mobile operating systems, which facilitate wider soft-
ware, internet (including web browsing over mobile broadband),
and multimedia functionality (including music, video, cameras,
and gaming), alongside core phone functions such as voice calls
and text messaging. Smartphones typically contain a num-
ber of metal–oxide–semiconductor (MOS) integrated circuit (IC)
chips, include various sensors that can be leveraged by their soft-
ware (such as a magnetometer, proximity sensors, barometer,

25
gyroscope, or accelerometer), and support wireless communica-
tions protocols (such as Bluetooth, Wi-Fi, or satellite naviga-
tion).
Early smartphones were marketed primarily towards the en-
terprise market, attempting to bridge the functionality of stan-
dalone personal digital assistant (PDA) devices with support
for cellular telephony, but were limited by their bulky form,
short battery life, slow analog cellular networks, and the im-
maturity of wireless data services. These issues were eventu-
ally resolved with the exponential scaling and miniaturization
of MOS transistors down to sub-micron levels (Moore’s law),
the improved lithium-ion battery, faster digital mobile data net-
works (Edholm’s law), and more mature software platforms that
allowed mobile device ecosystems to develop independently of
data providers.
In the 2000s, NTT DoCoMo’s i-mode platform, BlackBerry,
Nokia’s Symbian platform, and Windows Mobile began to gain
market traction, with models often featuring QWERTY key-
boards or resistive touchscreen input, and emphasizing access to
push email and wireless internet. Following the rising popular-
ity of the iPhone in the late 2000s, the majority of smartphones
have featured thin, slate-like form factors, with large, capaci-
tive screens with support for multi-touch gestures rather than
physical keyboards, and offer the ability for users to download
or purchase additional applications from a centralized store, and
use cloud storage and synchronization, virtual assistants, as well
as mobile payment services. Smartphones have largely replaced
PDAs and handheld/palm-sized PCs.
Improved hardware and faster wireless communication (due
to standards such as LTE) have bolstered the growth of the
smartphone industry. In the third quarter of 2012, one billion
smartphones were in use worldwide. Global smartphone sales
surpassed the sales figures for feature phones in early 2013.

26
4.2 Software Used
4.2.1 Raspbery Pi OS

Figure 4.10: Raspbery Pi OS Logo

Description

Raspberry Pi OS (formerly Raspbian) is a Debian-based oper-

ating system for Raspberry Pi. Since 2015, it has been officially
provided by the Raspberry Pi Foundation as the primary operat-
ing system for the Raspberry Pi family of compact single-board
computers. The first version of Raspbian was created by Mike
Thompson and Peter Green as an independent project. The
initial build was completed in June 2012.
Previous, Raspberry Pi OS versions were 32-bit only and
based on Debian, taking the name Raspbian. Since the more re-
cent 64-bit versions no longer use Debian, the name was changed
to Raspberry Pi OS for both the 64-bit and 32-bit versions. As
of 1 February 2021, the 64-bit version is in beta and is not suit-
able for general use.
Raspberry Pi OS is highly optimized for the Raspberry Pi line
of compact single-board computers with ARM CPUs. It runs on
every Raspberry Pi except the Pico microcontroller. Raspberry
Pi OS uses a modified LXDE as its desktop environment with
the Openbox stacking window manager, along with a unique
theme. The distribution is shipped with a copy of the algebra

27
program Wolfram Mathematica and a version of Minecraft called
Minecraft: Pi Edition, as well as a lightweight version of the
Chromium web browser.

Specifications

Figure 4.11: Rasberry Pi OS desktop

ˆ Developer: Raspberry Pi Foundation

ˆ OS family: Unix-like

ˆ Working state: Current

ˆ Source model: Open source

ˆ Latest release: Raspberry Pi OS (32-bit) / 2021-01-11

ˆ Marketing target: Raspberry Pi

ˆ Available in: English, and other languages

ˆ Update method: APT

ˆ Package manager: dpkg

ˆ Platforms ARM i386 version available

28
 ˆ Kernel type: Monolithic

ˆ Userland: GNU

ˆ Default user interface: LXDE

ˆ License: Free and open-source software licenses (mainly

GPL)
ˆ Official website: www.raspberrypi.org/software/operating-
systems/

4.2.2 Arduino IDE

Figure 4.12: Screenshot of the Arduino IDE showing a blink program

Description

The Arduino Integrated Development Environment (IDE) is a

cross-platform application (for Windows, macOS, Linux) that is
written in functions from C and C++. It is used to write and

29
upload programs to Arduino compatible boards, but also, with
the help of third-party cores, other vendor development boards.
The source code for the IDE is released under the GNU Gen-
eral Public License, version 2. The Arduino IDE supports the
languages C and C++ using special rules of code structuring.
The Arduino IDE supplies a software library from the Wiring
project, which provides many common input and output proce-
dures. User-written code only requires two basic functions, for
starting the sketch and the main program loop, that are com-
piled and linked with a program stub main() into an executable
cyclic executive program with the GNU toolchain, also included
with the IDE distribution. The Arduino IDE employs the pro-
gram avrdude to convert the executable code into a text file in
hexadecimal encoding that is loaded into the Arduino board by
a loader program in the board’s firmware. By default, avrdude
is used as the uploading tool to flash the user code onto official
Arduino boards.
With the rising popularity of Arduino as a software platform,
other vendors started to implement custom open source compil-
ers and tools (cores) that can build and upload sketches to other
microcontrollers that are not supported by Arduino’s official line
of microcontrollers.
In October 2019 the Arduino organization began providing
early access to a new Arduino Pro IDE with debugging and
other advanced features.

Specifications

ˆ Developer(s): Arduino Software

ˆ Stable release: 1.8.13 / 16 June 2020

ˆ Repository: github.com/arduino/Arduino

ˆ Written in: C, C++, Java

30
 ˆ Operating system: Windows, macOS, Linux

ˆ Platform: IA-32, x86-64, ARM

ˆ Type: Integrated development environment

ˆ License: LGPL or GPL license

ˆ Website: www.arduino.cc/en/Main/Software

4.2.3 Firebase

Figure 4.13: Firebase Logo

Google Firebase is a Google-backed application development

software that enables developers to develop iOS, Android and
Web apps. Firebase provides tools for tracking analytics, re-
porting and fixing app crashes, creating marketing and product
experiment.
Firebase offers a number of services, including:
ˆ Analytics – Google Analytics

ˆ Authentication

ˆ Cloud messaging

ˆ Realtime database

31
 ˆ Crashlytics

ˆ Performance

ˆ Test lab

Description

Figure 4.14: Firebase Cloud System

Cloud Firestore is a cloud-hosted; NoSQL database that your

iOS, Android, and web apps can access directly via native SDKs.
Cloud Firestore is also available in native Node.js, Java, Python,
Unity, C++ and Go SDKs, in addition to REST and RPC APIs.
Following Cloud Firestore’s NoSQL data model, you store
data in documents that contain fields mapping to values. These
documents are stored in collections, which are containers for
your documents that you can use to organize your data and
build queries. Documents support many different data types,
from simple strings and numbers, to complex, nested objects.
You can also create sub collections within documents and build
hierarchical data structures that scale as your database grows.
The Cloud Firestore data model supports whatever data struc-
ture works best for your app.

32
 Additionally, querying in Cloud Firestore is expressive, effi-
cient, and flexible. Create shallow queries to retrieve data at
the document level without needing to retrieve the entire col-
lection, or any nested subcollections. Add sorting, filtering, and
limits to your queries or cursors to paginate your results. To
keep data in your apps current, without retrieving your entire
database each time an update happens, add realtime listeners.
Adding realtime listeners to your app notifies you with a data
snapshot whenever the data your client apps are listening to
changes, retrieving only the new changes.
Protect access to your data in Cloud Firestore with Firebase
Authentication and Cloud Firestore Security Rules for Android,
iOS, and JavaScript, or Identity and Access Management (IAM)
for server-side languages.

Firebase Realtime Database

The Firebase Realtime Database is a cloud-hosted database in

which data is stored as JSON. The data is synchronized in
real-time to every connected client. Clients share one Realtime
Database instances and automatically receive updates with the
newest data, when cross-platform applications are built with
iOS, and JavaScript SDKs.
The Firebase Realtime Database is a NoSQL database from
which data can be stored and synced between in real-time. It
is a big JSON object which the developers can manage in real-
time. By using a single API, the Firebase database provides the
application with the current value of the data and updates to
that data. Real-time syncing makes it easy for users to access
their data from any device, be it web or mobile.
Helps users collaborate with one another. It ships with mobile
and web SDKs, which allow us to build our app without the need
for servers. When users go offline, the Real-time Database SDKs
use local cache on the device for serving and storing changes.

33
The local data is automatically synchronized, when the device
comes online.

4.2.4 MIT App Inventor

Figure 4.15: App Inventor’s design editor

Description

MIT App Inventor is an online development platform that any-

one can leverage to solve real-world problems. It provides a
web-based “What you see is what you get” (WYSIWYG) editor
for building mobile phone applications targeting the Android
and iOS operating systems. It uses a block-based programming
language built on Google Blockly (Fraser, 2013) and inspired by
languages such as StarLogo TNG (Begel & Klopfer, 2007) and
Scratch (Resnick et al., 2009; Maloney, Resnick, Rusk, Silver-
man, & Eastmond, 2010), empowering anyone to build a mobile
phone app to meet a need. To date, 6.8 million people in over
190 countries have used App Inventor to build over 24 million
apps. We offer the interface in more than a dozen languages.
People around the world use App Inventor to provide mobile

34
solutions to real problems in their families, communities, and
the world. The platform has also been adapted to serve re-
quirements of more specific populations, such as building apps
for emergency/first responders (Jain et al., 2015) and robotics
(Papadakis & Orfanakis, 2016).

Figure 4.16: App Inventor’s blocks editor

The MIT App Inventor user interface includes two main edi-
tors: the design editor and the blocks editor. The design editor,
or designer, is a drag and drop interface to lay out the elements
of the application’s user interface (UI). The blocks editor is an
environment in which app inventors can visually lay out the
logic of their apps using color-coded blocks that snap together
like puzzle pieces to describe the program. To aid in develop-
ment and testing, App Inventor provides a mobile app called
the App Inventor Companion (or just ”the Companion”) that
developers can use to test and adjust the behavior of their apps
in real time. In this way, anyone can quickly build a mobile app
and immediately begin to iterate and test.

35
4.2.5 Android

Figure 4.17: Commercial logo as used by Google, since 2019

Description

Android is a mobile operating system based on a modified ver-

sion of the Linux kernel and other open source software, de-
signed primarily for touchscreen mobile devices such as smart-
phones and tablets. Android is developed by a consortium of
developers known as the Open Handset Alliance and commer-
cially sponsored by Google. It was unveiled in November 2007,
with the first commercial Android device launched in September
2008.
It is free and open source software; its source code is known
as Android Open Source Project (AOSP), which is primarily
licensed under the Apache License. However most Android
devices ship with additional proprietary software pre-installed,
most notably Google Mobile Services (GMS) which includes
core apps such as Google Chrome, the digital distribution plat-
form Google Play and associated Google Play Services develop-
ment platform. About 70 percent of Android smartphones run
Google’s ecosystem; competing Android ecosystems and forks
include Fire OS (developed by Amazon) or LineageOS. How-
ever the ”Android” name and logo are trademarks of Google
which impose standards to restrict ”uncertified” devices outside
their ecosystem to use Android branding.
The source code has been used to develop variants of Android
on a range of other electronics, such as game consoles, digital
cameras, portable media players, PCs and others, each with a
specialized user interface. Some well known derivatives include

36
Android TV for televisions and Wear OS for wearables, both de-
veloped by Google. Software packages on Android, which use the
APK format, are generally distributed through proprietary ap-
plication stores like Google Play Store, Samsung Galaxy Store,
and Huawei AppGallery, or open source platforms like Aptoide
or F-Droid.
Android has been the best-selling OS worldwide on smart-
phones since 2011 and on tablets since 2013. As of May 2017, it
has over two billion monthly active users, the largest installed
base of any operating system, and as of January 2021, the
Google Play Store features over 3 million apps. The current
stable version is Android 11, released on September 8, 2020.

Specifications

Figure 4.18: Android 11 home screen with Pixel Launcher

37
ˆ Developer: Various (mostly Google and the Open Handset
Alliance)
ˆ Written in: Java (UI), C (core), C++ and others

ˆ OS family: Unix-like (Modified Linux kernel)

ˆ Working state: Current

ˆ Source model: Open source (most devices include propri-

etary components, such as Google Play)
ˆ Initial release: September 23, 2008; 12 years ago

ˆ Latest release: Android 11 / September 8, 2020; 5 months

ago
ˆ Repository: android.googlesource.com

ˆ Marketing target: Smartphones, tablet computers, smart

TVs (Android TV), Android Auto and smartwatches (Wear
OS)
ˆ Available in: 100+ languages

ˆ Update method: Over-the-air

ˆ Package manager: APK-based

ˆ Platforms: 64- and 32-bit (32-bit only apps being dropped

in 2021) ARM, x86 and x86-64, unofficial RISC-V support
Kernel type Linux kernel
ˆ Userland: Bionic libc, mksh shell, Toybox as core utilities
(beginning with Android 6.0)
ˆ Default user interface: Graphical (multi-touch)

ˆ License: Apache License 2.0 for userspace software GNU

GPL v2 for the Linux kernel modifications

38
ˆ Official website: www.android.com

39
Chapter 5

System Design

Systems design is the process of defining elements of a system

like modules, architecture, components and their interfaces and
data for a system based on the specified requirements. It is
the process of defining, developing and designing systems which
satisfies the specific needs and requirements of a business or
organization.
A systemic approach is required for a coherent and well-
running system. Bottom-Up or Top-Down approach is required
to take into account all related variables of the system. A de-
signer uses the modelling languages to express the information
and knowledge in a structure of system that is defined by a con-
sistent set of rules and definitions. The designs can be defined
in graphical or textual modelling languages.

5.1 Use Case Diagram

A use case diagram at its simplest is a representation of a user’s
interaction with the system that shows the relationship between
the user and the different use cases in which the user is involved.

40
 Figure 5.1: Use Case Diagram of the Developed System

5.2 Activity Diagram

An activity diagram is a behavioral diagram i.e. it depicts the
behavior of a system. An activity diagram portrays the control
flow from a start point to a finish point showing the various
decision paths that exist while the activity is being executed.

41
 Figure 5.2: Activity Diagram of the Developed System

5.3 Class Diagram

Class diagram describes the attributes and operations of a class
and also the constraints imposed on the system. The class dia-
grams are widely used in the modeling of objectoriented systems
because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.

42
 Figure 5.3: Class Diagram of the Developed System

5.4 Sequence Diagram

A sequence diagram is a type of interaction diagram because
it describes how—and in what order—a group of objects works
together. These diagrams are used by software developers and
business professionals to understand requirements for a new sys-
tem or to document an existing process.

Figure 5.4: Sequence Diagram of the Developed System

43
5.5 Block Diagram
A block diagram is a specialized, high-level flowchart used in
engineering. It is used to design new systems or to describe
and improve existing ones. Its structure provides a high-level
overview of major system components, key process participants,
and important working relationships.

Figure 5.5: Block Diagram of the Developed System

44
Chapter 6

Coding

6.1 Raspberry Pi 3 Code

from f i r e b a s e import f i r e b a s e

import RPi . GPIO as GPIO

import time
from time import s l e e p
import d a t e t i m e
import s e r i a l

s e r = s e r i a l . S e r i a l ( ” / dev / t t y S 0 ” , 9 6 0 0 , tim eout

= 4)

time . s l e e p ( 0 . 3 )
count = open ( ’ / home/ p i /num . txt ’ ) . r ea d ( )
i n d e x = i n t ( count )
p r i n t index

time . s l e e p ( 0 . 5 )
GPIO . setmode (GPIO .BCM)

45
f i r e b a s e= f i r e b a s e . F i r e b a s e A p p l i c a t i o n ( ’ h t t p s
: / / oh= f i s h =88d20= d e f a u l t =r t db . f i r e b a s e i o .
com / ’ )

w h i l e True :
now = d a t e t i m e . d a t e t i m e . now ( )
p r i n t now

received data = ( str ) ( ser . readline () )

print ( received data )

i f len ( received data ) > 10:

ard data = received data . s p l i t ( ’ , ’ )

temperature = f l o a t ( ard data [ 0 ] )

turbidity = f l o a t ( ard data [ 1 ] )
tds = int ( ard data [ 2 ] )
s a l i n i t y = f l o a t ( ard data [ 3 ] )
do = f l o a t ( a r d d a t a [ 4 ] )
ph = f l o a t ( a r d d a t a [ 5 ] )
i n d e x = i n d e x+1

p r i n t ( index )
p r i n t ( do )
p r i n t ( ph )
print ( salinity )
print ( tds )
p r i n t ( temperature )
p r i n t now
print ( turbidity )

46
with open ( ” / home/ p i /num . t x t ” , ”w” ) as
text file :
t e x t f i l e . w r i t e (”%d” %(i n d e x ) )

r e s u l t = f i r e b a s e . p o s t ( ’ / Oh Fish / ’ , { ’
index ’ : s t r ( i n d e x ) , ’ do ’ : s t r ( do ) , ’ ph
’ : s t r ( ph ) , ’ s a l i n i t y ’ : s t r ( s a l i n i t y )
, ’ tds ’ : s t r ( t d s ) , ’ temperature ’ : s t r
( t e m p e r a t u r e ) , ’ time ’ : s t r ( now ) , ’
t u r b i d i t y ’ : s t r ( t u r b i d i t y ) })
print ( result )

#f b . put ( ’ t e s t / a s d f ’ , ” count ” , 4 ) #”path

” , ” property Name ” , p r o p e r t y V a l u e

r e s u l t = f i r e b a s e . put ( ’ / Oh Index / ’ , ’
index ’ , s t r ( i n d e x ) )
print ( result )

r e s u l t = f i r e b a s e . put ( ’ / O h lr / ’ , ’
index ’ , s t r ( i n d e x ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’ do ’ ,
s t r ( do ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’ ph ’ ,
s t r ( ph ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h lr / ’ , ’
salinity ’ , str ( salinity ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’ tds
’ , s t r ( tds ) )

47
 print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’
temperature ’ , s t r ( t e m p e r a t u r e ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’ time
’ , s t r ( now ) )
print ( result )
r e s u l t = f i r e b a s e . put ( ’ / O h l r / ’ , ’
turbidity ’ , str ( turbidity ) )
print ( result )

time . s l e e p ( 3 0 )

6.2 Arduino Code

#i n c l u d e <OneWire . h>
#i n c l u d e <S o f t w a r e S e r i a l . h>
So ftw are Ser ial mySerial (8 ,9) ;

#i n c l u d e ”DFRobot EC . h”

#d e f i n e DO PIN A3
#d e f i n e TdsSensorPin A2
#d e f i n e VREF 5 . 0
#d e f i n e SCOUNT 30
i n t a n a l o g B u f f e r [SCOUNT ] ;
i n t analogBufferTemp [SCOUNT ] ;
i n t a n a l o g B u f f e r I n d e x = 0 , copyIndex = 0 ;
f l o a t averageVoltage = 0 , tdsValue = 0 ,
temperature = 25;

48
#d e f i n e EC PIN A4
f l o a t v o l t a g e , ecValue , e t e m p e r a t u r e = 2 5 ;
DFRobot EC e c ;

OneWire ds ( 1 0 ) ;
int led = 13;
byte i ;
byte p r e s e n t = 0 ;
byte t y p e s ;
byte data [ 1 2 ] ;
byte addr [ 8 ] ;
float celsius , fahrenheit ;
f l o a t ntu ;

#d e f i n e VREF 5000
#d e f i n e ADC RES 1024

void setup ( void )

{

S e r i a l . begin (9600) ;
mySerial . begin (9600) ;
pinMode ( l e d , OUTPUT) ;

ec . begin ( ) ;

pinMode ( TdsSensorPin , INPUT) ;

d i g i t a l W r i t e ( l e d , HIGH) ;
delay (700) ;
d i g i t a l W r i t e ( l e d , LOW) ;

49
 delay (700) ;
d i g i t a l W r i t e ( l e d , HIGH) ;
delay (700) ;
d i g i t a l W r i t e ( l e d , LOW) ;
delay (700) ;
//
S e r i a l . p r i n t l n (” Start . . . ”) ;
}

void loop ( void )

{
i n t ph = analogRead (A0) ;

i n t turb = analogRead (A1) ;

c e l s i u s = ( f l o a t ) raw / 1 6 . 0 ;
fahrenheit = c e l s i u s * 1.8 + 32.0;

i n t t u r b i d i t y = map( turb , 0 , 7 5 0 , 1 0 0 , 0 ) ;

t d s V a l u e =(133.42 * c o m p e n s a t i o n V o l a t g e *
compensationVolatge *
compensationVolatge = 255.86*
compensationVolatge *
compensationVolatge + 857.39*
compensationVolatge ) * 0 . 5 ;

Temperaturet = ( u i n t 8 t )READ TEMP;

ADC Raw = analogRead (DO PIN) ;
ADC Voltage = u i n t 3 2 t (VREF) * ADC Raw /
ADC RES ;

50
 v o l t a g e = analogRead ( EC PIN )
/1024.0*5000;
ecValue = e c . readEC ( v o l t a g e ,
etemperature ) ;

f l o a t fph = ( f l o a t ) c e l s i u s / 4 . 6 ;
i n t adox = analogRead ( 3 ) ;

i n t dox = map( adox , 0 , 8 0 0 , 2 0 , 0 ) ;

Serial . print ( celsius ) ;

Serial . print (” ,”) ;
Serial . print ( turbidity ) ;
Serial . print (” ,”) ;
Serial . p r i n t ( tdsValue , 0 ) ;
Serial . print (” ,”) ;
Serial . p r i n t ( ecValue , 2 ) ;
Serial . print (” ,”) ;
Serial . p r i n t ( dox ) ;
Serial . print (” ,”) ;
Serial . p r i n t l n ( fph ) ;

mySerial . print ( c e l s i u s ) ;
mySerial . print (” ,”) ;
mySerial . print ( t u r b i d i t y ) ;
mySerial . print (” ,”) ;
m y S e r i a l . p r i n t ( tdsValue , 0 ) ;
mySerial . print (” ,”) ;
m y S e r i a l . p r i n t ( ecValue , 2 ) ;
mySerial . print (” ,”) ;
m y S e r i a l . p r i n t ( dox ) ;
mySerial . print (” ,”) ;
m y S e r i a l . p r i n t l n ( fph ) ;

51
 delay (29000) ;

52
Chapter 7

Test Results

7.1 IoT Sensor System

The following model is designed and developed as a fully func-
tional unit. It has to be connected to a power source and a
Wi-Fi connection must also be established at time of usage.

Figure 7.1: IoT Sensor System

The following image is the probe part of the system contain-

ing sensor probes meant to be partially submerged in water to
take readings.

53
 Figure 7.2: IoT Sensor System Probe

7.2 Cloud Implementation

The data is successfully being read and uploaded into the Fire-
base cloud

Figure 7.3: Database Readings

54
7.3 Mobile Application
The application, named ”Oh Fish!”, interface is shown as fol-
lows.
First, download and install the mobile application. Open the
application and the home page is displayed.

Figure 7.4: Home Page of the Mobile Application ”Oh Fish!”

Tap on the ”Get Readings” button and the live readings

pulled from the database and will be displayed.

55
 Figure 7.5: Live Readings the IoT System Sensors are displayed

Tap on ”Choose Fish” button and select the fish that you
require to test the water for. Each fish has different optimal
parameters to which the application will display the conclusion
accordingly. For the sake of initial testing, we choose two fish
namely shrimp and salmon.

56
 Figure 7.6: ”Choose Fish” Selection Screen

The conclusions built will be displayed under ”Results:” and

provide feedback of the parameters being either ”too high”, ”too
low” or ”perfectly alright”.

57
 Figure 7.7: Results are displayed

Clicking ”Click for more information” button at the bottom

of the screen will lead to a second page where the user can view
a picture, description and the optimal range of the parameters
for each fish.
Else the user can click the ”Go back to Readings” button to
go back to the home page.

58
 Figure 7.8: About Fish page

Clicking ”About Parameters” button at the bottom of the

screen will lead to the third page where the user read about the
information of the parameters depicted and used.
Else the user can click the ”Go back to Readings” button to
go back to the home page or click on ”Go to fish info” and go
back to the second page.

59
Figure 7.9: About Parameters page

60
Chapter 8

Conclusion

The project ”IoT BASED SMART WATER QUALITY TEST-

ING SYSTEM FOR PISCICULTURE WITH MOBILE APPLI-
CATION” was designed such that to build a water quality test-
ing system which would give us the information about param-
eters and also upload these values into the Firebase cloud that
can be viewed on the application.
Integrating features of all the hardware components used have
been developed in it. Presence of every module has been cali-
brated and placed carefully, thus contributing to the best work-
ing of the unit. Using highly advanced IC’s with the help of
growing technology, the project has been successfully imple-
mented. Thus the project has been successfully designed and
tested.
We have successfully designed and implemented a water qual-
ity testing system for aquaculture based on IoT technology. The
system offers farmers the ability to monitor the most impor-
tant water quality parameters of their ponds for measuring dis-
solved oxygen (DO), pH, temperature, salinity, turbidity, total
dissolved solids (TDS) in real time. We also provide a front-end
application to show the readings and build conclusion based on
the cases. It is a simple and effective as well as reliable method
to reduce maintenance costs. This solution helps make it more

61
affordable for small-scale farmers in developing countries to ap-
ply hi-tech farming practices.

8.1 Future Scope

The present system can be further improved in a few ways:
ˆ By expanding the cloud service system as provided by Fire-
base
ˆ Implementation of machine learning algorithms on the dataset
acquired in the cloud and make analysis and predictions
ˆ Implementation of IoT system as sensor hubs and applying
edge computing
ˆ Improving the sensors by upgrading them into industrial
grade level sensors

62
Bibliography

[1] IoT Based Aquaculture

Publisher: International Research Journal of Engineering
and Technology (IRJET)
Published in: Volume: 07 Issue: 05 — May 2020
[2] eMatsya – An Innovative Data Acquisition System To Col-
lect Fish Catch Data From Reservoirs And Other Inland Wa-
ter Bodies
Publisher: IEEE INTERNATIONAL JOURNAL OF SCI-
ENTIFIC & TECHNOLOGY RESEARCH
Published in: VOLUME 8, ISSUE 12, DECEMBER 2019
[3] IoT for Aquaculture 4.0 Smart and easy-to-deploy real-time
water monitoring with IoT
Publisher: IEEE
Published in: 15 November 2018 2018 Global Internet of
Things Summit (GIoTS)

63