Full Text 02

Bachelor Thesis
Computer Science and Engineering, 300 credits
An implementation of a real-time water

quality monitoring IoT system with 4G
connectivity
Catfish - Data and Sensors
Computer Science and Engineering, 15

credits
Halmstad 2021-06-23
Ellen Nihl, Eek de Bruijckere
HALMSTAD
UNIVERSITY
Abstract
This report is about implementing an Internet of Things (IoT) system that is meant to measure
the water quality of the Nissan river located in Halmstad. The system measures the temperature,
pH value, turbidity, dissolved oxygen, total dissolved solids and electrical conductivity of the water.
The project is named Catfish, and the authors of the report are in the Data and Sensors team.
The purpose of the Data and Sensors team is to program the prototype to collect the specified
environmental values, combining all functionalities of the prototype in the main code, and sending
the data wirelessly to a database in real-time, including creating the database.
To collect the data, two ArduinoTM microcontrollers and sensors from DFRobot are used. For
the central computing, a Raspberry PiTM is used. To send the data in real-time, a 4G dongle is
connected to the Raspberry PiTM and to transmit the data, the protocol TCP/IP is used. In order
to create a local database, SQLite is used, and for the database server, MariaDB is used.
The project has succeeded to collect data from the specified sensors, send the data wirelessly
over the Internet with the help of a 4G modem, and store the data in a database on a remote
temporary server. However, the sensors are not calibrated due to lack of time, which means the
data received from the sensors can not be trusted. The server that stores the data is a temporary
server implemented by the Data and Sensors team since there was no other place to store the data.
Sammanfattning
Denna rapporten handlar om en implementation av ett Internet of Things (IoT) system som är
menad för att mäta vattenkvalitéen i Nissan i Halmstad. Systemet mäter temperaturen, pH värde,
grumlighet, upplöst syre, totalmängden upplösta ämnen och elektrisk konduktivitet i vattnet. Detta
projektet heter Catfish och författarna av denna rapport är del av Data och Sensor gruppen.
Syftet av Data och Sensor gruppen är att programmera prototypen till att samla de specifierade
miljövärdena, kombinera prototypens funktioner i huvud-koden och att skicka datan till en databas
trådlöst och i real-tid, vilket inkulderar att skapa databasen.
För att samla datan används två ArduinoTM mikrokontrollers och sensorer från DFRobot. För
den centrala datoranvändningen används en Raspberry PiTM . För att skicka data i realtid används
ett 4G modem som kopplas till Raspberry Pi:nTM och skickar datan till servern genom TCP/IP.
Skapandet av en lokal databas är gjord i SQLite och för databasen i servern används MariaDB.
Projektet har lyckats med att samla data från de specifierade sensorerna, skicka datan trådlöst
över Internetet med hjälp av ett 4G modem och lagra datan i en databas i en temporär fjärrserver.
Sensorerna är dock inte kalibrerade på grund av tidsbrist, vilket betyder att man inte kan lita på
datan från sensorerna. Servern där datan lagras är temporär och implementerad av Data och Sensor
gruppen eftersom det inte fanns någon annanstans att lagra datan.
i
Contents
1 Introduction 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Requirement Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background 5
2.1 Microcontrollers and microcomputers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Relational database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Non-relational database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Data communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Between microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Radio technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3 Internet access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Method 13
3.1 Implementation of data collection from the Cat and the Fish . . . . . . . . . . . . . 13
3.1.1 Choice of hardware and coding environment . . . . . . . . . . . . . . . . . . . 13
3.1.2 Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Code of the sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Data transfer to the main microcomputer . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Combination of main functionalities in the main microcomputer . . . . . . . . . . . . 18
3.3.1 Integration with the Control and Autonomy team and the Design and Man-
ufacturing team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Connection with the microcontrollers . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Collection of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.4 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.5 Local database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Data transfer to a database wirelessly in real-time . . . . . . . . . . . . . . . . . . . 21
3.4.1 Choice of modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Choice of software and protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.3 Client-server code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.4 Temporary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Implementation of databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Calibration and verification of the sensors . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.1 pH-sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.2 Turbidity-sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.3 Total Dissolved Solids-sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.4 Dissolved Oxygen-sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.5 Electrical Conductivity-sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Analysis of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ii
4 Results 32
5 Conclusions 34
5.1 Implementation of data collection from the Cat and the Fish . . . . . . . . . . . . . 34
5.1.1 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Data transfer from the Cat and the Fish to the main microcomputer . . . . . . . . . 35
5.3 Implementation of main functionalities in the main microcomputer together with the
Control and Autonomy team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 Data transfer to a database wirelessly in real-time . . . . . . . . . . . . . . . . . . . 36
5.4.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5 Implementation of databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Discussion 38
6.1 Limitations of our solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2 Next prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.1 Improvements of the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.2 Improvements of the data communication . . . . . . . . . . . . . . . . . . . . 39
6.2.3 Other improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendices 43
A Schematics 43
B Databases 45
C The finished prototype 53
iii
1 Introduction
Catfish is a project created by an innovation team in Halmstad University called Innovation Lab 1 .
The purpose of the project is to create a prototype, which consists of three devices, to measure
the environmental qualities in, above, and underwater, operating autonomously in real-time.
The first of the three devices, called the Cat, will float on the surface of the water. The second
device, named the Fish, can be submerged between 0 to approximately 5 meters in water. Lastly, the
third device, called the Bird, will work as a drone, hovering over the other devices. These devices
can go on a so-called mission. To create a mission, a user can select one or multiple locations
(waypoints) in a lake or river where the prototype autonomously heads to. The parts of a mission
include:
1. Heading to a waypoint.
2. Arriving at the waypoint and stabilising the motors.
3. Lowering the Fish.
4. Collecting data of the environmental qualities.
5. Hoisting the Fish.
6. Continuing to the next waypoint.
7. Sending data to a database on a remote server in real-time.
The database is to be connected to an application which displays the environmental values, see
Figure 1.
Figure 1: An overview of the Catfish project. The three devices collect data, and then the data is
sent and stored in a database (visualised as a cloud ), which an application receives to display.
1 run by Harvey Blanco and Alireza Esmaeilzadeh.
1
The parameters to be measured by the Cat are temperature, pH-value, turbidity, dissolved
oxygen, total dissolved solids, and electrical conductivity. The Fish will measure temperature,
turbidity, and dissolved oxygen. As described later in this section, the project has a team responsible
for the environmental aspects. Meaning, it is their responsibility to decide what values to measure
and interpret the results of the measurements with the help of their knowledge in chemistry.
The importance of monitoring the water quality can be motivated with the help of the 17 goals
of the UN. The Catfish project includes goal 6; Clean Water and Sanitation, and 14; Life Below
Water. Goal number 6 wants to ensure water access and sanitation for all, which is vital since
billions of human beings still have a huge lack of these resources [1]. Goal number 14 includes
conserving the oceans and is the most relevant goal for the Catfish project. The sea handles
important ecosystems and other essential global systems which are crucial for humankind. In order
to create a sustainable future, the sea must be kept free from pollution [2]. To have a device that
measures the water quality and can find potential sources of pollution in a body of water, these
goals could be helped to be achieved.
The current prototype (prototype 2.0) is made to be used in the Nissan river in Halmstad, with
the future goal to expand further and use Catfish in any body of water.
Since this is a big project, it has been divided into different teams, each team representing a
separate thesis:
• Design and Manufacturing - in charge of the design and production of the devices.
• Power and Motor - work with battery management and motor control.
• Control and Autonomy - makes the prototype autonomous by integrating motors and a
flight controller into the prototype.
• Environmental Analysis – in charge of researching environmental aspects and assisting the
Data and Sensors team by stating what to measure and the conclusions of the measurements.
• Interface – in charge of designing the application of this project, including developing a
conceptual Graphical User Interface (GUI) that displays the data.
• Data and Sensors - the authors’ part. This team is responsible for the real-time data
collection, data communication, and data storage of the project.
1.1 Purpose
The purpose of the Data and Sensors team is to program the prototype to collect the specified
environmental values, combining all parts of a mission in the main code, and sending the data
wirelessly to a database in real-time, including creating the database.
The main focus for the Data and Sensors team is to make the prototype an Internet of Things
(IoT) device, meaning that the focus is on communication over the Internet and the storage of the
data. See Figure 2 for a simple overview of the project.
2
Figure 2: An overview of the Data and Sensors team’s purpose.
1.2 Limitations
An important part to mention is that the prototype solely focuses on the Cat and the Fish, excluding
the Bird from this thesis, due to the time constraint. Instead, this will be implemented in the next
prototype.
1.3 Requirement Specification

The heads of Innovation Lab set the specifications of the project as a whole. The specifications of
the Data and Sensors team are set by the aforementioned team themselves.
The teams shall also take into account to divide the prototype into modules.
These are the specifications set for the Data and Sensors team:
• Implementing data collection from the Cat and the Fish, including the calibration of the
sensors.
• Sending the collected data from the Cat and Fish to the main microcomputer located in the
Cat.
• Combining the functions of a mission in the main microcomputer with the Control and Au-
tonomy team and Design and Manufacturing team.
3
• Sending the collected data and additional data (received from Control and Autonomy team)
to a database wirelessly in real-time.
• Implementing a database that stores the collected data.
4
2 Background
The Catfish prototype works as an Internet of Things (IoT) device. It collects values from sensors
autonomously in real-time and stores this data on a database on a remote server, through connection
to the Internet, see Figure 2.
IoT refers to the network of objects (or ”things”) that consists of embedded systems with sensors,
software, and other hardware, that enables interaction with humans and communication with other
devices via a connection to the Internet [3]. With the growth of IoT systems, the amount of data
gets richer, which means that the insight of what is monitored is deepened. Analysis of this data
can optimise and identify the performance of the system in question. Meaning, various businesses
can benefit highly from IoT systems [4].
A word that is commonly used in this context is cloud. When saying that something is stored
on the cloud, it means that it is stored on a server that is accessible through the Internet. When
it comes to IoT systems, it is often discussed about Cloud computing, Edge Computing, and Fog
Computing. These refer to different ways to handle large amounts of data, mainly, where to process
this data. Cloud computing means that the data is processed on the cloud (remote servers), not
on any local storage of the system [5]. Edge computing refers to the data being processed locally,
then sent to the cloud, meaning that the cloud has no processing to do, improving response time
(in other words, decreasing latency) for the cloud. Fog computing implies that some parts of the
data are processed locally, where the servers are also decentralised, meaning that some of the data
can be accessed offline [6, 7].
In the case of the Catfish project, the prototype does not handle any significant amounts of
data. However, the data can either be processed locally in the embedded system, which can count
as Edge computing, or on the server on the mainland, which would be Cloud computing.
The concept of creating a real-time water quality monitoring system similar to the Catfish
project has been done before. One example of such systems connects sensors to a microcontroller
which analyses the data and then sends the data via radio transmitter and receiver modules [8].
It differs much from the Catfish prototype, both in what values to measure and how they are
measured. Also, the system in question does not have a connection to the Internet.
Unlike the last example, a similar system to Catfish exists, but with access to the Internet.
It is an IoT system that measures environmental qualities (solar) with the help of an ArduinoTM
microcontroller, which is connected to the Internet using 3G [9].
Another example of an IoT system that measures environmental qualities is a weather tracking
system, controlled by a Raspberry PiTM , that uses the MQTT protocol to transport messages [10].
To conclude, this project has high potential, and most importantly, is relevant to today’s tech-
nology.
2.1 Microcontrollers and microcomputers

This part of the project corresponds to the ”Embedded system” circle in Figure 2. An embedded
system is defined as a computer system that consists of a central processing unit (CPU), memory,
Input/Output (I/O) peripherals, and other electrical devices, which performs information process-
ing [11]. There can not be an IoT device without an embedded system. A way to get these
functionalities is by coding a microcontroller, which consists of one or more CPUs, memory, and
I/O peripherals, connecting necessary sensors to it and processing the information given.
5
This section will go through some options in microcontrollers and microcomputers, coding en-
vironments, and coding languages.
There is a wide array of microcontrollers to choose from, where Arduino TM microcontrollers
are one of the most common ones to use for general projects [12]. The Arduino Mega 2560 REV3
is based on the ATMega microcontroller from MicrochipTM . It has 54 digital I/O pins, 16 analog
inputs, 256KB Flash memory, 8KB RAM, 4KB electrically erasable programmable read-only mem-
ory (EEPROM), a Universal Serial Bus (USB) connection, four serial ports, and can supply 3.3V
or 5V to its I/O pins [13].
The most popular microcontroller in the ArduinoTM family is the Arduino UNO [14]. This
microcontroller is much smaller compared to the Arduino Mega, both in physical size and memory
capacity. It has 14 digital I/O pins, 6 analog inputs, 32KB Flash memory, 2KB Static RAM
(SRAM), 1KB of EEPROM memory, a USB connection, one serial port, and can supply 3.3V or
5V to its I/O pins [15].
ArduinoTM is known for providing free, open-source software for everyone. They have their
own Integrated Development Environment (IDE) called Arduino IDE, which is accessible for free.
This IDE is most commonly used when writing in their own programming language, which is a
mix between C and C++ [16]. For pure C programming on ArduinoTM microcontrollers, then IAR
Workbench could be an option [17].
Another way to create an embedded system is by using a microcomputer. The difference between
a microcontroller and a microcomputer is that a microcomputer works like a regular computer,
which is supposed to run an Operating System (OS), but with the smallest parts possible. Also, they
usually have common peripherals such as USB and Ethernet [18]. The most common microcomputer
is the Raspberry Pi TM , most commonly run with the Raspberry Pi OS, accessible through their
website for free. Pre-installed on the OS is the Thonny IDE, where Python programs can be written
[19].
2.2 Sensors
In order to enable data collection of the specified values, sensors are needed. The sensors shall be
connected with microcontrollers in order to manipulate them. This section refers to the ”Sensors”
box in Figure 2.
Since the Data and Sensors team does not have the necessary knowledge about biology and
chemistry, it is up to the Environmental Analysis team to decide what to measure in the water.
Through their research and input from the rest of the teams, it is decided to use the following
sensors:
• Temperature sensor DS18B20 [20]
• pH sensor SKU: SEN0161 [21]

• Turbidity sensor SKU: SEN0189 [22]
• Total Dissolved Solids (TDS) sensor SKU: SEN0244 [23]
• Dissolved Oxygen (DO) sensor SKU:SEN0237-A [24]

• Electrical Conductivity (EC) sensor SKU:DFR0300-H [25]
6
See Table 1 for specifications for these sensors.
Most significant sensor specifications

Sensor Unit Range Accuracy Response Temp. Probe life Verification
time range
◦
Temperature C −10◦ C − ±0.5◦ C < 750ms −55◦ C− Not speci- No.
◦
85 C 125◦ C fied.
pH pH 0pH − ±0.1pH ≤ 1min 0◦ C − Not speci- Yes. Be-
14pH 60◦ C fied. fore every
mission.
Dissolved mg/L 0mg/L − Not 90 sec 0◦ C − Electrode: Yes. Be-
Oxygen 20mg/L speci- 40◦ C 1 year, fore every
fied. Cap: 1-2 mission.
months
Turbidity NTU 0N T U − Not < 500ms 5◦ C − Not speci- Yes. Be-
3000N T U speci- 90◦ C fied. fore every
fied. mission.
Total Dis- ppm 0ppm − ±10% Not spec- Not Not speci- Yes. Be-
solved 1000ppm ified. specified. fore every
Solids fied. mission.
Electrical ms/cm 10ms/cm− ±5% Not spec- 0◦ C − > 0.5year Yes. Be-
Conductiv- 100ms/cm ified. 40◦ C fore every
ity mission.
Table 1: For further information visit the DFRobot website [26]. See section 3.6 for calibration
and verification specifications.
2.3 Database
This part of the thesis explains the top of Figure 2, ”Database on a server”. A database is
an organised collection of data usually stored electronically in a computer. Databases are very
commonly used for data storage. In schools, databases are used to store student names and what
classes they attend. In factories, data about production speed and quality is stored. Other places
that use databases are banks, game companies, manufacturers, etc. [27].
2.3.1 Relational database

A relational database is a model for storing data in relation to one another. The main structure of
the relational database is tables, which store the data. To create relations between tables, keys are
used. The Foreign key (FK) is used to establish the relationships between tables, and the Primary
key (PK) uniquely identifies rows of data inside tables (see Figure 3). To retrieve, update, and
manage how the information is organised and optimised, a Relational Database Management System
(RDBMS) is needed. The RDBMS acts as an interface between the database and the end product.
Structured query language (SQL) is the basis of all the different RDBMS. In this thesis, MariaDB,
SQLite and SQL Server Management System (SSMS) are considered [28–30].
7
MariaDB is a community-developed, commercially supported RDBMS, intended to remain free
and open-source under the General Public License [28].
SQLite is a unique DBMS that does not require a server to run. Instead, data is stored on
ordinary disk files. This makes SQLite popular to use as a file format. The code for SQLite is in
the public domain and is thus free to use for any purpose, commercial or private [29].
SQL Server Management Studio (SSMS) is a software application used for configuring, manag-
ing, and administering all components within MicrosoftTM SQL Server. Visual Studios and SSMS
are very compatible. The developer can, for example, create a database and auto-generate code in
Visual Studios [30, 31].
Relational databases exceed in structured data, i.e. data that does not change structure-wise.
Figure 3: The bookID and authorID are primary keys (PK) that uniquely identifies each row of the
tables. The authorID in the table Book is a foreign key that connects the tables together.
2.3.2 Non-relational database

NoSQL is another type of database that is increasing in popularity. NoSQL has two different
meanings. Some say that it stands for ”non SQL” while others say ”not only SQL”. Either way,
most agree that a NoSQL is a database that does not use relational tables [32].
There are many types of NoSQL databases. The one that was considered is a Document database.
The data is stored in documents in a similar manner as JSON (JavaScript Object Notation) files.
An example of a document database is seen in Figure 4. This type of database excels in storing
unorganised data. A document database is often used when the user collects a large amount of data
and does not rely on the specifics. NoSQL databases are also good at expanding to more than one
server. This is because there are no relations; the user can store it where there is space [32].
Figure 4: An example of a document database.
8
2.4 Data communication
For embedded systems, especially for IoT systems, data communication is a must. In order to
collect and store data, devices need to be able to communicate with each other.
This section will go through common protocols, how to achieve access to the Internet for em-
bedded systems, and the theory behind these parts. This part of the system corresponds to the
arrows that connect the boxes in Figure 2. There will be data communication via cables within
the embedded system and wireless communication from the embedded system to a server.
2.4.1 Between microcontrollers

Data communication can happen wirelessly or via wires. Examples of data communication protocols
via cables are Ethernet, the most common one to use in Local Area Networks (LANs), and the
USART (Universal Synchronous and Asynchronous Reception and Transmission) protocol, for serial
communication. Serial communication is the process of sending data bit-wise, through either a
channel or a bus [33].
When it comes to data communication between microcontrollers, serial communication via USB
(which stands for Universal Serial Bus) cables are the most convenient and common way to do
it. Many of Arduino’sTM microcontrollers already have that implemented [13], and for Raspberry
Pi’sTM , it is easy to implement in Python using pyserial 2 .
2.4.2 Radio technology

Since this report is about the creation of an IoT device, Internet access is needed. However, in
order to understand how to achieve Internet access, an overview of radio frequency (RF) modules
is needed.
A RF module consists of a RF transmitter and a RF receiver. The RF transmitter first needs
power and an oscillator to create an electrical wave which will be the baseline of the communication.
A modulator will then add the data to this wave by changing the amplitude or the frequency. An
increase in amplitude makes the wave bigger, and an increase in frequency means narrower waves.
The amplifier amplifies the modulated wave to increase its power, and therefore, the wave has more
range. Finally, an antenna converts the amplified wave to a radio wave and sends the data through
the air. See Figure 5.
The receiver begins with the antenna, receiving the radio wave and converting it to a signal. It
will then amplify the signals received from the antenna. A tuner will then discard all the frequencies
that are not interesting and keep the one that the transmitter is using. A demodulator will then
get the tuned signal and extract the data from the frequency and amplitude changes set by the
modulator [34].
There are many different RF modules with different ranges, power needs, and transmission
speeds. Some examples of modules are the HC-12 with long-range, low energy usage, and low
transmission speed [35], LoRa that has long-range transmission, variable energy usage depending
on message length [36], and the NRF24 with medium-range transmission, low energy usage, and
high transmission speed [37].
An example of RF modules usage is in an automated electricity meter, where all the aspects
of this module have been used as a greenhouse environmental monitoring system, where they have
used many modules to create a network of nodes [38, 39].
2 https://github.com/pyserial/pyserial/
9
Figure 5: An explanation for radio frequency transmitter and receiver.
However, as mentioned before, using RF technology with solely a transmitter and a receiver
would not make the prototype an IoT device. To make that possible, access to the Internet is
needed, and in this case, wireless Internet access.
2.4.3 Internet access

Related to previously mentioned radio frequency modules, a way to access the Internet wirelessly
is to transmit data via radio waves. This can be done in many ways; one example is through WiFi
technology. Suppose a device is connected to a Local Area Network (LAN), for example, to a router
via WiFi. In that case, it can transmit its data via radio waves, following the WiFi protocol, for
the router to receive. The data is then transferred from the router to its destination through either
cables or radio [40]. In order to make use of WiFi technology in an IoT device, the device must
be in the range of a router to work. Meaning, if the device in question will travel along a river,
another solution is needed. The solution could be Mobile Broadband technology.
Mobile broadband technology refers to high-speed wireless access to the Internet through a
mobile device (smartphone, tablet, etc.), modem, or similar, transmitting the data via radio waves.
The most used generation of mobile broadband technology is the third and fourth generation (3G
and 4G), where 5G is on the rise. These later generations of mobile broadband technology are very
supportive of integration of Internet Protocol (IP)-systems [41].
A modem is short for modulator-demodulator, which is a type of hardware that can translate
digital information into analog radio waves, and the other way around [42], meaning that it also
works as a transmitter and a receiver at the same time (see Section 2.4.2 Radio technology).
For example, suppose an embedded system wants to send data over the Internet through a mobile
broadband modem. In that case, it converts the digital signal received from the computer into
analog radio waves that it transmits (see the left half of Figure 6), to be received by a radio tower.
The radio tower continues to send the data to its desired destination (described as ”Endpoint”
and visualised as a server, in Figure 6) via other radio towers and other parts of the Wide Area
Network (WAN) (see ”WAN” in Figure 6). Simply put, a modem and a radio tower both work as
radio transmitters and receivers, who can easily communicate with each other.
10
Figure 6: A system that sends data through an embedded system through Mobile Broadband
technology and a modem, achieving the Internet access.
In mobile broadband technology, 3G and 4G is the most relevant choices to look into when
deciding how to achieve access to the Internet on an embedded system, see Table 2. The comparison
is important because depending on what kind of embedded system it is, a broad frequency spectrum
might have a higher priority than the data transmission speed.
It is known to be possible to achieve access to the Internet using 3G on a system that measures
climate-related values in real-time, in this case, solar parameters [9]. It is even done similarly to
the previously mentioned solar monitoring system in another example, with the only significant
difference being the usage of 4G instead [43].
3G vs 4G
Broadband Freq. Band Freq. Spectrum Maximum Speed
3G 1800 Mhz to 2500 15 Mhz to 20 Mhz 2 Mbps
Mhz
4G 2000 Mhz to 8000 5 Mhz to 20 Mhz 100 Mbps
Mhz
Table 2: Comparison between relevant technical specifications between 3G and 4G [44]. Freq. stands
for frequency.
In general, 4G consumes more battery power than 3G due to its high data movement and
processing, and the usage of higher frequencies. 4G is also significantly faster.
11
The lower the frequency band, the better the range. It is clear that 3G has the lowest value of
frequency range. However, 4G is significantly broader. Also, the lowest value of 4G is very close to
3G’s range [44].
2.4.4 Protocols
TCP/IP stands for Transmission Control Protocol/Internet Protocol and is the most common
protocol for sending data over the Internet. Usually, TCP/IP is used between two devices, typically
following the client/server model. The client/server model refers to the structure of one device
asking the other device for services. The device or devices that ask for services are called the
client(s), while the device that provides the service is called a server. For example, a web server
serves web pages [45].
TCP/IP takes care of the transmission of data with the help of Internet Protocol-addresses
(IP-addresses). Every device with a connection to the Internet has an IP-address, and works as an
identifier for the device. If the destination and the starting point of a data transfer, which follows
the Internet Protocol, are not part of the same network, it will still find its way to the destination
by going through different networks. This process is called routing [45]. This is what is happening
in Figure 6, from the modem, through the WAN, and to the server.
The HyperText Transfer Protocol (HTTP) can work as a part of the TCP/IP protocol, meaning
that HTTP clients use TCP/IP when connecting to an HTTP server (in other words, a website).
It is the basis of communication for the World Wide Web and can be an excellent protocol to use
if the programmer wants to send data to a website [45].
2.5 Server
As previously mentioned, a server is used to provide functionalities for other programs or devices
(clients). This architecture is called client/server model [46], which is described in Section 2.4.4
Protocols. Servers are optimised for a specific task and are better than the client’s computer at
the task in many cases.
Many server types provide different services. The server type that is used in this project is a
database server [47], see Figure 2 at the top, ”Database on a server”. The primary responsibility
of a database server is to store and retrieve data. Also, the database server needs to take care of
user management and security, so that just the authorised people gain access to the data. The
server also needs optimisation so the client can retrieve the data faster.
An option for this thesis is to create a server. Should there be a need to handle confidential
data, a better option would be to rent a server, offering better protection.
This project cooperates with Halmstad University. Since the university host servers, using one
of them could also be an option.
12
3 Method
The hardware needed for the Data and Sensors team is funded by Innovation Lab, which includes
microcontrollers and microcomputers needed, the sensors from Section 2.2 Sensors, and other
hardware and electronic parts (cables, resistors etc.). The programs that are free to use are Arduino
IDE, Thonny, SQLite and MariaDB.
The coding explained in this section can be found on the Catfish Github repository3 .
Figure 7: An overview of the Data and Sensors team’s purpose of the Catfish project.
3.1 Implementation of data collection from the Cat and the Fish
This part of the project is explained at the bottom of Figure 7, the connection between the sensors
and the ArduinoTM microcontrollers.
3.1.1 Choice of hardware and coding environment

For the programming of the sensors in the Cat, an Arduino Mega 2560 REV3 is chosen, since the
sensors are compatible with ArduinoTM . Also, many projects have already been done using these
3 https://github.com/Aloksirf/Catfish.git
13
sensors together with ArduinoTM microcontrollers [26]. The choice of the microcontroller is also
motivated by its high number of digital pins (54 pins) [13] which is crucial since there is a high
number of sensors to be connected to them, and the possibility to implement more sensors is taken
into account.
The main microcomputer, also placed in the Cat, is chosen by both the Data and Sensors team
and the Control and Autonomy team, since they are also responsible for it. From the Data and
Sensors team’s perspective, the criteria of a microcomputer are that a database can be created on
it, it can interact with the other devices, and have USB ports for the Internet modem and the
microcontrollers. It is chosen to be a Raspberry Pi model 4B. The language of the main code in the
Raspberry PiTM microcomputer is Python. Through communication within the Data and Sensors
team and the Control and Autonomy team, it is decided that it is important to separate the tasks
onto several microcontrollers in order to enable the possibility to have every system run in parallel.
Also, using multiple microcontrollers is important regarding the modular design.
It is also decided to have a second microcontroller that handles the sensors of the Fish, primarily
because of the modular design requirement and division of processing power, but also to facilitate
for the Design and Manufacturing team with the winch-system.
The winch-system is the system that lowers and raises the Fish from 5 meters underwater to
being directly under the Cat. The winch-system is discussed deeply in the Design and Manufacturing
team’s report [48].
When adding the second microcontroller in the Fish, only a USB cable connects the Cat and the
Fish. The USB cable both powers and sends data between the microcontrollers, and the cables of
the sensors are connected to the microcontroller of the Fish. In contrast to the previously mentioned
case, having only one microcontroller for the data collection of both the Cat and the Fish, all of the
cables of the sensors of the Fish would have to be taken into account in the winch-system, which
are three cables per sensor (5V, GND, and data).
Another positive point to this arrangement is that adding additional sensors or other components
to the system in future prototypes could be done without upgrading the microcontrollers.
This microcontroller is chosen to be an Arduino UNO because it was already accessible in the
Innovation Lab, since it was used for the former prototype. Also, the fact that this microcontroller
is physically small is an advantage from the Design and Manufacturing team’s perspective, since
the space in the Fish is small [48].
The coding of the sensors is done using open-source libraries that are developed for those exact
sensors, which are acquirable through the web page of the sensors [26]. The coding of the sensors
is done in Arduino’sTM language in their own environment Arduino IDE, since that is the language
of the open-source libraries.
To get the values from the water, the sensors mentioned in Section 2.2 Sensors are used.
While the Environmental Analysis team decides what to measure, the rest of the teams takes the
following things into account: the price, availability, fitting on the Catfish, and compatibility with
ArduinoTM microcontrollers. All of the sensors come from the same distributor, DFRobot, they
are small enough to fit on the prototype, and they are compatible with the chosen microcontrollers
[26].
3.1.2 Assembly
For the physical assembly of this part, cables are connected to the sensors and microcontrollers
according to the data-sheets of the sensors [20–25], where all of the analog sensors (which includes
14
every sensor except for the temperature sensor) only require three cables to be connected: power
(5V), ground (GND), and a data cable. The only digital sensor, the temperature sensor, is connected
the same way except for the 4.7Ω resistor connected between the power and the data cable [20], see
Appendix A. The cables in question are soldered by the Data and Sensors team.
3.1.3 Code of the sensors

While the codes that manipulate the sensors are received from the open-source libraries [26], the
overall structure of collection and choice of sensors is implemented by the Data and Sensors team
accordingly.
The code of the sensors is structured so that a number corresponds to a sensor, so that the mi-
crocomputer can specify what value it wants through the serial port, and receive the corresponding
sensor’s value. For example, if it receives the value ’1’, it measures the temperature. As seen in
Figures 8 and 9, the code starts by polling for a value from the serial port, which is where the
microcomputer is connected, then the code returns the value that is wanted. However, there is a
special case. Suppose the microcomputer sends the character ’H’ to one of the microcontrollers. In
that case, the microcontroller will send an identification character back (see the right-most box in
Figures 8 and 9), the Cat will send the character ’C’ back, which stands for ”Cat”, and the Fish
will send an ’F’ back, which stands for ”Fish”. Why the ArduinoTM microcontrollers must identify
themselves is explained later in Section 3.3.2 Connection with the microcontrollers.
This structure makes it simple to identify errors of a single sensor, e.g. if a sensor malfunctions.
The microcomputer can ask for another measurement right away, and if the sensor still malfunctions,
it can go on to the next sensor.
The codes of the Cat and Fish are very similar, with the only difference being the number of
sensors.
To make sure that the sensors are giving us the correct values, they need to be verified often
and calibrated occasionally (see Section 3.6 Calibration and verification of the sensors).
15
Figure 8: An overview of the code on the Arduino Mega.
16
Figure 9: An overview of the code on the Arduino UNO.
3.2 Data transfer to the main microcomputer

This part of the thesis corresponds to the connections between the ArduinoTM microcontrollers and
Raspberry PiTM microcomputer in Figure 7. For the communication between the Arduino Mega
in the Cat to the Raspberry Pi model 4B, serial communication is used, which follows the USART
protocol. The baud rate is set to 9600 bps (bits per seconds) in the code.
The main microcomputer, the Raspberry Pi model 4B, works as the central part of the embedded
system. It takes care of the main functionalities and has a connection to the other parts of the
prototype. This includes the ArduinoTM microcontrollers, the servo motor which controls the winch-
system, specified by the Design and Manufacturing team [48], and the PixhawkTM -flight controller,
specified by the Control and Autonomy team [49].
The Cat and the Fish data are sent to the main microcomputer through serial communication
using USB cables. There is one USB cable per ArduinoTM microcontroller, where they take up two
of the four ports on the Raspberry Pi model 4B [19]. The USB cable takes care of the power and
the data transmission all by itself. The other option would be to use four PIO pins (Vcc, GND,
and two data pins) necessary from the ArduinoTM microcontroller [13, 15] and four corresponding
GPIO pins on the Raspberry PiTM microcomputer [19] to have the same result, which is decided
to be unnecessary when simpler options exist.
17
Additional data from the Control and Autonomy team are also meant to be sent to the main
microcomputer from the flight controller: a waypoint location. The location is a vital part of the
Data and Sensors team, because the location is a primary key for one of the tables in the main
database. At the moment, only dummy-values are collected instead of the real locations. It is
beyond this thesis to implement the communication and collection of the location. See the Control
and Autonomy report for information about the communication between the PixhawkTM flight
controller and Raspberry Pi TM microcomputer [49].
3.3 Combination of main functionalities in the main microcomputer

This section explains the whole process of the main microcomputer’s code.
The integration of every part explained in this section is implemented according to Figure 10,
which is a logical schematic of how the code works on the Raspberry Pi model 4B, located in the
Cat, written in the IDE Thonny, coded in Python.
3.3.1 Integration with the Control and Autonomy team and the Design and Manu-
facturing team
The logical box ”Have we arrived at the waypoint and is the Fish down?” (Figure 10) polls for an
input from the PixhawkTM -flight controller together with the servo motor to tell the main micro-
computer that the prototype has arrived at the specified waypoint and the servo motor has placed
the Fish the specified meters down underwater. The actual integration of these parts is not done
by the Data and Sensors team. The integration of the servo motor with the main microcontroller
is done by the Design and Manufacturing team [48], and the flight controller integration is done by
the Control and Autonomy team [49]. The ”Tell the Pixhawk that the collection of data succeeded
and to proceed with the mission” and the ”Tell the Pixhawk that the collection of data failed and to
abort the mission” boxes on Figure 10 are up for the Control and Autonomy team to implement
also [49]. Every other box is implemented by the Data and Sensors team.
3.3.2 Connection with the microcontrollers

When the previously mentioned logical box succeeds, i.e. the prototype has arrived at the waypoint,
and the Fish is down, the code continues to ”Do we have connection with the Arduinos?” (Figure
10, box 2), which is closely described in Figure 11. This code is necessary because, firstly, it
enables the ability to connect with the microcontrollers and communicate with them through serial
communication. Secondly, when the microcontrollers disconnect with the main microcomputer,
there is a chance that the ports reinitialise, meaning, the ports’ names can change. The micro-
controller of the Fish can be on port one and the microcontroller of the Cat on port two, with
corresponding names to the port, but when it disconnects, these names change places. This means
that the code thinks it reads values from the Cat when in reality, it reads from the Fish, which
results in errors in the code when inserting the values in the database. In order to prevent this
from happening, the ”Do we have connection with the Arduinos?” logical box will read one port
at a time, then send an ’H’ through serial communication to the microcontroller at the port and
either receive an ’F’ if it is the Fish that responds, or a ’C’ if it is the Cat (Figure 11, boxes 3-6.).
Then, set the Cat and the Fish accordingly in the code (Figure 11, the two boxes in the bottom
before the ”END” box.).
18
3.3.3 Collection of data
If ”Do we have connection with the Arduinos?” succeeds, the code continues to ”Collect data + calc
mode/mean”, which is the process of trying to collect the values from the sensors via the ArduinoTM
microcontrollers, and calculation of the mode and mean value. If the collection of data fails, it will
break the collection of data, reset all the values from the sensors, disconnect, and go back to ”Do we
have connection with the Arduinos?”, as seen in Figure 10, following the arrow that says ”FAIL”
from the ”Collect data + calc mode/mean” box.
3.3.4 Calculations
In the context of IoT, this system could be counted as a system that includes Edge computing
(explained in Section 2.4 Data communication). The data from the sensors are processed
locally in the embedded system. When measuring from the sensors, the program reads six times.
With these six values from each parameter, a calculation is done. For more accurate results, more
than six sets of data would be needed. However, this prototype is not that advanced, so this is a
basic implementation of what could be implemented better in a future prototype.
The question is how the calculations should be done. It is discussed to choose between calculating
the mean, median, or mode value of the raw data from the sensors. It is known that the sensors need
some time to stabilise their value, see column ”Response time” on Table 1. Meaning the sensors
might give inaccurate values in the beginning. Especially the temperature sensor. Through testing,
it is seen that the temperature sensor always returns the value of 85 as the first measurement for
unknown reasons. Meaning, this has to be taken into account when measuring. The idea is that
a sensor should collect a large number of values, and theoretically, if the sensor is at the same
place during the measurements, it should stabilise, meaning that value should reappear many times
during the measurements (with two decimals taken into account). See Table 3 for a comparison
of the calculation types with the same dataset, which is based on a likely temperature dataset.
Mean vs. Median vs. Mode

Calculation Dataset Result
type
Mean [85.0, 21.0, 21.1, 21.1, 21.0, 21.1] 31.7
Median [21.0, 21.0, 21.1, 21.1, 21.1, 85.0] 21.1
Mode [85.0, 21.0, 21.1, 21.1, 21.0, 21.1] 21.1
Table 3: Comparison between mean, median and mode on the same dataset.
The mean value is the sum of the values divided by the total number of values, in this case:
85.0 + 21.0 + 21.1 + 21.1 + 21.0 + 21.1
≈ 31.7
6
which is not an accurate description of the temperature, which means that mean value is not used.
The median value is the value in the middle of the list, where the list is sorted by size. Which
in this case is two samples of the value 21.1, which is then calculated to be 21.1 due to the mean
value of these two, which in this case is an accurate description of the temperature value.
19
The mode value is the value that appears most frequently in the dataset, which in this case is
21.1. This is also an accurate description of the temperature.
With the sensors’ needs for time to stabilise for correct measurements taken into account, the
most frequent value is probably the most accurate value of the dataset. Especially if a wrong value
is achieved, it will not bother calculating the mode value as long as it does not happen many times.
If that were to happen many times, there would probably be something wrong with the hardware
of the sensors that no amount of mathematics can save.
If it does not exist at least two of the same value, it is decided to calculate the median value
instead, since that is the second-best alternative of showing accurate values based on this case.
Calculation of the mode and median value is implemented by importing the python library
statistics 4 .
3.3.5 Local database

If the previously mentioned part of the code, ”Collect data + calc mode/mean”, succeeds, it con-
tinues to insert the calculated values into the local database. First, a cursor is created to execute
queries in the database. To add the data, an INSERT query is executed. The data is stored in
dictionaries with the table name as the key, facilitating the query. For more information about the
databases, see Section 3.5 Implementation of databases.
4 https://github.com/python/cpython/blob/master/Lib/statistics.py
20
Figure 10: An overview of the main code on the microcomputer.
3.4 Data transfer to a database wirelessly in real-time

This section refers to the part of Figure 7, from the Raspberry PiTM microcomputer, and the rest
of the way upwards: ”Modem”, ”4G”, ”Internet Connectivity”, ”TCP/IP”, and ”Main Database
21
on a Server”. Code-wise, this section refers to the box ”Send data to server” in Figure 10.
3.4.1 Choice of modem

The most significant difference between 3G and 4G is the speed, see Table 2. High speed is not
a huge priority for this prototype. What is important is to have all of the data sent with no loss.
However, having high speed gives the prototype a higher quality and better appeal.
As mentioned in Section 2.4.3 Internet access, 4G uses more battery compared to 3G.
However, this difference is not crucial for this prototype, as the battery is well powered according
to the Control and Autonomy team [50].
Another aspect to consider is that 5G is on the rise, meaning 3G is not far from being classified
as an old technology, which could mean that 3G would not be considered a long-term solution for
the Catfish project.
With all of this said, 4G is the better option. A Huawei 4G Dongle E3372 USB modem is
chosen, alongside with a COMVIQ SIM-card. According to Tele2’s (who are well-known Internet
Service Providers (ISP)) website, they have the same coverage as them, and Tele2’s 4G coverage
over Nissan river is great [51]. The modem can reach up to 150 Mbps and is attachable with USB
which can be attached to the Raspberry Pi model 4B.
3.4.2 Choice of software and protocol

The software that is implemented in Python for data transferring over the Internet is called socket 5 ,
which is the endpoint for sending and receiving data over the Internet. The modem provides an
Internet connection. In the initialisation of the socket, TCP/IP is chosen, and the IP-address and
the corresponding port of the server is inserted.
As previously mentioned, mobile broadband technology supports the Internet Protocol (IP),
which means that the way the modem knows where to send the data is through IP-addresses, see
Section 3.4.4 Temporary server for more information about accessing the server.
3.4.3 Client-server code

There are two codes for the client-server connection: one in the client and one in the server.
The client code in the Catfish is seen in Figure 12 on the left side. First, it queries the non-sent
view in the local database. The non-sent view gathers all the non-sent data to a two-dimensional
array. This array contains all data needed to be sent to the server. The first dimension is all the
values in a row, and the second is all the rows that have not been sent. If there are values that
have not been sent, the program tries to connect to the server.
If there is no connection, it will return a message ”server not reachable” to the main program.
If the connection to the server succeeds, the data is sent to the server. The sending starts by
taking the first row, converting it to bytes, and sending the list to the server. When it receives
a confirmation from the server, it changes the state of the row in the local database to a ”1” in
the ”sent” column, meaning it has been sent. After this, the program is done and returns ”False”,
which means that there is no more data to send.
The code in the server is quite simple; in Figure 12 on the right side, there is an explanation
of the code. First, it creates a socket and starts waiting for a client to connect to the socket. When
a connection is established, it expects some data from the client in the form of a byte string. The
5 https://github.com/python/cpython/blob/master/Lib/socket.py
22
values are then separated into a list. It then inserts the values into the database by INSERT queries.
If it has been successfully received and stored, the code returns ”1”. If it fails, it will return a ”0”
to the client and wait for the following array to be sent.
When the communication is done, the server ends the connection and starts a new socket with
the same IP-address and port number, waiting for a new client to access the server.
3.4.4 Temporary server

When it comes to the server part, the best option would be to borrow a server from Halmstad
University. In that case, the security and management of the server would be professionally handled
and cost less time to set up. However, as a consequence of technical problems, this will not be a
part of this prototype of the Catfish project. A temporary server is implemented by the Data and
Sensors team instead to prove that the data communication works.
A Raspberry Pi model 4B is used as a server since that was already accessible from the Innovation
Lab. This server will create the connection between the Catfish and the main database. The
server creates a socket, an endpoint for sending/receiving data containing an IP-address and a port
number. The Raspberry PiTM microcomputer does not have access to a WAN, but only a LAN
created by a router.
The task of the router is to redirect messages incoming from the WAN and direct them to the
server’s socket. Usually, there is a firewall that stops incoming requests. To bypass the firewall,
port forwarding is used on the router. This is a way of redirecting an incoming message to a
specific socket, in this case to the Raspberry PiTM microcomputer. When the server receives data,
it will store the data in the database and send a confirmation back to the client, see Section 3.4.3
Client-server code. With all of this said, now the Raspberry PiTM microcomputer is reachable
from anywhere in the world, if the public IP-address of the router and the port number that redirects
to the Raspberry PiTM is known.
Most IP-addresses are dynamic, meaning that they change addresses once in a while. When a
computer needs an IP-address it asks the Internet service provider (ISP) to get one. The ISP that
is used is Comviq. A dynamic IP-address is inferior for a server because the client can not keep
track of when the address changes. This is where static IP-addresses come in.
A static IP-address is an IP-address that does not change. To get a static IP-address in a WAN,
the programmer needs to ask the IPS for an address, which usually costs a fee. In this case, Comviq
does not offer this kind of service.
Another option is to assign a dynamic DNS server. DNS stands for Domain Name System. A
system like this gives a name to a computer, for example catfish.ddns.com where it automatically
keeps track of when the IP-address changes. To connect to a server, the programmer instead calls
for catfish.ddns.com, and it retrieves the IP-address of the server [42]. Since the Data and Sensors
team’s solution to a server is temporary, a DNS server would not be necessary for the current state,
but might be an alternative to look into in future prototypes.
In the LAN, it is the Dynamic Host Configuration Protocol (DHCP) within the router that
assigns local IP-addresses. To keep the same local IP-address for the server, a reservation is set.
This is set up by assigning the Media Access Control address (MAC-address) of the Raspberry PITM
microcomputer to a local IP-address. The MAC-address is a unique identifier set when creating a
new network interface [52].
With all of this said, the temporary server is not a secure system. The simplest and most well-
known attack on a database server is an SQL injection attack, which would work on this server. An
23
SQL injection attack is when an attacker sends an unwanted query instead of the intended content.
A consequence can be that all data in the attacked database gets deleted [53].
To clarify, the Catfish sends its data through the WAN to the router, the router redirects
it by port forwarding in its LAN to the server, and the server accepts the data and sends an
acknowledgement back to the Catfish the same way.
24
Figure 11: How ”Do we have connection with the Arduinos?” box from Figure 10 functions.
25
Figure 12: How ”Send data to server” box in Figure 10 functions.
3.5 Implementation of databases

There are two databases in this project. One database stores the data in the Catfish and a second
one in the server. This is so that the Catfish can complete missions without a connection to the
Internet. If it has a connection, it will send the data in real-time to the second database.
Both databases are SQL databases instead of NoSQL databases. This is because there is a clear
relation to the collected data, and it is simple to add another drone if needed. Relational databases
are a well-known database type, so it would also be more time-efficient to create.
As seen in Figures 13 and 14 the structures are similar. All of the Cat’s measurements are
26
in one table, and the Fish measurements in another. To combine these, there is a Waypoint table.
This design makes it simple to add new sensors or a new drone with minimum manipulation. The
databases are similar to make it easier to synchronise the databases. The difference in the design
is that the server does not have the ”sent” column. This column tells the Catfish if it has sent the
data to the server or not. A view is also added to the local database that gathers all the non-sent
data to a two-dimensional array.
The databases have different DBMSs, and this is because they are used in two completely
different ways. The local database in the Catfish needs to work without a connection to the
Internet. In this case, SQLite is chosen as the DBMS. This is because it has its complete database
in a single file. This file is stored on the computer’s memory itself and therefore does not need the
Internet to access the database. For the database on the server, more options exist. The Microsoft
SQL Management Server System would be used if the server was on Halmstad University. However,
with the server being on a Raspberry PiTM microcomputer, it is better to use MariaDB. MariaDB
is an open-source platform free to use for commercial use, and it has a small footprint. MariaDB
Server is one of the most popular database servers in the world [28].
Figure 13: Structure of the local database. Figure 14: Structure of the main database.
3.6 Calibration and verification of the sensors

The calibration and verification of the sensors is a central part of the project. To make sure that
the values that the sensors collect are accurate, they are tested in a controlled environment. This
controlled environment is a lab located in Halmstad University, where the solutions and equipment
needed for the testing are accessible. The Environmental Analysis team is in charge of the liquid
solutions needed together with an expert that has great knowledge in the chemistry field6 .
Every sensor used in this thesis is an analog sensor, except for the digital temperature sensors.
According to the data-sheets of the sensors, all of the analog sensors need to be calibrated [20–
25]. The testing is divided into two parts, verification and calibration. How a sensor is verified is
by putting the probe in a body of water with already known values, then comparing it with the
value received from the sensor with the range and technical accuracy taken into account, see sensor
6 David Green, lecturer in Halmstad University
27
specifications on Table 1. If the values exceed this calculated value, it is needed to be calibrated.
For example: if the pH sensor is put into water with the known value 4, and it reads a value between
3.9 and 4.1, the verification is acceptable since the accuracy is ±0.1pH for the pH sensor, see Table
1. However, if it reaches beyond 4.1 or below 3.9, it needs to be calibrated. For all of the analog
sensors, verification is needed after every long-time use, in other words, after every mission.
Calibration means that the analog voltage value that the sensor receives needs to be adjusted
with the actual real value of the solution. This is necessary because it is almost certain that a sensor
sometimes has errors in the measurements. Errors in this context means the difference between the
collected value and the actual value. Aspects such as frequent usage, improper care of hardware,
temperature, pressure, and other environmental aspects can affect the sensors so that errors occur
[54].
In cases like these, calibration is the solution. However, the process of calibration differs between
the sensors used in this project. This is what is described in the sections to come.
3.6.1 pH-sensor
What is needed for verification and calibration of the pH value sensor is:
• 3NKCL solution
• Deionised water
• Acidic solution
• Alkaline solution
The 3NKCL solution is the standard liquid solution that is used for the maintenance of the pH
sensor. When the sensor is not in use, the top should always be kept wet with the said solution in
its cap in order to extend the probe’s life. Another crucial part for extending the probe’s life is to
always wash the probe with deionised water before putting it into another solution [21].
An acidic sample, an alkaline sample, and a sample in the middle with known values are needed
for calibration. The sensor’s values should reach for these values, and the potentiometer located on
the chip that came with the sensor is adjusted so that the expected values are displayed.
3.6.2 Turbidity-sensor
For the turbidity sensor, a conversion from voltage to NTU needs to be implemented since the
library used does not include that part [22]. This is done according to the graph (Figure 15)
which shows this relationship between voltage and NTU with the equation:
y = −1120.4x2 + 5742.3x − 4352.9

which is only accurate for:
2.5 < x < 4.2

The y-axis is the turbidity value in NTU, and the x-axis is the voltage value in Volts.
Since this sensor still can give us values beyond these limits, between 0-5 Volts (see sensor
specifications on Table 1), it is important to take the boundaries into account so that there is no
confusion in reading the values. For example, if the voltage reaches 2 volts, which is beyond the
28
Figure 15: The relationship between turbidity and voltage. The relationship is only accurate for
2.5 < x < 4.2 [22].
accuracy limit, the NTU-value will be about 2500 NTU (see Figure 15), which is wrong, while it
still seems to be within limits.
For calibration of this sensor, solutions with known turbidity values, preferably a high, low and
middle value, are used to verify that the values of the solution and the values received from the
code corresponds. If it does not, the potentiometer placed on the chip of the sensor is adjusted to
correct the error [22].
3.6.3 Total Dissolved Solids-sensor

The TDS sensor is calibrated by following the instructions that are already in the code accordingly:
1. Run the program, write ”enter” in the command line in the serial monitor in the Arduino
IDE.
2. Put the TDS and temperature probes in a solution with a known TDS value.
3. Write ”cal:[tds-value]” in the command line. For example, if we have a solution of 700 ppm,
write ”cal:700”.
4. When the program tells us it is successful, and the entered value is displayed, type ”exit” to
save and exit. Now the sensor is calibrated [23].
3.6.4 Dissolved Oxygen-sensor

For the DO sensor to function, the following liquid solution is needed to be filled in its cap:
• 0.5 mol/L NaOH solution
This solution is to be changed every month, and the cap every second month, to achieve as accurate
values as possible.
For the first time calibration, two cups of water are prepared, one with cold water, and the other
with warm water, within the sensor’s temperature range (see Table 1), since DO values depend on
temperature. The cups of water should also be filled with air before insertion of the sensor, by, for
29
example, using a straw or a machine that blows air automatically to increase the level of oxygen in
the water. Calibration is done accordingly:
1. Fill the cap with the 0.5 mol/L NaOH solution.

2. Place probe into the solution with cold water, wait a few seconds for the value to stabilise.
3. Read the raw analog voltage values and the water temperature in the serial monitor in the
Arduino IDE. Do the same thing with the other solution.
4. In the code, fill in the variables with the collected values:

• CAL1 V = the analog voltage value from the solution with cold water.
• CAL1 T = the temperature from the solution with cold water.
• CAL2 V = the analog voltage value from the solution with warm water.
• CAL2 T = the temperature value from the solution with warm water.
Now, the rest of the code takes care of the calibration, and the collection of the DO value [24].
3.6.5 Electrical Conductivity-sensor

For the verification and calibration of the EC sensor, the solutions needed are:
• Distilled water
• 12.88ms/cm standard buffer solution
The calibration of the EC sensor is done similarly to the TDS sensor. For calibration of the EC
sensor, these steps are followed:
1. Wash the probe with distilled water.

2. Run the program, write ”enterec” in the command line in the serial monitor in the Arduino
IDE.
3. Insert the probe into the 12.88ms/cm standard buffer solution (which came with the sensor)
together with the temperature sensor probe.
4. Write ”calec” to start the calibration. The program will automatically assume that the
standard buffer solution is in use.
5. When the program tells us it is successful, and the entered value is displayed, type ”exitec”
in the command line to save and exit. Now the sensor is calibrated [25].
30
3.7 Analysis of results
The following list is created to test the Data and Sensors team’s part of the Catfish project:
1. Test the database
How to test: By discussing with a team member7 who has prior expertise with databases
and has worked on the previous Catfish prototype, and also by manual testing. This includes
testing of tables, columns, stored procedures, and functional database. For SQLite, it will
always be possible to send in the wrong type of data. This is a drawback on SQLite, so most
of the security is in the code.
Expected result: The database handles the queries as planned.
2. Test the communication between the microcomputer and microcontrollers
How to test: By manually disconnecting the USB cables between the microcontrollers and
microcomputer while the code is running, on different parts of the code.
Expected result: They can communicate with each other and handle the errors that occur.
The code should also continue even though the connection is lost.
3. Discuss with the environmental team if the measured data is reasonable
How to test: By calibrating the sensors by following the instructions in Section 3.6 Cali-
bration and verification of the sensors.
Expected result: Get reasonable measurements.
4. Test what happens if one of the sensors disconnects
How to test: By manually removing the connection between the sensors and the microcon-
trollers during the measurements.
Expected result: All the other sensors that are still connected will continue working.
5. Check that the data from the local database corresponds to the data of the main
database
How to test: By accessing the databases after a mission has run, and comparing the databases.
Expected result: The databases are synchronised.
6. Test if the Catfish can complete a mission without a 4G connection
How to test: By running the main code without the modem connected to the Raspberry PiTM
microcomputer.
Expected result: The Catfish should have the mission’s data on the main microcomputer in
the local database. When connecting the Catfish to the Internet again, it should send the
data to the main database, and the ”sent” column should be filled with ”1”.
7. Test the Catfish with poor connection to the Internet
How to test: By disconnecting and connecting the modem from the Raspberry PiTM micro-
computer when running the main loop.
Expected result: The data is sent in real-time when connected. When it is not connected, it
stores the data locally until the connection is back again. When getting a connection again, it
should send all the data that is not sent to the main database and continue sending real-time
data.
7 Julian Kaduk, Interaction Design Engineer
31
4 Results
In this section, all of the results of this project are presented.
See Figure 16 for the schematics of the Cat and Figure 17 for the schematics of the Fish in
Appendix A.
A real mission has not been completed, since the day of the testing was delayed for the Catfish
project. None of the Data and Sensors team’s tests have been completed with the full prototype
assembled. However, almost every planned test can be executed despite this.
Appendix B contains figures of the database with values in it after a ”mission” the Data and
Sensors team has created. This ”mission” included collecting the data from the sensors in open air.
Figures 18 and 19 are the tables of the local database, and Figures 20 and 21 are the Waypoint
tables in the local database, with the difference of these two figures are the column ”sent”, which
tells us if the row has been sent to the main database. Figures 22, 23 and 24 are images of the
Catdata, Fishdata and Waypoint tables in the main database on the server.
When it comes to implementing the main functionalities of the prototype, the Data and Sensors
team has made the structure of the mission in the main code, where all parts of a mission are
taken into account. The servo motor is implemented successfully by the Design and Manufacturing
team. However, the communication with the flight controller and main microcomputer is yet to be
implemented by the Control and Autonomy team.
Conclusively, every part of a mission works individually. The servo motor and the flight con-
troller functions as planned, but it has not been tested if the servo motor can trigger the data
collection, or that the flight controller triggers the servo motor, etc. What is left to implement is
the actual combination of all parts of the system.
See Appendix C for photographs of the finished prototype.
This section will go through the list from Section 3.7 Analysis of results.
1. Test the database

The testing of the database is successfully performed. There are no problems with inserting,
altering, and selecting queries.
2. Test the communication between the microcomputer and microcontrollers
The communication between the microcomputer and microcontrollers is executed as expected.
When connected, they can communicate with each other without errors. If they can not
connect, the errors are handled, see Table 4. During these tests, the USB cables between
the microcomputer and microcontrollers are manually disconnected in order to simulate real
errors that can occur from glitches from the winch-system. The disconnection of the USB
cables is manually executed during the measurements of the Cat, the measurements of the
Fish, and after their measurements. These parts of the code are tested by manually physically
disconnecting the USB cable of the Arduino UNO by itself, the USB cable of the Arduino
Mega by itself, and both of them at the same time.
If the physical disconnection of the microcontrollers happens during their measurements, the
values are thrown away, and the data collection is restarted.
If the physical disconnection happens where it does not affect the data collection, the data
collection succeeds, and the ArduinoTM microcontrollers’ serial ports are disconnected in
the code. This is important since if they physically disconnect, the serial ports might change
32
names which can generate errors during the following data collection, as explained in Section
3.3.2 Connection with the microcontrollers.
It is also made sure that the prototype never gets stuck in the data collection. If it fails to
collect data nine times, the data collection is aborted. When this happens, the flight controller
should be notified to abort the mission, which is not implemented in this prototype.
Testing of error-cases in the data-collection code

Placement in the code: Cat disconnects Fish disconnects Both disconnect
Cat measurement case 1 case 1 case 1
Fish measurement case 2 case 1 case 1
Done measurement case 2 case 2 case 2
Cases
Case 1 Throw away the collected values (if there are any). Start over.
Case 2 Collection succeeds. Disconnect ports. Move on with the code.
Table 4: Testing of error handling of cases in the data-collection part of the code.
3. Discuss with the environmental team if the measured data is reasonable

The measured data is not reasonable. This is because the calibration of the sensors is not done
due to lack of time and unexpected change of plans. See Section 6 Discussion for more
information. However, if the sensors would have been calibrated, but without the temperature
sensor being connected, then the DO, EC, and TDS sensor will also give unreasonable values
since they are dependent on the temperature sensor.
4. Test what happens if one of the sensors disconnects
If one of the sensors, or even all of them, disconnect, no error will occur; only an unreasonable
value will be received. If the other sensors are functioning, then their values are received as
usual.
5. Check that the data from the local database corresponds to the data of the main
database
The local database and the main database have the same exact values. See Appendix B.
6. Test if the Catfish can complete a mission without a 4G connection
The tables Catdata, Fishdata and Waypoint on the local database are filled without the
Internet connection at first, and then they are sent to the main database when the Internet
access is achieved, which works without errors. Also, as seen in Figure 25 in Appendix
B, the Internet connection is lost during the measurements, which does not affect anything
except for the ”sent” column.
7. Test the Catfish with poor connection to the Internet
With bad connection to the Internet, the Catfish will continually measure values. The data
is sent to the server when connected to the Internet. In Figure 25 in Appendix B, the
Catfish lost connection after some time, but it still managed to continue on with the code.
33
5 Conclusions
This section goes through the conclusions of the Data and Sensors team in the Catfish project by
going through the requirement specifications.
5.1 Implementation of data collection from the Cat and the Fish
The collection of data from the Cat and the Fish has been successful. The Cat and the Fish
collect data from the sensors and handle any errors that might occur, but the sensors have not been
calibrated.
5.1.1 Error handling

The errors handled in conjunction with the microcontrollers’ data collection are: the cables of the
input pins can disconnect, and the cables that power the sensors can disconnect.
If the cables of the input pins on a microcontroller disconnect, the ArduinoTM microcontroller
will generate random numbers from a pin that has nothing connected to it, called floating input
[13, 15]. Meaning, if a disconnection happens, a random number is generated without any error in
the program. For example, this is seen on the Catdata table in Figure 18 in Appendix B, rows
24 to 26, where the Data and Sensors team purposely removed the data pins in order to prove this.
If the 5V pin that powers the sensors on the ArduinoTM microcontroller disconnects, the values of
the sensors turn to 0. This is what is seen happening in table Fishdata in Figure 19 in Appendix
B, rows 8 to 18. The temperature sensor’s code generates the value -1000 whenever it senses that
something is wrong with the connection. The dissolved oxygen sensor returns the actual value 0
since the calculations do not affect that value. The turbidity sensor returns the value -4352.9, which
means that the voltage is 0; it just has gone through the equation that translates the voltage signal
into an NTU value from Section 3.6.2:
y(0) = −1120.4 · 02 + 5742.3 · 0 − 4352.9

y(0) = −4352.9
Conclusively, as long as a value is received, the code will not break. Even though the sensors are
disconnected, the power source of the sensors is disconnected, or even if the values are very wrong
(by, for example, reading from non-calibrated sensors), the system will still proceed to insert the
values in the database and continues.
5.1.2 Calibration
Even though there was no time to calibrate the sensors, the actual concept of monitoring the water
quality is very promising to work. This is because the calibration of sensors only means that the
analog voltage reading needs to be adjusted. The sensors are still returning values that are changed
depending on the solution they are in, which means that they do sense the water quality, unless
there is an unknown error in the hardware.
As seen in the Catdata table in Figure 18 in Appendix B, rows 1 to 23, the values look like
that for a reason. These values were received from the sensors when none of them were in the water;
they were open in the air.
34
The temperature sensor shows us a reasonable value, and the pH sensor is returning a value
based on the 3NKCL solution in its cap.
The turbidity sensor senses how transparent the medium is; the lower the value, the more
transparent [22], meaning that a high value is reasonable since air is as transparent as something
can be. This also explains why the turbidity value of the Fishdata table (Figure 19 in Appendix
B, rows 1 to 7 and 19 to 23) is negative, because the value is too high as it has not been calibrated.
Meaning, it goes beyond the right limit of the graph that explains the relationship between turbidity
and voltage (Figure 15).
The dissolved oxygen value is 0 on Catdata because the solution in its cap is not filled, while
the dissolved oxygen sensor for the Fish has its cap filled, which is why we see a value there.
The TDS and conductivity values return the value 0 because both measure conductivity, and
the air is not conductive, making those values reasonable.
As mentioned in the purpose section of this report, the focus of the Data and Sensors team is
to make the prototype an IoT device, which means that the calibration had to be de-prioritised.
However, calibration of the sensors is fixed by following the tutorial in Section 3.6 Calibration
and verification of the sensors, as long as there is time put into it, and people with a chemistry
background around to help with the liquid solutions needed.
Conclusively, calibration is needed, and it is not certain that the sensors are entirely functional,
but it looks very promising.
5.2 Data transfer from the Cat and the Fish to the main microcomputer
The sending of data from the ArduinoTM microcontrollers in the Cat and Fish to the microcomputer
has been successful. It can handle the errors caused by the glitching from the winch-system, and
the microcontrollers can disconnect from the main microcomputer.
The winch-system created by the Design and Manufacturing team is a phenomenal solution to
the problem of lowering and raising the Fish while still having connection [48], but not glitch-proof.
The winch-system can cause much glitching between the microcontroller of the Fish and the main
microcomputer, which in itself can cause errors in the main code when trying to collect data. This
is fixed by the structure of the code, see Section 3.3 Send data to a database in real-time.
As seen in Table 4, the code is tested in these parts where the Data and Sensors team manually
generate the disconnection to resemble the actual errors that can occur, which proves that the code
has good error handling in this part. This does not only prove that it can handle the winch-system’s
glitches; it also handles the disconnection of either of the microcontrollers that can happen for other
reasons.
When it comes to the serial communication between the microcontrollers and the main micro-
computer, the serial channel will be overloaded if there is data sent constantly, which will result
in no data coming forward. This is handled by the structure of the code, by having the micro-
controllers only send data when it is asked for it, and the microcomputer only asks for more data
until it has received the previous piece of data. This makes the data transmission between the
microcontrollers and microcomputer extraordinarily secure and reliable.
With all of this said, the system will handle if the microcontrollers are disconnected from the
main microcomputer without errors, and the serial communication will not be overloaded because
of the structure of the code.
35
5.3 Implementation of main functionalities in the main microcomputer
together with the Control and Autonomy team
The Design and Manufacturing team implemented the servo motor [48], but the PixhawkTM im-
plementation is yet to be done by the Control and Autonomy team. It looks very promising since,
according to them, there have been projects where a Raspberry PiTM and a PixhawkTM flight
controller have communicated with each other [49], and the Data and Sensors team has taken these
parts into account when coding.
5.4 Data transfer to a database wirelessly in real-time

For testing that the prototype still functions without the Internet connection, the modem is removed
to simulate loss of the Internet connection in Nissan river. The figures mentioned in this section
can be found in Appendix B.
In the Waypoint table, one column is meant to show if the row of values is sent or not to the
server. This is the column named ”sent”. When the value is 0, it means that the data has not been
sent, and a value of 1 meaning it has been sent. In Figure 20, the data has not been sent to the
server. This is because the Catfish was not connected to the Internet at the time of the measuring.
When the modem is reattached to the Catfish, the Internet connection is back, and the Catfish will
try to send the data to the server. As seen in Figure 21, all the values in the sent-column has
been set to 1. This means that the rows have been sent and stored on the server. When comparing
the server database and the local database in Figures 19 and 23, 18 and 22, 21 and 24 they have
got exactly the same values. This means that the transfer over the Internet has been successful. If
the Internet connection would be unstable, a similar case to what is happening in Figure 25 could
occur (Note that this figure is not from the same data measurement as the previous figures). The
first eight rows have sent their data to the server and then lost their connection. It continues with
the mission even though the connection is lost. This is why the 0s are in the ”sent” column on rows
9, 10, and 11. Later, when the connection is back, it will send the rows that have not been sent.
This proves that the Catfish can send data over the Internet to a server, and when it does
not have internet access, it will store the values, and then send the values when the connection is
reestablished.
5.4.1 Server
The temporary server that is implemented by the Data and Sensors team is not a long-term solution
for the Catfish project since it is neither secure nor stable. A simple injection attack can delete the
whole database, or anyone with the right IP-address and port number can connect to the server.
The server is not stable because the IP-address is not static and it needs a specific string sent to it or
the server will not store the data. It was only done in order to prove that the data communication
works. The temporary server has lived up to its purpose, to put in the data that is sent to it in a
database, see Figures 22, 23 and 24 in Appendix B. Conclusively, the server should be placed
where it can be professionally handled, such as a server in Halmstad University or on a purchased
server.
36
5.5 Implementation of databases
The databases are easy to use. All of the insert, alter, and select queries are working without a
problem, and all of the data is accessible in the database. The databases are expandable because
of the relations between the tables. The figures of Appendix B have directly been taken from the
databases. This would define a well-built database.
37
6 Discussion
In a similar project, about a water quality monitoring system that notifies the user of real-time
measurements [8], they have dug deeper into how the sensors work and how much precision they
get from the sensors, and less is written about how they transmit the data. In contrast to our
project, we have the focus on transmitting data instead of measuring accurately. They also do not
have their system connected to the Internet, as we do. They measure the following water qualities:
temperature, pH, electrical conductivity, dissolved oxygen, turbidity, oxidation reduction potential
(ORP), free residual chlorine (FRC), and nitrates, where all of the measurements succeeded except
for the ORP sensor since it was not calibrated, which is five out of six of the water quality parameters
that are used in the Catfish project. Our work combined with this report supports and guarantees
that the next prototype of the Catfish project will be a success.
When it comes to transmitting data over the Internet, there are many different types of protocols
that are interesting to use. We have chosen to use TCP/IP to send data from the Catfish to the
server. Another way to do this is by using the Message Queuing Telemetry Transport (MQTT)
protocol, which works on top of the TCP/IP. MQTT is a protocol often used when implementing
IoT systems. It is designed to connect to places with restricted bandwidth. This use of MQTT in a
similar project to the Catfish project, that measures environmental qualities in a weather tracking
system, controlled by a Raspberry PiTM microcomputer [10].
6.1 Limitations of our solutions

The server was created as a last-minute solution by the Data and Sensors team because no server
was prepared. We expected that the project leaders had already thought about where to store the
data of the Catfish prototype since they needed a team that collected data, but it turned out a
little too late that they had not. Meaning, we had no other choice than to create a temporary
server and de-prioritise the calibration of the sensors instead. The Data and Sensors team agreed
internally that it is more important to focus on the Internet connectivity and data communication
rather than receiving the correct values of the sensors from a computer science perspective.
Another reason why the calibration of the sensors did not happen was that when we had planned
to go through with the calibration, the school shut down for three weeks because of a COVID-19
outbreak in Halmstad. We had prepared the solutions with the help of David Green and the
Environmental team, but when the school was shut down, we did not have access to the lab
containing the solutions. Also, it took a significant amount of time to move the whole project
to our apartments during the lockdown. We had to set up the Raspberry PiTM together with a
monitor, keyboard and a mouse, and a soldering station for the soldering of the sensors’ cables and
the microcontrollers. This was more time consuming compared to if we had used already existing
equipment as planned.
During this thesis, a few problems arose, and the project leaders gave us limited help since they
do not have a computer science background. This is why all specifications regarding computer
science were set by the Data and Sensors team.
6.2 Next prototype

This section discusses what technical improvements could be implemented for the next prototype
of Catfish.
38
6.2.1 Improvements of the server
The server is made under pressure of time in this prototype. This means that the server can be
improved significantly. A suggestion for the next prototype is to have a designated team that
improves the security, handling, and connection of the server.
An idea for improving the server’s security is to have a password between the Catfish and server
to start the communication. A handshake can also accomplish this.
The way the data is transmitted can also be improved. A suggestion of this part is to look into
JSON files. This could make it easier to add more sensors and drones in the future.
Having a Raspberry PiTM microcomputer as a server would work on the following couple of
prototypes. However, when Catfish becomes a product, a server like this would not suffice. As a
long-term solution, a collaboration with Halmstad University would be a more time-efficient means
to get a secure and reliable server.
6.2.2 Improvements of the data communication

The communication between the Cat and the Fish works very well in this prototype. However, one
thing that can be improved is that the Cat and the Fish should not rely on each other to work.
For example, at the moment, if the Fish loses connection to the Raspberry PiTM microcomputer,
then all the data collection stops. For the next prototype, it would be better if they were handled
in parallel to each other. This would mean if the Fish loses connection, then the Cat would still
take the values it can get and store them in the database.
6.2.3 Other improvements

Early on in this project, there was a discussion about if we should have a camera on the prototype
or not, preferably on the Fish, so that the user can see the bottom of Nissan in real-time with a
low FPS (frames per seconds) value. We decided that it was too much work for this prototype.
Another important thing the next team could think about is data storage. For this prototype,
not much thought was taken about the amount of storage the microcontrollers use, the amount of
data transmitted over the Internet, the costs of that, etc., since there were such small amounts of
data to work with for this prototype.
When having calibrated sensors, an improvement could be to have a column in the databases
that tell if the data is reasonable. For example, if one of the sensors generates a value outside of
their range (see Table 1 for the ranges of the sensors), the ”reasonable”-row of that sensor can be
filled with ”0”, and a ”1” if the value is reasonable. This could help the application to know what
values are wrong, so that it can notify the user.
Another improvement regarding the sensors could be to choose a different set of sensors with
complete data-sheets, unlike the current set. Information about the hardware and how the sensors
technically work can not be found on the current ones.
One more improvement would be to specify what our team does and separate the tasks better.
There were not enough time to dig deep in one specific area. Instead, we made a simple version
of every step because of the time constraint. For the next prototype, the Data and Sensors team
should be divided into multiple teams. A suggestion would be to have at least two teams, one for
the sensors and data collection, and the other for the communication and data storage.
39
References
[1] United Nations. Water and Sanitation - United Nations Sustainable Development, 2021. Ac-
cessed: 2021-06-11.
[2] United Nations. Oceans - United Nations Sustainable Development, 2021. Accessed: 2021-06-
11.
[3] Feng Xia, Laurence T Yang, Lizhe Wang, and Alexey Vinel. Internet of things. International
journal of communication systems, 25(9):1101, 2012.
[4] Joern Ploennigs, John Cohn, and Andy Stanford-Clark. The future of iot. IEEE Internet of
Things Magazine, 1(1):28–33, 2018.
[5] Eric Knorr and Galen Gruman. What cloud computing really means. InfoWorld, 7(20-20):1–17,
2008.
[6] Digiteum team. Difference between cloud, fog and edge computing in iot. Digiteum, 2020.
Accessed: 2021-04-26.
[7] Partha Pratim Ray. An introduction to dew computing: Definition, concept and implications.
IEEE Access, 6, 2018.
[8] N. A. Cloete, R. Malekian, and L. Nair. Design of smart sensors for real-time water quality
monitoring. IEEE Access, 4:3975–3990, 2016.
[9] A. López-Vargas, M. Fuentes, and M. Vivar. Iot application for real-time monitoring of solar
home systems based on arduino™ with 3g connectivity. IEEE Sensors Journal, 19(2):679–691,
2019.
[10] R. K. Kodali and V. S. K. Gorantla. Weather tracking system using mqtt and sqlite. In
2017 3rd International Conference on Applied and Theoretical Computing and Communication
Technology (iCATccT), pages 205–208, 2017.
[11] Peter Marwedel. Embedded system design : Embedded systems foundations of cyber-physical
systems, and the internet of things. Springer Nature, 4, 2021.
[12] Arduino. Arduino Products, 2021. Accessed: 2021-04-21.
[13] Microchip. ATmega640/V-1280/V-1281/V-2560/V-2561/V Datasheet, 2014.
[14] Arduino. Arduino UNO Rev3, 2021. Accessed: 2021-04-21.
[15] Microchip. ATmega328P Datasheet, 2015.
[16] Arduino. Arduino¨- Home, 2021. Accessed: 2021-04-26.
[17] IAR Systems. IAR Systems, 2021. Accessed: 2021-04-26.
[18] Digiteum team. Microprocessor vs microcontroller vs microcomputer. Jaycon Systems, 2019.
Accessed: 2021-04-26.
[19] Arduino. Teach, Learn and Make with Raspberry Pi, 2021. Accessed: 2021-04-26.
40
[20] Dallas Semiconductor. DS18B20 Programmable Resolution 1-Wire® Digital Thermometer.
[21] DFRobot. PH meter(SKU: SEN0161), 2017.
[22] DFRobot. Turbidity sensor SKU: SEN0189, 2017.
[23] DFRobot. Gravity: Analog TDS Sensor / Meter For Arduino SKU: SEN0244, 2017.
[24] DFRobot. Gravity: Analog Dissolved Oxygen Sensor / Meter Kit For Arduino SKU:SEN0237-
A.
[25] DFRobot. Gravity: Analog Electrical Conductivity Sensor / Meter(K=10).
[26] Dfrobot. https://www.dfrobot.com/. Accessed: 2021-03-01.
[27] AJ Graham. How Are Databases Used in the Real World? Techwalla. Accessed: 2021-04-26.
[28] Mariadb. Mariadb home page. Accessed: 2021-04-22.
[29] SQLite. SQLite home page. Accessed: 2021-04-22.
[30] Microsoft. What is SQL Server Management Studio (SSMS)? Accessed: 2021-04-22.
[31] Microsoft. Visual Studio. Accessed: 2021-04-22.
[32] Lauren Schaefer. What is NoSQL? mongoDB. Accessed: 2021-04-26.
[33] Dawoud Shenouda Dawoud and Peter Dawoud. Serial Communication Protocols and Standards
RS232/485, UART/USART, SPI, USB, INSTEON, Wi-Fi and WiMAX, pages i–xl. 2020.
[34] Les Besser and Rowan Gilmore. Practical RF Circuit Design for Modern Wireless Systems,
volume I: Passive Circuits and Systems. Artech House, Norwood, 2003.
[35] Wireless Serial Port Communication Module, 10 2010.
[36] Micrichip Technology Inc. Low-Power Long Range LoRa® Technology Transceiver Module,
2017.
[37] Nordic semiconductor. Single Chip 2.4Ghz Transciever, 9 2008.
[38] A. Ali, N.H. Saad, N.A. Razali, and N. Vitee. Implementation of automatic meter reading
(amr) using radio frequency (rf) module. In 2012 IEEE International Conference on Power
and Energy (PECon), pages 876–879, 2012.
[39] Zhao Xiaoyan, Zheng Xiangyang, Duan Chen, Chen Zhaohui, Sang Shangming, and Zhang
Zhaohui. The design and implementation of the greenhouse monitoring system based on
gsm and rf technologies. In 2013 International Conference on Computational Problem-Solving
(ICCP), pages 32–35, 2013.
[40] William Lehr and Lee W McKnight. Wireless internet access: 3g vs. wifi? Telecommunications
Policy, 27(5-6):351–370, 2003.
[41] Erik Dahlman, Stefan Parkvall, and Johan Skold. 4G: LTE/LTE-advanced for mobile broad-
band. Academic press, 2013.
41
[42] Preston Gralla. How the Internet works. Que Publishing, 1998.
[43] K. Xia, J. Ni, Y. Ye, P. Xu, and Y. Wang. A real-time monitoring system based on zigbee and
4g communications for photovoltaic generation. CSEE Journal of Power and Energy Systems,
6(1):52–63, 2020.
[44] Sagarkumar Patel, Vatsal Shah, and Maharshi Kansara. Comparative study of 2g, 3g and 4g.
International Journal of Scientific Research in Computer Science, Engineering and Informa-
tion Technology, 3(3):1962–1964, 2018.
[45] Charles M Kozierok. The TCP/IP guide: a comprehensive, illustrated Internet protocols ref-
erence. No Starch Press, 2005.
[46] Haroon Shakirat Oluwatosin. Client-server model. IOSRJ Comput. Eng, 16(1):2278–8727,
2014.
[47] G. Held. Server Management. Best Practices. CRC Press, 2000.
[48] Evelin Bergvall. Product Development in University Driven Innovation - Catfish, an action
research thesis. 2021.
[49] Michael Alexander Georg Forschle. Catfish project - Control and Autonomy. 2021.
[50] Vidar Hårding. Control and Autonomy of a Water quality measuring Unmanned Surface Ve-
hicle (USV) - Catfish project - Control and Autonomy. 2021.
[51] Tele2. Täckningskarta - Tele2, 2021. Accessed: 2021-04-27.

[52] TechTarget. DHCP (Dynamic Host Configuration Protocol), 2019. Accessed: 2021-06-04.
[53] K. Wei, M. Muthuprasanna, and Suraj Kothari. Preventing sql injection attacks in stored
procedures. In Australian Software Engineering Conference (ASWEC’06), pages 8 pp.–198,
2006.
[54] Scott Sommer. What is a sensor calibration and why is it important? RealPars, 2019. Accessed:
2021-04-12.
42
Appendices
A Schematics
This appendix shows the schematics of the sensors and Arduino microcontrollers.
Figure 16: The schematics of the sensors in the Cat.
43
Figure 17: The schematics of the sensors in the Fish.
44
B Databases
This appendix contains images of the databases. These are actual screenshots of the databases on
the microcomputers.
Figure 18: The table Catdata in the local database.
45
Figure 19: The table FishData in the local database.
46
Figure 20: The table Waypoint in the local database without internet connection.
47
Figure 21: The table Waypoint in the local database with internet connection.
48
Figure 22: The table CatData in the server database.
49
Figure 23: The table FishData in the
server database.
50
Figure 24: The table Waypoint in the server database.
51
Figure 25: The table Waypoint in the local database when losing connection from internet. Note
that this figure is not from the same data measurement as the previous figures.
52
C The finished prototype
This appendix includes photographs of the finished prototype. The winch-system was tested and
succeeded as intended.
On some photographs, a rope around the Fish and stones hanging from them are visible. This
is because the Fish was not heavy enough to sink, which the stones compensated for.
Figure 26: The finished prototype in action.
53
Figure 27: A full view of the prototype on land.
54
Figure 28: Here the Fish is right under the Cat. Here the placement of the sensors of the Fish are
visible too.
55
Figure 29: The Fish being lowered.
56
Figure 30: The placement of the sensors on the Cat.
57
Figure 31: This is the box of electronics. Most of the parts visible belong to the Control and
Autonomy team. The Raspberry Pi model 4B is visible on the top left, and the modem is seen to
the left.
58
Currently studying master’s program
in computer science. For fun, I do a
lot of sports where climbing is my
favourite especially outdoors. The
newest sport is volleyball that started
together with other students in
Halmstad.
Currently studying for the Master's

program in Computer Science and
Engineering at Halmstad University. I
like to paint, draw, and make
sculptures in clay during my spare
time.
PO Box 823, SE-301 18 Halmstad

Phone: +35 46 16 71 00
E-mail: registrator@hh.se
www.hh.se

Full Text 02

Uploaded by

Copyright:

Available Formats

You might also like

Full Text 02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Text 02

Uploaded by

Copyright:

Available Formats

Bachelor Thesis

Computer Science and Engineering, 300 credits

An implementation of a real-time water

Catfish - Data and Sensors

Computer Science and Engineering, 15

C The finished prototype 53

1.3 Requirement Specification

2.1 Microcontrollers and microcomputers

• Temperature sensor DS18B20 [20]

• pH sensor SKU: SEN0161 [21]

• Dissolved Oxygen (DO) sensor SKU:SEN0237-A [24]

Most significant sensor specifications

2.3.1 Relational database

2.3.2 Non-relational database

Figure 4: An example of a document database.

2.4.1 Between microcontrollers

2.4.2 Radio technology

2.4.3 Internet access

3.1.1 Choice of hardware and coding environment

3.1.3 Code of the sensors

3.2 Data transfer to the main microcomputer

3.3 Combination of main functionalities in the main microcomputer

3.3.2 Connection with the microcontrollers

Mean vs. Median vs. Mode

3.3.5 Local database

3.4 Data transfer to a database wirelessly in real-time

3.4.1 Choice of modem

3.4.2 Choice of software and protocol

3.4.3 Client-server code

3.4.4 Temporary server

3.5 Implementation of databases

3.6 Calibration and verification of the sensors

y = −1120.4x2 + 5742.3x − 4352.9

2.5 < x < 4.2

3.6.3 Total Dissolved Solids-sensor

3.6.4 Dissolved Oxygen-sensor

1. Fill the cap with the 0.5 mol/L NaOH solution.

4. In the code, fill in the variables with the collected values:

3.6.5 Electrical Conductivity-sensor

• 12.88ms/cm standard buffer solution

1. Wash the probe with distilled water.

1. Test the database

Testing of error-cases in the data-collection code

3. Discuss with the environmental team if the measured data is reasonable

5.1.1 Error handling

y(0) = −1120.4 · 02 + 5742.3 · 0 − 4352.9

5.4 Data transfer to a database wirelessly in real-time

6.1 Limitations of our solutions

6.2 Next prototype

6.2.2 Improvements of the data communication

6.2.3 Other improvements

[51] Tele2. Täckningskarta - Tele2, 2021. Accessed: 2021-04-27.

Figure 16: The schematics of the sensors in the Cat.

Figure 18: The table Catdata in the local database.

Figure 26: The finished prototype in action.

Currently studying for the Master's

PO Box 823, SE-301 18 Halmstad

You might also like