Li-Fi Based Application Final Report

College of Electrical and Computer Engineering
EEN450: Design Project (Capstone)

Section 51
Li-Fi Based Applications

by
Raghad JZ Abu-olwan 1045560
Nourhan Khalid Ahmed 1045693
Fatima Omar Al-Baiti 1043051
Aya Iyad Murad 1046415
A thesis submitted in partial fulfillment for the

degree of undergraduate of electrical and computer engineering
to
Dr. Montasir Qasymeh
Assistant Professor of Electrical Engineering , Abu Dhabi University
and
Dr. Mohammed Ghazal
Assistant Professor Chair of Electrical and Computer Engineering
Electrical Engineering and Computer Science
December 2017
Declaration of Authorship
I, Fatma Al-Baiti, Raghad JZ Abu-olwan, Nourhan Khalid Ahmed, and Aya Iyad Murad,
declare that this thesis titled, ‘Li-Fi based Applications’ and the work presented in it is
our own. I confirm that:
This work was done wholly or mainly while in candidature for a research degree
at this University.
Where any part of this thesis has previously been submitted for a degree or any
other qualification at this University or any other institution, this has been clearly
stated.
Where I have consulted the published work of others, this is always clearly at-
tributed.
Where I have quoted from the work of others, the source is always given. With
the exception of such quotations, this thesis is entirely my own work.
I have acknowledged all main sources of help.
Where the thesis is based on work done by myself jointly with others, I have made
clear exactly what was done by others and what I have contributed myself.
Signed:
Date:
i
“When nothing is going right, go left.”
Abstract
Dr. Montasir Qasymeh
Assistant Professor of Electrical Engineering , Abu Dhabi University
and
Dr. Mohammed Ghazal
Assistant Professor Chair of Electrical and Computer Engineering
Electrical Engineering and Computer Science
Doctor of Philosophy
by Raghad JZ Abu-olwan 1045560

Nourhan Khalid Ahmed 1045693
Fatima Omar Al-Baiti 1043051
Aya Iyad Murad 1046415
Li-Fi (Light Fidelity) is a new technology under development that will, in the future, be
used to improve digital communication alongside Wi-Fi. The objective of our project
is to utilize Li-Fi in designing two applications to solve current issues that cannot be
solved with Wi-Fi. The first is a system that enables sending files during exams or
conferences to a large number of people where radio jamming is required. The second is
an underwater exploration robot controlled remotely through Li-Fi, which will be used
to take pictures underwater.
Acknowledgements
Special thanks to Engineer Yasmina Al-khalil and Engineer Mohamed Khouya, who
put up with our endless questions and gave us guidance, hope, and support, and also
to Morne Van Heerden, Dr. Mohamed Ghazal, and Dr. Montasir Qasymeh for their
valuable contributions in this project.
iv
Contents
Declaration of Authorship i
Abstract iii
Acknowledgements iv
List of Figures viii
1 Introduction 1
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 File transfer application . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Underwater Optical Communication . . . . . . . . . . . . . . . . . 6
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 What is Li-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1.1 Li-fi vs Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Li-Fi working principle . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Misconceptions about Li-Fi . . . . . . . . . . . . . . . . . . . . . . 14
1.3.4 Harald Haas Achievement . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.5 Optical Underwater Communication Systems . . . . . . . . . . . . 16
1.3.6 History of ROVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.7 UDP and TCP Protocols . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Implementation of a file sending system using Li-Fi . . . . . . . . . 18
1.4.2 Implementation of file sending system using Wi-Fi . . . . . . . . . 19
1.4.3 Acoustic and optical underwater systems working principle . . . . 20
1.4.3.1 Under Water Systems: A comparison between Underwa-
ter Acoustic systems and Optical systems . . . . . . . . . 21
1.4.4 Line of Sight for underwater optical communication . . . . . . . . 22
1.4.4.1 Optical Systems . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.5 Photophone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Economic Impact Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Society Impact Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.7 Environment Impact Statement . . . . . . . . . . . . . . . . . . . . . . . . 26
v
Contents vi
1.8 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 Design 27
2.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Model and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Li-Fi compatibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 File sending application Testing Plan . . . . . . . . . . . . . . . . . 29
2.2.3 Li-Fi Based Remotely Operated Vehicle Application Testing Plan . 31
2.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Code Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 File transfer application . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2 Underwater ROV Application . . . . . . . . . . . . . . . . . . . . . 36
2.5 Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1 Failed Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1.1 AdaFruit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1.2 Logic Level Converter . . . . . . . . . . . . . . . . . . . . 39
3 Implementation 42
3.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2 Underwater robot . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Software Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.1 Li-Fi Compatibles Configuration . . . . . . . . . . . . . . . . . . . 48
3.2.2 File Sending Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.2.1 Experiment One: Transmitting Bytearray . . . . . . . . . 50
3.2.2.2 Experiment two: File Sending Protocol . . . . . . . . . . 51
3.2.2.3 Experiment Three: Sending Text file as byte arrays . . . 52
3.2.2.4 Experiment Four: Encoding and Decoding a File . . . . . 56
3.2.2.5 User Interface GUI . . . . . . . . . . . . . . . . . . . . . 57
3.2.3 Li-Fi based Remotely Operated Vehicle . . . . . . . . . . . . . . . 62
3.2.3.1 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.3.2 Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.3.3 Receiver (Raspberry Pi) . . . . . . . . . . . . . . . . . . . 69
3.2.3.4 Receiver (Arduino) . . . . . . . . . . . . . . . . . . . . . 72
3.3 Hardware Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3.1 Li-Fi based File Sending Application . . . . . . . . . . . . . . . . . 77
3.3.2 Remotely Operated Vehicle (ROV) . . . . . . . . . . . . . . . . . . 81
4 Project Management 85
4.1 Team Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Schedule Managment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3 Task Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4 Team Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.1 Teamwork Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5 Discussion and Results 95

5.1 Overall System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Initial Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Contents vii
5.3 Final Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.3.1 File Transfer Application . . . . . . . . . . . . . . . . . . . . . . . 97
5.3.2 Underwater ROV Application . . . . . . . . . . . . . . . . . . . . . 103
5.4 Discussion of Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.5 Project Cost and Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6 Conclusion and Future Work 110

6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2 Future Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A Pictures 113
B AFROESC manual 119
C Li Fi Compatibles manual 124
D RDL Li-Fi 136
E Instructional Manual 149
Bibliography 155
List of Figures
1.1 Diagram of proposed system for file transfer using Li-Fi . . . . . . . . . . 5

1.2 A Tethered ROV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 motiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Frequency spectral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Li-Fi vs Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Li-Fi principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Li-Fi Transmitter and Receiver block diagrams . . . . . . . . . . . . . . . 13
1.8 Li-Fi system implemented by prof. Harald Haas . . . . . . . . . . . . . . . 15
1.9 Depicts the schematic of acoustic systems that exploits sound signals to
transfer digital data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.10 depicts the acoustic communication technique (shown on the left side) and
underwater communication utilizing optical communication for enabling
underwater communication . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.11 Illustrates the inclination angle β and θ diverge angle . . . . . . . . . . . 23
1.12 The differences in the attenuation coefficient depending on the type of
water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.13 Shows the plots of Transmitted Signal Intensity Versus the Distance of
Propagation in Different Water Types. . . . . . . . . . . . . . . . . . . . . 24
1.14 Photophone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 The Transmitter side of the System . . . . . . . . . . . . . . . . . . . . . . 28

2.2 The Receiver side of the system . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Diagram explaining how the file transfer code works . . . . . . . . . . . . 35
2.4 Diagram explaining how the ROV code works . . . . . . . . . . . . . . . . 37
2.5 Diagram explaining how the propellers work . . . . . . . . . . . . . . . . . 38
2.6 The connection of the AdaFruit with the Rpi and the Motors . . . . . . . 39
2.7 Logic Level Converter pin output . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 Raspberry Pi Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Li-Fi Compatibles Components . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3 The transmitter module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 LED matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5 The receiver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Heat Gun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7 Multimeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.8 Equipment for assembling the ROV . . . . . . . . . . . . . . . . . . . . . . 46
3.9 HS-81 micro servo motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.10 Raspberry pi 2 model B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
viii
List of Figures ix
3.11 Propellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.12 Installing Pyserial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.13 Installing Pyserial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.14 The Printed Decimal Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.15 Illustrates the Pinout of the Raspberry Pi . . . . . . . . . . . . . . . . . . 53
3.16 The Connection Setup of the Servo and the Camera with One Raspberry
Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.17 Shows the Connections of Baseboard of the Li-Fi Transmitter Module to
the Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.18 Shows the Connections of Baseboard of the Li-Fi Receiver Module to the
Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.19 Shows the Internal connections of the Li-Fi Receiver Module . . . . . . . 78
3.20 Shows the Connection of the LED Matrix to the Transmitter Module . . . 79
3.21 The Overall Connection of the LED Panel to the Receiver Module . . . . 79
3.22 Config Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.23 The Steps Followed in Configuring the Receiver Module . . . . . . . . . . 80
3.24 ROV System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.25 Propellers and brushless DC motors . . . . . . . . . . . . . . . . . . . . . 82
3.26 The Main Frame of the ROV . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.27 ROV Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1 Gantt Chart depicting our schedule for the project . . . . . . . . . . . . . 87

4.2 Calendar events done on February . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Calendar events done on March . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4 The Computer Engineering Team Working on the Hardware . . . . . . . . 93
4.5 The Electrical Engineering Team Working on the Software . . . . . . . . . 94
5.1 The Code Used for Testing the Receiving side . . . . . . . . . . . . . . . . 96

5.2 ’researchdesignlab.com’ Printing . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 Communication Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4 Shows the Time Calculated to Send a Text File with Byte-array Approach 97
5.5 Text File Transmitter Code Using Encode Method . . . . . . . . . . . . . 99
5.6 Transmitter Graphical User Interface (GUI) . . . . . . . . . . . . . . . . . 100
5.7 Shows the Time Calculated to Send an Image File with Encode Approach 101
5.8 Shows the Time Calculated to Send an Audio File with Encode Approach 101
5.9 Transmitter Graphical User Interface (GUI) . . . . . . . . . . . . . . . . . 103
5.10 The ROV Moving Forward . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.11 The ROV Turning Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.12 Project Breakdown of Cost . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.1 The ROV Moving Forward . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.2 The ROV Turning Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.3 Shows Propellers Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.4 ESC connections to the ROV Battery . . . . . . . . . . . . . . . . . . . . 115
A.5 An ESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.6 Light Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A.7 ROV’s Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.8 Micro-controllers Connection . . . . . . . . . . . . . . . . . . . . . . . . . 117
List of Figures x
A.9 ROV Under Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.10 The ROV Under Development . . . . . . . . . . . . . . . . . . . . . . . . . 118
Dedicated to all our family and friends who supported us
throughout this project, and helped us to put forth our best efforts
and produce results that we are proud of. Thank you for
everything.
xi
Chapter 1
Introduction
In the near future, ordinary off-shelf light bulbs will be replaced by powerful and ex-
tremely high-tech Light-emitting-diodes LED for providing a local network for exchang-
ing data in in-door applications. This can be achieved with Light-Fidelity Li-Fi, a
technology that is aiming to reduce the pressure on the radio wave frequency spectrum
by providing users with an alternative network to send data over high range of band-
widths without reserving them. We can anticipate a wide range of applications that
can be facilitated and provided by Li-Fi everywhere around us such as: shopping malls,
educational institutes, offices, hospitals, and even air-planes. Integrating Li-Fi technol-
ogy in underwater communication systems is achievable considering the fact that water
is penetrable for optic signals. However, there are constraints in employing optic sig-
nals in aquatic environments due to power attenuation resulting from the scattering and
obstruction experienced by the optic signal as it propagates through the medium ,specif-
ically due to the presence of objects that may block the line of sight such as sediments
or marine life. Light Emitting Diodes (LED)s have the ability to change its lightening
intensity rapidly. Thus, it can be used to encode data into a serial stream of zeros and
ones at very high speeds to the receiver module/device. This is basically the principle
that Li-Fi technology is based on for sending data. Usually, preserving the continuity
of transmitting data is dependant on keeping the receiver module within a clear line on
sight with the transmitter module. Therefore, the receiver should be confined within the
Field of Sight (FOS) of the LED matrix. In some cases, this limitation will be in fact
turned into a aid for users to share data without worrying about hacking, since walls
are impenetrable for optic signals.
In this project, two application will be implemented for evaluating and characterizing
the implemented Li-Fi prototype in completely different environments. The first appli-
cation is a Li-Fi based application in which several types of files are sent as an encoded
1
Chapter 1. Introduction 2
string. The first application tested the speed and the file sizes that can be sent through
this system. Through Li-Fi based Remotely Operated vehicle application, we have in-
vestigated the possibility of replacing the tether cable, used for sending real time video
and commands, with a wire of light instead. The limitations imposed on the system is
reduction of depths that ROV can dive to.
1.1 Problem Statement
In recent years, technology has rapidly evolved, and is still evolving at a fast rate. It has
integrated with our lives immensely, as we depend on it more and more in our day to
day lives. We all own devices that are connected to each other in a great big network.
We rely on these connections to complete many tasks, and as such it has become an
essential part of our lives. This is all possible because of Wi-Fi. However, W-Fi, despite
its popularity, has its disadvantages. Because of its wide use, it may soon run out
of bandwidth, and then the demand will exceed the supply. To solve this problem, a
new technology is emerging: Light Fidelity, or Li-Fi. Developed by Harald Haas in the
University of Edinburch, Li-Fi is a new method of communication, similar to Wi-Fi,
but instead of radio waves it uses visible light to transmit data. It is a promising new
technology that, in the future, will be used alongside Wi-Fi to further improve digital
communication. In our project, we will be using Li-Fi in applications for which Wi-Fi
is not efficient enough.
1.1.1 File transfer application
All of our work is being digitized, and paper is slowly becoming redundant. It is for that
reason that instant file sending to multiple destinations simultaneously is important to
achieve. Suppose that you are giving a lecture, or a presentation, and you want to share
a documentation with your audience, or a survey. Distributing papers would not only
be inefficient and time consuming, but also a waste of resources and not environmentally
friendly. The best way to distribute such files would be digitally, and wirelessly, which
would be speedy and efficient.
Although this is already achievable using Wi-Fi, it is not the best solution for all occa-
sions. Wi-Fi has its disadvantages, such as the fact that its susceptible to interference
from other devices using Wi-Fi or operating at the same frequency. Also, Wi-Fi signals
may be intercepted and networks may be hacked. This particular fact especially could
cause issues in situations that require security. For example, an electronic exam could
require sending files wirelessly from the examiner to the examinees or vice versa. If this
is done over Wi-Fi, it could possibly allow cheating.
This problem can be solved by substituting Wi-Fi with Li-Fi, which uses visible light
instead of radio waves to transmit data. Because of that, Li-Fi does not have the
same issues as Wi-Fi concerning interference. Also, it is more secure, since light cannot
penetrate walls. This means that it can be contained within a room, and no one from
outside that room can intercept any data.
Fig.1.1 shows the overall design of the system proposed. We have a sender and a receiver,
each of whom have an interface which includes a monitor connected to a Raspberry Pi,
in order to observe and manipulate the files sent or received. On the sender’s end, the
Raspberry Pi is connected to a Li-Fi transmitter or Tx, which is connected to a LED
matrix that is used to transmit the data. On the receiver’s end, the Raspberry Pi is
connected to a Li-Fi receiver or Rx, which uses its photodiode to capture the flickering
of the LED matrix and retrieve the data, which the user can then see on their interface.
Although the figure depicts only one receiver, the final goal of this project is to be able
to send files to multiple receivers at once.
Figure 1.1: Diagram of proposed system for file transfer using Li-Fi
1.1.2 Underwater Optical Communication
There are several fields of research that are facilitated by exploiting Remotely operated
vehicles (ROVs). Archaeologists; for instance, use (ROVs) as scientific tools for locating
ancient ruins on the seabed of the ocean. At these depths, the performance of these ma-
chinery is carried out precisely and safely. Remotely operated vehicles have contributed
beyond any doubt into establishing knowledge about the locations of oil and petroleum
resources in profound and deep areas of the sea as well. The requisite Electrical power
for the operation of the ROV is usually provided through the umbilical cable. The
Remotely operated vehicle (ROV) shown in Fig.1.2 is provided with the requisite power
by rechargeable lithium batteries. The stored electrical power is not an concern since
most stored electrical power ROVs lasts for 2-3 hours.
Figure 1.2: A Tethered ROV

Tethering the Remotely Operated Vehicles provides real time control and video trans-
mission to the pilot on the surface/ship. Since the pilot of the Remotely Operated
Vehicle ROV is not in the vehicle itself, the access to the view of the rov is required
for maneuvering and controlling it. There is one problem with tethering the ROV, it
can not be moving around freely while confined with a tether cable. In some cases, the
tether cable experience an entanglement with propeller of the ship, and in worst cases
it is cut by the propeller. Incorporating light Fidelity (LiFi) technology with ROVs for
creating a Green underwater communications is one of potential application of Li-Fi
technology. In fact, there are variety of options for transmitting data in underwater sys-
tems; for instance, acoustic underwater communication systems, which transmit data
over large distances using sound waves provide wider range for transmission. Sound
waves produced by acoustic modems in underwater acoustic systems affects the living
creatures badly. Besides the fact acoustic based systems and underwater sensor based
systems too costly to be used for scientific research. Thus, utilizing light instead serves
as a cleaner and less costly alternative. This research is attempting to implement a Li-
Fi based Remotely operated vehicle (ROV) system, which is safe for transmission, not
costly, and sufficient for simple applications that does not require high level of accuracy.
For enabling Li-Fi on the ROV, a pair of Li-Fi compatibles placed at each end of the
transceiver to create a uni-directional communication link out of light. The Line-Of-
Sight needs to be maintained between the transmitter and the receiver part throughout
the transmission to reduce power attenuation. A powerful submerged Lamp is essential,
as it functions as an encoder for the information sent out by the transmitter, which is
decoded at the receiver side to its original form.
1.2 Motivation
The extensive usage of devices, which is increasing the shortage of the radio wave spec-
trum, may lead to a situation where the demand is higher than the supply. Visible Light
assimilates an enormous reservation of frequencies in the electromagnetic spectrum that
is 10,000 times the radio frequency spectrum. Light-Fidelity technology is less costly,
compared to Wireless-Fidelity, since it is based using on low-cost Light-emitting-diodes
(LED) as transmitters in addition to other low-priced electronics. Replacing radio waves
based systems with Li-fi technology will decrease the cost of the system by a factor of
10[1]. Light fidelity, which is based on visible light communication, can replace radio
frequencies in a wide range of applications to increase the efficiency of data transferal
and energy usage. The preeminent objective of this research is to increase the practi-
cality and efficiency of Wireless fidelity based applications by exploiting cost-effective
optical communication systems (Li-Fi).
Figure 1.3: Shows the Part of the Spectrum that can be Utilized to Enable Li-Fi).
In this day and age, wireless communication has become as common as electricity. We
use it in our everyday lives for various purposes. Mainly for wireless communication
we use Wi-Fi, sometimes Bluetooth. However, there are circumstances where Wi-Fi
is not entirely possible or recommended. One of such cases is sending files wireless-ly.
Sometimes you may need to share files with a large group of people in a room, such as
in an exam which is taken on computers, or in a conference. Although it is possible to
send it using Wi-Fi, security would be an issue, as radio waves can be intercepted and
hacked. It is also highly impractical to share it using wired means, as it would cause
inconvenience and waste time. Therefore, using the new and rising technology of Li-Fi
would be the best solution. It can be used to send data using visible light wirelessly in
a secure fashion, and it is also cheap to implement.
1.3 Background
1.3.1 What is Li-Fi
Li-Fi is a shortage for Light Fidelity. The idea of Li-Fi was brainstormed and introduced
by professor Harald Haas during a TED Global Talk back in 2011. Li-Fi is the application
of visible light communication VLC for transmitting data wire-lessly, bidirectionally and
at a very high speed. Li-Fi and Wi-Fi have a similar function although they differ in
the communication technology they use. The main variation point is that Wi-Fi utilize
traditional radio frequency signals in transmitting information whereas Li-Fi use the
visible light to assimilate a transmission medium.
They both transmit data over electromagnetic spectrum. The potentiality of using this
technology comes from the fact that it has a wide spectrum, which is almost 10000
times greater than the entire traditional radio frequency spectrum. Hence, Li-Fi has
tremendous capacity. On the contrary, wireless fidelity Wi-Fi has a limited capacity
due to spectrum crisis; as shown in figure Fig.1.4. In addition, Li-Fi is remarkably safer
and more secure for indoor communication due to the fact that light can not penetrate
walls.[2]
Figure 1.4: Frequency spectral

Light Fidelity Li-Fi is subset of Optical Wireless Communication. The infra-red, ultra-
violet, and visible light are all under the category of Optical Wireless Communication.
Nonetheless, Li-Fi overcomes all of them due the fact that the assigned visible light
energy for illumination could be used for communication.[2] Data is modulated with
very high speeds by changing the intensity rapidly. Afterwards, the photo sensitive
detector receives the modulated intensity of the light and decode it to series of ones and
zeros.
1.3.1.1 Li-fi vs Wi-Fi
Figure 1.5: Li-Fi vs Wi-Fi

1.3.2 Li-Fi working principle
Figure 1.6 illustrates the principle of Li-Fi. A visible light has to be generated to
transmit a constant sequence of photons due of supplying fast and slight variation of
current to the LED light bulbs. The process of emitting photons create visible light.
When changing the applied current on the LED light bulbs slightly, the strength of the
outputted light will fade up and down at a very high speeds. Led matrices are generally
noted as semi-conductor equipment. Therefore, the optical output and the current could
be modulated through very high speeds that can be detected by a photo-detector, which
is then converted once again to an electrical current (steam-able content). Practically,
the photo-detector receives both the light signals and the signal elements and converts
the data into steam-able content. The modulation process strength is undetected by
human eye; hence, visible light technique is considered as fluid as radio frequencies.[3]
Figure 1.6: Li-Fi principle
Li-Fi consists of two sections: the transmitter section and the receiver section. Trans-
mitter and receiver, they both use semi-conductor diode, light emitting and light de-
tector/sensor diode in a sequence. The process starts at the transmitter section when
the modulated signal is sent from the edge of the communication link; after that, the
receiver detects the modulated light at the other edge and decodes these digital signals
and data; in other word, it converts the modulated light back to Ones and Zeros. The
Fig.1.7 shows the Li-Fi transmitter and receiver block diagram.
Figure 1.7: Li-Fi Transmitter and Receiver block diagrams
The input data coming from the computer is first to be represented as digital signal
through converting it to binary information (Zeros and Ones bits). The input binary
data is next passing through the LED driver in which the High Illumination LED bulbs
will start irradiating ON and OFF depending on the input digital data. The data flow
could be increased through using a smaller and a faster lighting LED bulbs. The LED
flashes ON and OFF, is transmitted to the photo-diode, which functions as a part of
the receiver. Then the signal pass through a double stage inverting amplifier and its
converted to binary bits; its characterized as a weak signal. Last stage is that the binary
information is converted to the original signal, and it is read by the receiver device.[1]
1. Transmitter section: The transmitter is a part of the visible light commu-

nication that encodes data to the receiver section. The Li-Fi transmitter main
components could be propagated as the following:
Source device → Data Reading Module → Data Conversion Module → Transmitter

Module.
• Data Conversion Module: It might encrypt the data at first. It represents

the data as digital signal through converting it to binary information. Also,
it uses data micro-controllers and converters to function as modulators or
encoders.
• Transmitter Module: referring to the LED driver circuit, it produces the
corresponding ON and OFF flicking light manner for the LEDs.
2. Receiver section: The Li-Fi receiver main components could be propagated

as the following: Destination device or computer → Receiver Module → Data
Interpretation Module → Data Display (GUI)
• Receiver Module: it includes the photo-diode which is main job to reveal

the ON and OFF LED manner. After that, it translates this manner and con-
verts the received signal into binary bits, and it supports this signal through
the amplifier.
• Data Interpretation Module: with a help of a micro-controller, it can de-
tect, decodes and converts the binary data into the original signal. Referring
to the transmitter, in case of any encryption occurs there then a decryption
will take place in the receiver.
1.3.3 Misconceptions about Li-Fi
Li-Fi is a new technology developed by Harald Haas. Not many know of it as of yet, so
its only natural that there would be some myths about it flying around. Following are
some of the most common misconceptions about Light Fidelity:
1. The light flickers: this might be the most common myth about Li-Fi. When
people learn of the idea of sending data in 0s and 1s, by turning the LED on and
off rapidly, they imagine that the LEDs will flicker on and off, being a hindrance.
In fact, that is not the case, although it is not entirely incorrect. It is true that the
LED flickers on and off, but it does so in such high speeds, that it is impossible
to notice with the human eye (although still possible for a machine to notice). To
the onlooker, it will seem as though the LED is constantly turned on. [4]
2. The light needs to be turned on at all times: this is another myth that is
true to a certain extent. Since Li-Fi needs visible light to transfer data, it is true
that the LED must remain on to keep the transmission going. However, LEDs can
be dimmed down until they are so low, to the human eye it looks like it is turned
off, but the receiver can still detect it. [4]
3. Other light sources, such as sunlight, can cause interference: Li-Fi works
by turning the LED on to transmit a digital 1 and off for a 0. That is why, its
natural to believe that if there are other light sources, such as sunlight, it could
cause the receiver to believe that a constant digital 1 is being transmitted. In
fact, that is not the case. By going through a process of optical filtering, which is
fairly simple, extra unwanted sources of light can be filtered out so that there is
no interference. [4]
4. Li-Fi can only be used in one direction: some may believe that transmitting
in both directions using Li-Fi is not possible as the uplink and downlink transmis-
sions may interfere with each other, but that is incorrect. Uplink and downlink
can be separated from each other by using different wavelengths to transmit, or
various other methods. [4]
1.3.4 Harald Haas Achievement
Prof. Harald Haas has defined the Li-Fi mechanism simply by the data transmission
through LED light bulbs; noticing that when the LED is on, the transmitted digital
signal data will be one otherwise when the LED is off then the transmitted digital
data will be 0. Hence, the Li-Fi principle can simply be characterized by encoding of
data through switching the LED bulbs ON and OFF. After that data is decoded at the
receiver side to the original signal. Fig.1.8 shows the Li-Fi system implemented by prof.
Harald Haas.
Figure 1.8: Li-Fi system implemented by prof. Harald Haas

1.3.5 Optical Underwater Communication Systems
The diminution of the initial intensity of the transmitted optical signal power is resultant
from the absorption of water. The performance of the link is inversely proportional to the
distance Fig.1.13. Line-Of-Sight is One of the most prevalent myths and misconceptions
about Light-Fidelity technology. LOS links are based on preserving the direct detection
of the transmitter on the receiver side throughout the operation. It was determined in
[5] that maintaining the line-of-sight reduces the amount of attenuation in the optical
signal power in underwater mediums.
1.3.6 History of ROVs
As of yet, the vast majority of the sea world remains a mystery to us. To be precise, the
amount of the ocean world that human have explored is a measly 5%. [6] This kind of
knowledge is important to get a hold of, and it is for this reason and many others that
underwater exploration robots are essential. There is only so much that human divers
can achieve. On average, the ocean floor lies 3.5 kilometers below sea level, reaching
until a maximum depth of 11 kilometers at the Challenger Deep in the Pacific Ocean.
[7] It is impossible for any human diver to reach that far below. This is why ROVs were
invented.
There are a few different types of ROVs. These types are classified by their sizes,
uses, and the distances depths at which they can travel. The smallest of them in size,
called the Small ROVs, are used in waters no deeper than 300 meters, and can only do
surveys or similar jobs, as they only have a camera. High Capability ROVs are much
like the Small ROVs, only bigger in size, and plunge into deeper waters, up to 6096
meters deep. They are used mainly by scientists and the military, due to the fact that
they dont have many functions other than video feed. The Work Class ROVs can do
more than either the Small or High Capability ROVs can, because they dont rely solely
on electric power as the first two do, but also use hydraulic power. This gives them
the ability to do more physical work, such as lifting objects, with their seven-function
manipulator and five-function grabber. Last are the Heavy Work Class ROVs, which
are the most sophisticated type of ROVs. They are similar to Work Class ROVs in that
they use hydraulic power and can lift objects, but they include several grabbers and
manipulators rather than one, and they are more powerful than the Work Class ROVs,
having the ability to lift up to 5000 kilograms. They can also dive into a depth of 3000
meters. [8]
1.3.7 UDP and TCP Protocols
UDP and TCP are two different protocols, which are responsible for data communication
between the terminals allocated in the same IP network. The packets that are chosen to
be sent from a pc are first sent to the router and later to the marked destination. TCP
stands for Transmission Control Protocol, while UDP stands for User Data-gram
Protocol. The main difference between the two protocols is that TCP is connection ori-
ented, while UDP is connection-less. TCP protocol is used commonly in the Internet due
to its high performance in error correction; also, it guarantees the delivery. Moreover,
TCP control provides a flow control method. UDP is somehow unreliable compared to
TCP in that the receiver does not send an acknowledgment after receiving. Thus, the
sender does not wait to send the new packet. In other words, the previous shortcoming
makes this protocol easier in processing but as said its unreliable. [9]
The Li-Fi compatibles utilized in this prototype do not support sending files such as:
images, audio files, videos, etc. Thus, we had to consider studying the TCP and UDP
protocols in order to be able to design our own protocol that will support file sending.
1.4 Literature Review
1.4.1 Implementation of a file sending system using Li-Fi
Li-Fi uses light to transmit data, by using a LED as a transmitter, and a photo-diode as
a receiver. Because of the fact that it uses light, there are many benefits of using Li-Fi in
communication and data transmission over other methods such as Wi-Fi or Bluetooth.
It is for this reason that some have thought of implementing a system that can use Li-Fi
technology to transfer data. The paper by Sharma, Sanganal, and Pati proposes such a
system.[10] The system consists of several modules, which include the human interface
as well as the conversion of the data from binary bits to light and vice versa, and the
lights modulation and demodulation. The process begins with the user choosing what
file to send through the human interface. The file is then converted to bit form (binary
1s and 0s), and sent serially (one bit at a time) to a driver where there is a transmitter.
Before it can be transmitted, however, the data must be modulated. There are several
ways this can be done. The simplest one is OOK, On Off Keying. The idea is simple: 0
for off, 1 for on, and then it uses Manchester line coding. Other methods for modulation
include pulse position modulation and color shift keying. After the data is transmitted
by a LED or LED matrix, it is received by a receiver which contains a photodetector.
The signal that the photo detector gets is then put through Schmitt triggers to make
sure it is a square signal. After demodulation, the data is again transmitted serially
through an RS232 cable to another computer which receives the data. The receiving
user can then observe and manipulate the received data through the interface. [10]
For our project, we will be using Li-Fi compatibles, pairs of transmitters and receivers,
which will do all the modulation and demodulation, and the transmission and receiving
of data. Also, we will be using raspberry pis to read the data from USBs and write
them into other USBs, unlike the implementation in the paper which sends data to and
receives it from a computer through an RS232 cable. A computer monitor may, however,
be used, or any monitor, as well as a keyboard and a mouse, as a user interface.
1.4.2 Implementation of file sending system using Wi-Fi
USB flash driver is the most used device for transferring files and data, but it has
some disadvantages as it takes time because of having each file individually from each
computer. Moreover, a network access is needed in order to collect an e-assessment in
educational institutions; which lead the students to get information or answers from
online sources, so many educational institutions refuse relying on the computer based
examinations. Therefore, a system is made in order to transfer a multiple of files between
more than one USB drive without the need of personal computer or LAN/WAN access.
This system consists of an embedded system and a mobile application. It uses the
VDIP2 module with VNCL chip, and the communication is done using UART protocol
between the device and the USB flash drive. Furthermore, a small keypad is provided in
order to do the data process, which is displayed on an LCD screen. Its transaction for
the data access is secure and safe because it has an alternate authentication and a key
agreement. This system has a disadvantage in the hardware side as it uses keypad and
switches, which make it difficult to use. By using the embedded system with the mobile
application, it provides exchanging data between a big numbers of USB flash drives at
the same time. Moreover, the mobile application is used in order to show the content
of the USB drive for the user, where the user can cut copy or delete any number of files
or folders in an easy way to use. Accordingly, The mobile application shows the name,
size, and the last modification of the file or folder; it can be used to manage the files
that are in the USB flash drives. The embedded server board can communicate through
Wi-Fi network, which is made by the server board itself, and by a wired connection just
in case the Wi-Fi was disconnected. It has four ports where the user can plug in up to
four USB hubs in order to accept a big number of USB flash drives. Furthermore, it
contains a rechargeable battery, and a Wi-Fi dongle for setting a private network. The
system is secure and safe because the user can only view the files or folders and cut,
copy, paste, or delete them from the mobile application without editing or viewing them
as the description of the files are sent in a JSON form to the mobile application. [11]
1.4.3 Acoustic and optical underwater systems working principle
Communication using Radio Frequency is efficiently transmitting data at high speeds

in the air. Water impedes radio communication in underwater environments because it
absorbs radio-frequencies . In the visible light band, water is translucent and considered
penetrable for optic signals. Fibber optics cables is used in undersea environments for
exchanging data (telecommunication) at high data rates, but they are costly for discovery
journeys.[12]
Thus, researchers have developed alternative systems that enables data transferal in
underwater environments without the need to use radio waves, which are unsuitable for
this application. Light fidelity is one of the solutions provided to exchange digital data
through aquatic mediums by manipulating the intensity of the submerged lightening
source.For the purpose of exchanging data between the remotely Operated Vehicle
(ROV) and the human interface controlling it, a tether is used to connect ROVs and
their pilots.
There are two classifications for tethers: umbilical cables, and tether cables. Tether
cables are used to supply power to the ROV, and it is translated to amp-here values on
the ROV side.[13]
On the contrary, acoustic underwater systems are based on sending digital data from the
pilot to the ROV by employing sound waves instead optic waves. Modems are employed
in the acoustic systems to transmit data as depicted in Fig.1.9.
Figure 1.9: Depicts the schematic of acoustic systems that exploits sound signals to
transfer digital data
On the contrary, acoustic underwater systems are based on sending digital data from the
pilot to the ROV by employing sound waves instead optic waves. Modems are employed
in the acoustic systems to transmit data.
1.4.3.1 Under Water Systems: A comparison between Underwater Acoustic

systems and Optical systems
The optical underwater systems, also known as Free-water optical systems. In these
systems, optical links are utilized instead of acoustic links as well as water being a
transmission medium instead of free-space. In the visible band, light ability to penetrate
water will be limited by the depth. The range of meters that light can penetrate will
not exceed hundred meters. In addition to the depth, the turbidity, the existence of
suspended residuals, and marine creatures in water will result into less penetration of
light in the environment. Acoustic communication technique can be used to increase
the distance (depth), however it has a considerably high latency. A modem is used
in the acoustic systems to transmit data at frequencies ranging from 100 to 5000 bits
per second, and this ranges increase for short range communication systems. Acoustic
systems provide wider range for transmission of few Kilometres compared to optical
systems that can reach 100 meters only. On the other hand, optic systems data rates can
reach up to 1Mbps, which is 1000 times the data rates provided by acoustic systems. In
fact, creating optical links instead of acoustic links will boost data rates of the undersea
system to up few Mega-bit-per-second higher than 10 Mbps. Thus, the replacement of
the acoustic modems with optical modems provides high data-rate transmissions while
using energy more efficiently. The measurement of the distance that informs us about
the depth that the intensity of the water decreases exponentially is the e-folding. The
value of the e-folding varies in different water environments depending the clarity of the
water. In the green-blue band of the visible band, the e-folding value reaches (400-500)
Nano-meter, and this value can be estimated by 20 30 meters. The higher data rates
facilitate working on depths, which are times the e-folding values. [12]
Figure 1.10: depicts the acoustic communication technique (shown on the left side)
and underwater communication utilizing optical communication for enabling underwa-
ter communication
1.4.4 Line of Sight for underwater optical communication
The power attenuation is a fundamental factor in the comparison between acoustic and
optical underwater systems.
1.4.4.1 Optical Systems
Optical signals power that reaches the receiver side of optical systems in underwater
mediums is illustrated in the following equation:
2 ∗ PO ∗ Ar ∗ cosβ
power = .e−(α)t (1.1)
π ∗ L2 ∗ (1 − cosθ) + 2 ∗ At
1. Ar : Representing the area of the receiver.
2. At : Representing the area of the transmitter.
3. β: Inclination angle to the receiver.

4. θ: Half of the transmitter field-of-sight.
5. L: Distance to the receiver.
Fig.1.11 models a transmitter A and a receiver B in an optical system, where transmitter

A exploits a Light Source to transmit data to receiver Fig.1.11 models the inclination
angle θ and the diverge angle θ. The model depicts transmitter A with a beam diverge
angle of θ. The previous equation is resultant from research and simulations for imple-
menting an optical system using an AUV. Fig.1.11 models the inclination angle θ and
the diverge angle θ. The model depicts transmitter A with a beam diverge angle of
θ. The divergence of the receiver from 45 degrees from the mid-point of light beam
source increases the attenuation in the power of the optical signal that travels in water.
When the receiver is in line-of-sight with the transmitter, the attenuation is the least.
The field of sight of the Transmitter is represented by θ. In fact, theta denotes only half
of the range of sight of the transmitter. The beam of the light is either concentrated,
or with wide beam divergence angle. The wider the divergence θ angle, the larger the
attenuation of the optical signal. [5]
Figure 1.11: Illustrates the inclination angle β and θ diverge angle
The power of the optic signal at the receiver side can be calculated by the following
equation:
I = Io e−cd (1.2)
The value of attenuation coefficient c differs depending on the type of water that the
optical signal is travelling through. The distance between the transmitter and the re-
ceiver is denoted by ”d”. The initial intensity of the sent signal is represented by ”IO ”.
Fig.1.12 shows the attenuation coefficient values c for different types of water. The
attenuation coefficient c increases in value as the turbidity of water rises. For instance,
the attenuation coefficient of harbor water is the highest, since there is an abundance of
algae, sediments, and marine life. This deduction is in consonance with [5] simulations
plots shown in Fig.1.13. The intensity of the optical transmitted signal IO is prone to
be attenuated significantly in shorter distances. The effective range is inversely propor-

tional to the turbidity of water. Thus, it can be deducted that the pure water is the
most suited for reducing the attenuation as illustrated in Fig.1.13.
Figure 1.12: The differences in the attenuation coefficient depending on the type of
water
Figure 1.13: Shows the plots of Transmitted Signal Intensity Versus the Distance of
Propagation in Different Water Types.
1.4.5 Photophone
Even though Harald Haas has recently started using visible light as a substitute to Wi-
Fi, with his new technology Light Fidelity (Li-Fi), he was not the first person to use
light in communication. This fact is not known by many, but some years after inventing
the telephone, Alexander Graham Bell, created a device similar to it. With the help
of his lab partner Charles Sumner Tainter, he invented what he himself claimed to be
his most important invention of all: the photophone. [14] The photophone achieves the
same goal as the telephone, which is carrying sound over large distances. However, the
photophone manages to accomplish this wirelessly. As with the new Li-Fi technology,
the photophone uses visible light as a transmission medium. However, since kerosene
lamps were inadequate, it used sunlight. [14] The photophone consists of a transmitter
and a receiver. The transmitter is made of a parabolic mirror, onto which the sunlight
was directed. The light is then modulated by the vibrations on the surface of the mirror,
which are caused by the speech or sound to be transmitted. After that, the modulated
light is sent to the receiver side, which consists of a selenium cell. Selenium is a material
sensitive to light. [15] In the photophone, it is used to turn the light back to speech.
[14]
Figure 1.14: Photophone
1.5 Economic Impact Statement
Li-Fi technology is a low-cost alternative to the available base stations which have power
consumption that reaches up to a multiple of Giga-watts. Base station are not just costly,
they are also considered non-efficient in terms of energy consumption. Li-Fi technology
will reduce the number and the cost of requisite base stations significantly as it is based
on cheap low cost Light Emitting Diodes LED as transmitters, though it can not replace
them completely yet. If the available infrastructure and ordinary off-shelf light sources
are replaced with Li-Fi Light emitting diodes LED, hot-spots can be provided for users
in indoor systems.
1.6 Society Impact Statement
Wireless communication has become a necessity as electricity nowadays. Human being

require its services for meeting the demands of their everyday lives. Mainly for wireless
communication, Wi-Fi is used and the consumption is increasing at high rates leading
to a shortage in the bandwidths that can be reserved and provided for each application.
Thus, Li-Fi has came to stand alongside with Wi-Fi for reducing the pressure on the
radio wave spectrum considering the huge reservoir of unused frequencies of visible light
that is 10,000 times the radio wave spectrum. A combination of wave lengths can be
utilized for providing users with diversified potential speeds. In addition to that, Li-Fi
can guarantee for users that no one outside the room can hack the data that they send
through Li-Fi, since light signals can not penetrate walls.
1.7 Environment Impact Statement
Li-Fi is an optical wireless communication that uses light to transmit data, which make
it a green wireless communication. It does not lead to any electronic waste as it needs
only few various pieces of equipment that are not significantly expensive and available
to public. It requires only a LED bulb and a photo detector or a solar cell. If a solar
cell is utilized, any energy consumption will not be required; hence, it will not affect the
environment. Li-Fi can equip people with an alternative for Wi-Fi, which can provide
them a network for exchanging data with potential speeds that are faster than Wi-Fi.
Moreover, Li-Fi does not have adverse effects on our health, since it uses light unlike RF
wave systems that are hazardous to our health.
1.8 Report Outline
Chapter 2 presents the problem description and the designs we have came up with for
the two Li-Fi based applications. Continued with a detailed description of the imple-
mentation and testing procedures of the hardware and software parts of the prototypes.
A brief introduction of each team member, weekly reports, and work distribution is
given in chapter 4 followed up with the discussion and results, then conclusions and
recommendations.
Chapter 2
Design
2.1 Problem Description
This project intends to investigate the applicability of Li-Fi technology in two distinct
mediums in which data carrying light (D-light) can propagate through. Specifically,
studying how efficiently data is transferred through light in aquatic and non-aquatic
mediums. For this reason, we have implemented two applications based on Li-Fi and
established system evaluation criterion based on the time interval required for data to
be received at the receiver side. In order to understand the limitations imposed by the
medium where Li-Fi is used, we have studied the nature of light and the possible imped-
iments in these environments through literature review of preceding related researches.
Through literature review, we have also obtained the requisite knowledge about the
working principle of Li-Fi, which helped in establishing the file-sending protocol that we
developed. Establishing the file sending protocol formed the basis from which the design
of the two Li-Fi based applications was initiated. Considering the combination of elec-
trical and computer majors of the team members, we were divided into two sub-teams.
Each team consisting of an electrical and a computer engineering students worked on the
design of separate parts of the applications. The two sub-teams worked in parallelism
on tasks requiring both programming and electrical engineering skills, which ensured
the full participation of each team member as well as the exchange of knowledge and
experiences between them.
2.2 Model and Testing
Figures 2.1 and 4.5 represent the fundamental components of Li-Fi based systems con-
sisting of a Transmitter (Tx ), Receiver (Rx ), LED Panel (LP), and a Photo Diode (PD).
27
Chapter 2. System Design 28
The input/output model of the system includes a graphical user interface that displays
a window after running the transmitter code, which enables the users to choose the type
of files/ commands to be sent. The Transmitter/ Receiver models shown in Fig.2.1 and
Fig.4.5 are identical for the Li-Fi based File sending/ Remotely Operated Vehicle ap-
plications. The difference between the two systems is that the output of each system is
changing upon the type of input sent through the transmitter module. Specifically, the
output of the File sending application is a reconstruction of the sent file on the receiver
side, whereas the output of the Li-Fi based Remotely Operated Vehicle ROV is a re-
construction of the sent control command, which will maneuver the ROV accordingly.
At the Transmitter side, the chosen file is split into bytes, and each byte is encoded as
a 6 bit string. The file is then encoded to a stream of binary 1 and 0 through a LED
driving circuit which manipulates the intensity of the LED panel accordingly.
Figure 2.1: The Transmitter side of the System
On the receiver side, the changes in the intensity of the LED matrix is captured by a
photo-sensitive diode. The photo-sensitive diode will be interested in the high expedi-
tious frequencies of light sources and low frequency light sources is overlooked.
The testing process has been carried out in several phases, which followed the imple-
mentation or acquisition of each component as follows:
Figure 2.2: The Receiver side of the system
2.2.1 Li-Fi compatibles
In this phase, we have tested the transmitter and the receiver modules separately.
Initially, the ability of the transmitter module to encode files as a stream of zeros
and ones is tested using a basic code saved in nano text editor and run in
the Terminal of the raspberry pi. In this code, a file is converted to bytes array
and sent serially while applying a significant delay between each bit in order to
slow down the speed of LED matrix switching. Through this phase, we have
inspected the synchronization of the parallel LEDs, and the ability of sending
files through the Li-Fi Tx compatible module have been verified. 2.2.2 File
sending application Testing Plan
(a) Phase One: Wired Connection For developing the file sending protocol,
a wired connection has been established between two raspberry pi controllers
as UART devices.
• Sending a File as a Byte Array: Pyserial sends data between serial

devices in the form of string bytes. Initially, we attempted to break a
file into its corresponding binary bits. Then, we tried transmitting the
binary data which the file consists of as byte by byte. This approach has,
in fact, slowed down the transmission rate of data by 8 times, because
each single bit was sent as a byte. Hence, byte array method sends each
byte as 8 bytes.
• Base64 Encoding: In pursuance of increasing the transmission rate of
the developed protocol. Even though we were successful in sending text
file and image files between the raspberry pis by the previous method, the
transmission speed of files at this point was unsatisfactory. Therefore,
base64 encoding for encoding data has been used instead. The reason
for adopting base64 encoding method is due to the fact that it transmits
each 3 bytes as 4 bytes, which is still faster than the byte array method.
(b) Phase Two: Testing Over Li-Fi: In this phase of testing, a Li-Fi transceiver
has replaced the wired connection for establishing the serial communication
between the two raspberry pis. The prefabricated Li-Fi compatibles are
UART devices, which require powering them with the 5v, 3.3 v pins and
connecting them to the UART pins of the raspberry pi for enabling file
transfer serially over UART and by using light fidelity.
(c) Phase Two: Testing Over Li-Fi underwater: Through this phase, we
have tested the ability of sending files using the File sending protocol in un-
derwater environments. Specifically, this phase has been a a verification of
capability of sending commands to the Remotely Operated Vehicle ROV un-
derwater. For achieving this, we have submerged the Li-Fi compatible RX
module in a waterproof enclosure after configuring the module to receive at
a certain distance from the LED Matrix, which was placed above water. As
expected, even in underwater environment the file has been received success-
fully and without any significant difference in the time of reception from the
trial of sending the same file above water.
2.2.3 Li-Fi Based Remotely Operated Vehicle Application Testing

Plan
(a) Phase One: Wired Connection At the beginning, the software cod-
ing and electrical connections of each and every electronic component of the
Remotely Operated Vehicle (ROV) have been tested independently in con-
sideration of making troubleshooting for errors easier.
• Servo Motor and the Camera: The first part that we have worked
on for our second application is the camera and the servo motor that
changes its position along a semi-circular path on the ROV cylindrical
frame. For powering the servo up, we have connected the servo motor
to the 5v and ground pins of the raspberry pi. Servo motors depend on
pulse width modulation signals for changing its position. The control
line pin is connected to GPIO 18 pin. Initially, the camera of the ROV
and the servo motor were tested and programmed on a single raspberry
pi. After developing the code that control these parts, we have worked
on sending control commands of the servo motor and the camera to an-
other raspberry pi, again over UART. Sending these control commands
is particularly based on the same principle of encoding data using base64
encoding method, which is utilized in the file sending protocol as well.
The difference here is that what we are encoding is control commands.
• Propellers and Electronic Speed Controllers: The propellers of the

Remotely Operated vehicle are mounted on brush-less DC motors that
require external hardware for controlling their speeds and directions as
servos. At the beginning of this phase and before testing the hardware,
the code where a control commands is transmitted between one raspberry
pi to another pi connected to it through wired UART is developed. when
a key press is detected on the keyboard using Tkinter key bind method,
a control command representing the key press will be transmitted con-
tinuously to the receiver pi until a key release on the transmitter pi is
detected. At this point of protocol development, we have verified the re-
ception of states on the receiver side by printing the name of commands
sent through the transmitter pi on the receiver pi.
Afterwards, a brush-less DC motor has been tested on a single raspberry

pi by using pigpiod library of the raspberry pi that was unsuccessful in
rotating the brush-less dc motor. At first, we have tried controlling the
Electronic speed controllers, which control brush-less dc motors by using
servo signals and by varying the pulse width of the pwm signal com-
ing from the control line pin to the ESC. Electronic speed control start
peeping after being powered on without receiving an input for 8 seconds
indicating that it is actually disarmed. After running the requisite com-
mand for arming the esc on the terminal of the raspberry pi, the ESC
kept peeping pointing out that it is not getting a sufficient input. This
can be explained by the fact that ESC was never provided with sufficient
pwm voltages through the raspberry pi control pin. There have also been
several attempts to improve the accuracy of the pulse width modulation
signals by using Adafruit 16 bit channel, which was also a failed attempt
for the same exact reason. The voltage coming out of the raspberry pi
control pin is 3.3 v.
This has given rise to thinking of an alternative for controlling the ESCs.
After comparing the signals coming out of the pwm pins of the Arduino
Uno and the Raspberry pi using the oscilloscope, we have deduced that
raspberry pi pwm pins provide up to 3.3 volts, which is incapable of con-
trolling the ESC that requires 5 volts signals without external hardware.
In the end, we have established i2c connection between the arduino uno
and the raspberry pi as a solution that could have been improved by
using external circuitry for increasing the range of pwm signals of the
raspberry pi instead.
(b) Phase Three: Testing The Propellers Underwater In this phase of

testing, the motors have been calibrated to rotate at certain speeds and di-
rections in accordance to the control command sent from the pilot to the
Remotely Operated Vehicle (ROV) after submerging the main frame in wa-
ter. In this prototype, the receiver module consists of a raspberry pi/ Arduino
micro-controllers connected in a master-slave configuration through i2c com-
munication. Initially, calibrating the motors has been done through wired
connection between the transmitter and the receiver. Replacing the wired
connection with Li-Fi transceiver is the sub-sequential step to the wired test-
ing where the efficiency of Li-Fi in underwater mediums is evaluated.
(c) Phase Two: Testing Over Li-Fi: Sending commands serially between two
raspberry pis was tested over wired connections during the development phase
of each component. In this phase, as well, wired connections were omitted
from the prototype as soon as we obtained the requisite performance of the
propellers.
2.3 System Architecture
Our design project consists of two applications, the first one is a file transfer application
which consist of two sides, a transmitter and a receiver. The transmitter side consists of
Li-Fi compatible with a raspberry pi and LED matrix that transmits data by blinking
on and off to represent a binary of 1 and 0 respectively. The receiver side contains
another Li-Fi compatible with another raspberry pi that has a photo sensor, which is
replaced on top of it in order to detect the high frequency blinking of the LED matrix
that shines on it. It decodes a binary one when it is turned on and zero otherwise.
Moreover, for interface access, we have designed a Graphical User Interface (GUI to
be enable users to select the desired files that they want it to be sent. For our second
application, the communication system is based on a transmitter module for routing
control commands to a ROV, which contain Raspberry Pi and an Arduino that controls
the ESCs for controlling the propellers. Furthermore, the Raspberry pi is connected to
the camera and the servo that is responsible to move the camera.
2.4 Code Design
The project is made up of 2 main parts, which are the 2 applications that employ Li-Fi:
file transfer, and control of an underwater ROV (Remotely Operated Vehicle). For both
applications we used raspberry pis and readymade Li-Fi modules which are compatible
with raspberry pis. We used the raspberry pis to control what we wish to transmit over
Li-Fi, and then sent that data to or received it from the Li-Fi modules serially through
UART communication. The programming language we used for both applications was
python v2.
2.4.1 File transfer application
The application consists of a transmitter side and a receiver side, and there is a program
for each side. The process that the file goes through to travel from the transmitter
device to the receiver device is shown in figure 2.3. The first step is for the user to
choose the file they wish to transmit. When the code is run, a graphical user interface
(GUI) window will appear, which contains a browse button, radio buttons with which
the user determines the file type, and a send button. Once the file and file typeare
chosen, the user should press send, and the program will begin the transmission process.
It begins with encoding the data using base 64 encoding. This will transform the file
data into a string that can be transmitted over UART using the pyserial library. This is
necessary because the raspberry pi can only transmit data in string form, one character
(byte) at a time. This will also cause the file to increase in size, as base64 encoding
transforms each 3 bytes into 4 bytes.
Next is the transmission of the file, as well as the file type and the file length, which is all
necessary information for the receiver to know what to do with the data it is receiving.
First, a number will be transmitted to indicate the file type: 1 for image, 2 for text, and
3 for audio. Next is the length of the file, which is the number of bytes in the array of
strings (encoded file). Finally, the array of strings will be transmitted byte by byte. All
of this transmission is done by the i-Fi transmitter module, through the LED matrix,
and received by the photodiode on the Li-Fi receiver module.
Figure 2.3: Diagram explaining how the file transfer code works
The receiving raspberry pi will store the values of the length and file type, and then
loop to receibe the array of string. It will know the number of times it must loop, which
is the length that it received. After it has the entire encoded string, it will decode it
to regain the original file. Then, it will save the file according to the file type, with the
correct extension (png for image, txt for text, and mp3 for audio).
2.4.2 Underwater ROV Application
A a user- interaction unit (UIU) is designed to transmit the desired controls to the
remotely operated vehicle ROV from the transmitter module Tx to the receiver module
Rx . The transmitter module encodes the control commands inputted through a graphical
user interface GUI by manipulating the lightening intensity of a LED Panel LP to a
sequence of zeros and ones at high speeds representing the command chosen. The photo-
diode PD in the receiver module Rx observes the illumination intensity of the LP and
decodes it back to the sent encoded sequence of zeros and ones. As for this application,
the process of sending data is similar. However, in this case, what is transmitted is not
a file, but commands to control the ROV. There is also a receiver and transmitter, but
the receiver is not only a raspberry pi. It is a raspberry pi and an Arduino connected
together over I2C. Arduino is used to control the propellers of the ROV, while the camera
and the servo that moves the camera are controlled directly by the receiver raspberry
pi. Fig 2.4 shows the way the program works.
On the transmitter side, the camera and its movement are controlled by the user through
a GUI which contains a slider and a button, as can be seen in fig 2.4, while the general
movement of the ROV is controlled by keyboard keys. When a user changes the posi-
tion of the slider, ”1” is transmitted. When the user presses the snap button, ”2” is
transmitted. When the user presses the WASD keys, ”f”, ”l”, ”b”, or ”r” is transmitted
and when the user releases any of these keys, an ”i” is transmitted.
On the receiver side, first we have a raspberry pi which acts depending on the value it
receives. If it receives a ”1”, it will proceed to receive the duty cycle and change it for
the servo. If it receives a ”2”, it will proceed to take a picture using the USB camera
and save it on the desktop. If it receives any of the letters, it will transmit it to the
Arduino over I2C.
The Arduino will receive these messages and change the speed and direction of the
brushless DC motors accordingly. If it receives an ”f”, it will go to the Forward state.
”b” will make it go to the Backward state. ”l” will make it go to the Left state, and ”r”
will make it go to the Right state. Also, if it receives an ”i”, it will go back to its inital
Idle state.
Figure 2.4: Diagram explaining how the ROV code works

The remotely operated vehicle ROV utilizes a single vertical and two lateral propellers
mounted on brush-less dc motors to move the ROV to right, left, forward, backward,
upward, and downward. The controller board of the ROV controls and coordinates the
speed and the direction of the propellers to achieve the desired control command chosen.
For instance, so that the user can drive the ROV to move forward, the horizontal star-
board and port motors should be driven to rotate with opposite directions. Supposedly,
In case the user commands the ROV to move backwards, both the starboard and the
port propellers will move reversed directions to that in the forward motion. By pressing
the right button on the graphical user interface (GUI), the port propeller will be pushed
with forward rotation with higher speed than the starboard propeller. Thus, this will
move the ROV to the right as long as the user presses on the right button on the UIU.
The same principle is applied for turning the ROV to the left, where the starboard
propeller rotates forward while having the lower speed of rotation of the port propeller.
Figure 2.5: Diagram explaining how the propellers work

2.5 Model Design
2.5.1 Failed Attempts
2.5.1.1 AdaFruit
The propellers part of the Rov Kit came on top of our struggling list, since brush-less
DC motors are a fairly recent arrival. Also, we had never worked with such a motors
model before. The brush-less DC motors need an Electronic Speed Controller ESC to be
able to change the speed and the direction of the propellers. ESCs has a combination of
hardware and a special firmware inside each IC that has different models and purposes.
The ESC receives a PWM input and based on it, it calibrates. As a first attempt
we thought of using an AdaFruit controller that creates a wider and more accurate
range of PWM compared to what is given by the Raspberry Pi. The connection was
made as shown in Figure2.6. But inappropriately we couldnt get any results out of this
connection, without getting a clear clarification of why does not it work.
Figure 2.6: The connection of the AdaFruit with the Rpi and the Motors
2.5.1.2 Logic Level Converter
The Open ROV Kit v2.8 comes with an Arduino controller board. We soldered the
ESCs with the propellers and connect them through an Arduino Uno, and we run a
basic code. We achieved the task and the propellers worked. Later we had to see the
difference that made it work through the Arduino and not the Raspberry Pi. After
experiments and researches about the Raspberry pi Gpio and pin out nature through
measuring the output signal, we found that the signal pins in the RPi delivers a 3.3 V
while the Motors need at least 4.7 V to calibrate.
Consequently, we got a Logic Level Converter to avoid using an Arduino, to minimize

the waste of power and cost. The Logic Level Converter is a device that aims to step up
the input signal from 3.3 V to 5 V and does the opposite. We applied the connection
shown in Fig.2.7 in which we connected the signal pin to the low voltage pin in the Logic
Level Converter, and we connected the high voltage pin in the Logic Level Converter
to the signal line in the ESC. Also, we had a common ground between the ESC, Logic
Level Converter, and the Raspberry Pi. and we connected the 5 V pin in the RPi to
the high voltage pin in the Logic Level Converter, and the 3.3 V pin in the RPi to the
low voltage pin in the Logic Level Converter, as a reference voltages. Up till now the
we did not receive any output. Although that the measured voltage coming to the ESC
was 5 V which is required to run the simulation. But we found out that the Logic Level
Converter is only raising the voltage and not the current. Subsequently, we ended up
with the same issue, but this time with the lack of current.
Figure 2.7: Logic Level Converter pin output

Chapter 3
Implementation
3.1 Components
We have used different type of components to accomplish this project, which are de-
scribed below: The main things that we have used for our two applications are:
• Raspberry Pi: is tiny computer that has the size of a credit card, basically designed
for education. Nevertheless, it has an awesome functionality, and it has everything
a normal computer has such as a processor, RAM, USB port, HDMI, and audio
out. It has also GPIO pins that allow working directly with circuitry; however,
it is not powerful as a laptop or a desktop computer because of its small size. It
can be plugged into a monitor or a TV for display using HDMI cable; moreover, it
can be used for multiple tasks such as doing some documents editing, playing HD
video, playing games, browsing Internet, doing projects, and many other things.
Raspberry pi was introduced on 2011, but it was released on 2012 in the UK. There
are different models of it; for example, Model B rev1, model B rev2, and model A
rev1. However, the one that we are going to use in this project is Raspberry pi 2
model B; it has RJ45 Ethernet socket, two USB sockets, micro SD slot, and 512 MB
RAM memory. A 5V micro USB power supply will be used in order to power the
RPI. It is recommended to use 8GB micro SD as minimum size, so we can install
more packages. There are various operating systems that can be installed in order
to control. We are going to use Raspbian that is based of Debian. It it is the
main operating system and its recommended distribution of Linux. Furthermore,
there are other operating systems that can be install namely Ubuntu Core, Ubuntu
mare, NOOBS, and much more. Raspberry pi can be detected through network,
so it is better it secure it. We have to change the username and password because
all the RPIs have them in common. Username: Pi, Password: raspberry. We
42
Chapter 3. System Implementation 43
can use different programming languages such as Python, C, C++, Scratch, or

Ruby. To control it we will have any standard keyboard and mouse plugging them
in the USB sockets. Moreover, if we want additional USB socket, we can use
powered USB hubs. The specifications of the Raspberry Pi are shown in figure 3.1
below.[16]
Figure 3.1: Raspberry Pi Specifications
• Li-Fi Compatibles: It is a ready-made Li-Fi circuit and consists of a transmitter

and a receiver. The transmitter is connected to a LED matrix, which sends data
by turning it on and off to represent a binary 1 and 0, respectively. The receiver
contains a photo sensor which gives a binary 1 when the LED matrix shines on
it, and a binary 0 otherwise. Fig.3.2 shows LiFi Visible Light Communication
Compatible structure.[17]
Figure 3.2: Li-Fi Compatibles Components
The Li-Fi compatibles are two sides. First the transmitter that transmits the data
to the receiver side shown in figure 3.3 which is connected with the LED shown in
3.4 .
Figure 3.3: The transmitter

module Figure 3.4: LED matrix
Second, the receiver side which contains the photo detector, which detects the
light that is emitting from the LED matrix that is connected with the transmitter
shown below in figure 3.5
Figure 3.5: The receiver module

3.1.1 File Transfer
For the first application we used only two Raspberry Pis and the Li-Fi compatibles.
3.1.2 Underwater robot
For our second application we have used multiple items to assemble the robot and then
to function it. The components that we used for our next application are shown in
figures below. First, the Heat gun was used to melt the heatshrink and protect the
wires from shorting.3.6, we used a Multimeter 3.7 to measure the voltage or current
and check the power of the batteries, Acrylic Cement, devecon epoxy, LiCB charger and
another equipment used in assembling the ROV shown in 3.10, and the servo motor was
used to move the camera angle of 180 degrees 3.11. 3.8 shows the Raspberry pi’s which
are the main controllers of our system, and last are the propellers that are mounted on
Brush-less DC motors, it is for controlling the movement of the ROV 3.9.
Figure 3.6: Heat Gun

Figure 3.7: Multimeter
Figure 3.8: Equipment for assembling the ROV

Figure 3.9: HS-81 micro servo motor
Figure 3.10: Raspberry pi 2 model B

Figure 3.11: Propellers
3.2 Software Implementation
3.2.1 Li-Fi Compatibles Configuration
The Li-Fi compatibles require configuring it as follows:
1. First and foremost, the python serial package (pyserial) should be downloaded
and installed from: https://pypi.python.org/pypi/pyserial
2. Then, the downloaded package was unzipped

cd pyserial -2.7
3. For installing the software, the following command is written in the terminal as
follows:
sudo python setup . py install
4. For testing the Li-Fi boards, the modules were connected to raspberry pi 2 model
B where the following code is saved in the Nano text editor as (filename.py) to
test the receiver module.
Figure 3.12: Installing Pyserial
import serial
ser = serial . Serial ( ’/ dev / ttyAMA0 ’ ,38400)

while True :
p = ser . read ()
print p
5. The code is run by writing the command in the terminal of the raspberry pi:
sudo python filename . py
6. Afterwards, we pressed on the switch S2, which generated the following on the
terminal.
7. The previous step illustrated in Fig.3.13, did not give a clear indication whether
the Li-Fi receiver module is properly receiving. As a result, we have established a
testing method where the capability of the transmitter module to actually transmit
data is verified. After verifying the Transmitter performance, we ran a test where
receiving an uncorrected file is evaluated.
Figure 3.13: Installing Pyserial
3.2.2 File Sending Protocol
3.2.2.1 Experiment One: Transmitting Bytearray
Initially, we converted a file to an array of bytes using the built-in function bytearray on
the transmitter side, which is printed to show the outcome on the receiver side following
the steps:
elements = open ("\ home \ pi \ Desktop \ file \ txt " , " rb ")
# create bytearray from list of integers
values = bytearray ( elements . read ())
# Display bytes
for x in values :
print ( x )
import serial
ser = serial . Serial ( ’/ dev / ttyAMAO ’ , 9600)
while True :
p = ser . read ()
print str ( p )
1. We set up serial communication by importing serial library and the serial port
(ttyAMAO) to have a baud rate of 9600.
2. The receiver will read what’s sent to the port set up in the previous step and will
print it as a string.
3.2.2.2 Experiment two: File Sending Protocol
The prefabricated Li-Fi compatibles code are insufficient for sending files such as: text
files, images, or audio files. Therefore, for achieving the objective of sending files using
raspberry pi Li-Fi compatibles, we developed our own protocol that enables the user
to select the desired file through an interface window. Then, the file is encoded by the
transmitter TX that manipulates the intensity of the LED matrix. The receiver side
will detect the blinking of the LED matrix and decode it to recreate the sent file. The
process of developing the protocol is as follows:
1. First of all, we wrote ABC112233 in a new text file and saved it in the Desktop
of the raspberry pi as file.txt.
2. The nano text editor was then accessed by writing the command sudo nano
test.py at the command prompt.
3. Afterwards, we specified the file to be opened in the nano text editor with the
command open(’/home/pi/Desktop/file.txt’, ’rb’), which requires the file
path and location in the raspberry pi.
A file object is created by the open function, and the mode specified in this case
is read (denoted by ’r’). In addition to ’r’, b was adjoined to ’r’. We wrote ’rb’
reads the file in binary mode. [18]
4. Next, the built in function bytearray is used to return the bytes of the data
containing that file. Then these bytes were printed with the print command as
depicted in Fig. The returned bytes sequence from this function have the range
from 0 to 256 as follows in Fig.3.14.
Figure 3.14: The Printed Decimal Bytes
3.2.2.3 Experiment Three: Sending Text file as byte arrays
The preceding steps in section 3.2.2.2 were carried out for testing the functionality of
the built-in bytearray function. In this section, we setup a wired connection between
two raspberry to establish a serial communication and to exchange data serially by using
pyserial module and serial pins located as follows in Fig.3.15.
1. First of all, we made sure to disable the serial port login in order to enable using
the serial port for enabling serial communication between the two raspberry pis,
since the Li-Fi compatibles send data serially. The serial port in raspberry Pi is
already used for console terminal port, hence we needed to disable it before using
it. [19]
2. In order to connect two raspberry pis serially, we connected the UART Tx (pin
8) of the first raspberry pi to the UART Rx (pin 10) of the second. Then, we
connected the UART Tx (pin 8) of the second raspberry pi to the the UART
Rx (pin 10) of the first raspberry pi. The ground pin of each raspberry pi should
be common to and connected to the other raspberry pi.
3. After configuring the physical connections, the serial ports has to be accessed by
import serial provided by Pyserial library.
4. The requisite file to be accessed is specified by open(File path, ’rb’) and saved
in variable elements as discussed previously in section 3.2.2.2.
Figure 3.15: Illustrates the Pinout of the Raspberry Pi
5. The contents of the specified file are read and converted to byte array with the
function bytearray(elements.read())
import serial
elements = open ( ’/ home / pi / Desltop / image ’ , ’rb ’)
values = serial . Serial ( ’/ dv / ttyAMAO ’ , 9600)
print len ( values )

for y in values :
x = ’{0:08 b } ’. format ( y )
ser . write ( x )
6. Subsequently, the speed of serial data on the serial BCM port/interface ttyAMAO
is set to 9600.
7. The next loop is used to pad the numerical strings with zeros after converting
them to binary numbers through ’0:024b’.format(y). The binary strings are filled
with zero to ensure that all the strings have the same length (24 bit). Hence with
this code, x is serially written to the receiver, and it represents the bytes sent and
written as strings with an equal length of 24 bits after converting them to binary
strings.
1. On the same token, we enabled using serial on the receiver and imported the se-
rial library with import serial. On the receiver side, we have also set the baud
rate to 9600, which is requisite to enable the communication between them serially.
2. The read data from the serial port (ttyAMAO) is inserted to the empty array
stored in variable arr using append function. During each iteration of the loop,
each 8 received strings, which are binary as mentioned in the previous transmitter
code, are appended into the empty array stored in the variable arr.
3. The 8 arrays are then stored in arr2, which is another empty array, using the
join function. The preceding code was wrote to send file.txt specifically and was
changed to a more generic form in section 3.2.2.4.
import time
import serial
from decimal import Decimal
ser = serial . Serial ("/ dev / ttyAMAO " , 9600)

f = open ("/ home / pi / Desktop / text . txt " , ’ wa + ’)
arr2 = []
while True :
start = time . time ()

count2 = 0
for count2 in range (13):
arr = []
count = 0
for count in range (8):
p = ser . read ()
arr . append ( p )
s = ""
seq = ( arr [0] , arr [1] , arr [2] , arr [3] , arr [4] , arr [5] , arr [6] , arr [7])
seq2 = s . join ( seq )
print int ( seq2 , 2)
arr2 . append ( int ( seq2 , 2))
print arr2
duration = time . time () - start
print duration
4. For obtaining the time needed for the receiving the file, python timer is started
before receiving strings in the serial port. The start time is subtracted from the
time measured after printing arr2. The difference is stored in the duration variable.
3.2.2.4 Experiment Four: Encoding and Decoding a File
Since we previously tried transmitting the file bit by bit and were unsatisfied with the
result due to the nature in which pyserial works, we decided to send data byte by byte
instead. For that purpose, we use the python command base64.b64encode() to turn
our files into a stream of string in ASCII. That way, we can transmit the file byte by
byte, and it can easily be received by the Rx.
1. We first open the file we wish to transmit using a file path, in the same way we
did before, and then encode file that we read using base64.
import base64
import serial
textFile = open ( ’/ home / pi / Desktop / file . txt ’ , ’rb ’)

str = base64 . b64encode ( textFile . read ())
print str
print len ( str )
ser . write ( str )
2. On the receiver end, we loop 13 times in order to get all the bits and to append
them to an array. We then join all the bits together into one string, so we can
use that to determine how many times to loop on order to receive the entire file,
which is transmitted.
3. Next, we first create an empty string s, and then create a for loop to add it all to
all the bytes we receive. The resulting string is our encoded file.
4. We then use the command base64.b64decode() to get our original file back from
the encoded stream of string.
5. Lastly, we open a new file on the Rx with the desired path and write to it the file
we received.
6. Once done with the transmission of a text file, e go through similar steps to
transmit an image file of type (png). We encode and transmit it in the same way,
and then receive and decode it with the same commands. The only difference is
in the last step of of writing it to a new file. By changing the extension at the end
of the file name in the file path to .png instead of .txt. The file is saved as a png
image file.
import base64
import serial
imageFile = open ( ’/ home / pi / Desktop / image ’ , ’rb ’)

str = base64 . b64encode ( imageFile . read ())
print str
print len ( str )
ser . write ( str )
And in the same way, in order to transmit and receive an mp3 audio file, we change
the file extension to mp3.
3.2.2.5 User Interface GUI
After creating the separate codes for each file type, it is important to combine them in
one program so that the user can choose which file type to transmit. To accomplish this,
we use if statements, along with GUIs in order to make the program user friendly.
1. We start by importing the Tkinter library for the main window and tkFileDialog
for the file browser.
2. We create a new window hich we name root. We create 2 panels in this window,
topFrame and bottomFrame. To topFrame we add a label, an entry widget, and
a browse button. To bottomFrame we add the send button and 3 radio buttons,
which are our file type options for the user to choose from: image(.png), text(.txt),
and audio (.mp3).
import serial
import base64
from Tkinter import *

from tkFileDialog import as k op en fi l en am e
ser = serial . Serial ( ’/ dev / ttyAMA0 ’ , 38400)
def sel ():

selection = str ( var . get ())
root = Tk ()
var = IntVar ()
filePath = ""
topFrame = Frame ( root )

topFrame . pack ()
bottomFrame = Frame ( root )

bottomFrame . pack ( side = BOTTOM )
label = Label ( topFrame , text = " Location : ")

label . pack ( side = " left ")
T = Entry ( topFrame )
T . pack ( side = " left ")
def b u t t o n _ b r o w s e _ c a l l b a c k ():
filename = a sk op e nf il en a me ()
T . delete (0 , END )
T . insert (0 , filename )
def send ():

selection = str ( var . get ())
ser . write ( selection )
print ( selection )
filename = T . get ()
fileToSend = open ( filename , ’rb ’)
s = base64 . b64encode ( fileToSend . read ())
y = len ( s )
x = ’{0:024 b } ’. format ( y )
ser . write ( x )
print ( x )
ser . write ( s )
browseButton = Button ( topFrame , text = " Browse " , command = b u t t o n _ b r o w s e _ c a l l b a c k )
browseButton . pack ( side = " right ")
R1 = Radiobutton ( bottomFrame , text = " Image (. png )" ,

variable = var , value = 1 , command = sel )
R1 . pack ( anchor = CENTER )
R2 = Radiobutton ( bottomFrame , text = " Text (. txt )" ,

R3 = Radiobutton ( bottomFrame , text = " Audio (. mp3 )" ,

sendButton = Button ( bottomFrame , text = " Send " ,

command = send )
sendButton . pack ( anchor = S )
root . geometry ("400 x120 ")
root . mainloop ()
ser . write ( a )
3. We define the functions for the browse button and the send button. In the browse
button function, we do 2 things. First we open a new window from which we get
the file path of the desired file to transmit. Then, we make the entry widget empty
and change its contents to whatever file path we got from the browse window. As
for the send button function, we first transmit the value we get from the radio
buttons, which will be 1, 2, or 3, depending on the decision of the user. Then we
receive the contents of the widget to get the file we wish to transmit, and transmit
first its length, then its encoded form using the b64encode command.
4. We create the 3 radio buttons and set their values (1 for image, 2 for text, and 3
for audio), as well as set their command to the sel function, which sets the variable
selection to the value of the variable the radio buttons output, depending on which
of them the user selects.
5. On the receiver end, we first create a loop to receive the length as we sent it in
bits of 0s and 1s, 24 times for 24 bits. Then, similarly to how we did it in the
bytearray method, we join them all together to once again get the length in on
integer so we can use it for the other loop to receive the file. We use if statements
to know what to do with the data that we receive in the 3 different cases according
to the first byte received from the transmitter. If it is a 1, then the extension of
the file that we save is .png. If it is a 2, the extension is .txt, and if it is a 3, then
the extension is .mp3.
import serial
import base64
while True :
a = ser . read ()
s = ""
arr = []
count2 = 0
for count2 in range (24):
p = ser . read ()
arr . append ( p )
s2 = ""
seq = ( arr [0] , arr [1] , arr [2] , arr [3] , arr [4] , arr [5] , arr [6] , arr [7] , arr [8] ,
arr [9] , arr [10] , arr [11] , arr [12] , arr [13] , arr [14] , arr [15] , arr [16] , arr [17] ,
arr [18] , arr [19] , arr [20] , arr [21] , arr [22] , arr [23])
seq2 = s2 . join ( seq )
x = int ( seq2 , 2)
print x
if a == "1":
count = 0
for count in range ( x ):
str = ser . read ()

s += str
print s
print len ( s )
fh = open ("/ home / pi / Desktop / imageTosave . png " , ’wb ’)
fh . write ( s . decode ( ’ base64 ’))

fh . close ()
elif a == "2":
count = 0
ext = ". txt "
fileName = " textToSave "
str = ser . read ()

s += str
print s
print len ( s )
fh = open ("/ home / pi / Desktop /" + fileName + ext , ’wb ’)

fh . close ()
elif a == "3":
count = 0
ext = ". mp3 "
fileName = " AudioToSave "
str = ser . read ()

s += str
print len ( s )
fh = open ("/ home / pi / Desktop /" + fileName + ext , ’wb ’)

fh . close ()
3.2.3 Li-Fi based Remotely Operated Vehicle
3.2.3.1 Camera
The camera is used for taking underwater pictures under the water. In our project,
we are controlling it by Raspberry Pi and a graphical User interface. The camera is
connected via a USB with the Raspberry Pi. The setup connection shown in Fig.3.16
is initially implemented for simplifying testing process. The user will be able to snap
a picture through touching the snap button in the LCD screens. The code we utilized
in this part is dedicated to auto save the picture and name it per the date and time.
First of all, we have worked on moving the servo motor and snapping images with one
raspberry pi. Later on, we have established serial communication between two raspbery
pis where one transmits the command and the other does the action.
Figure 3.16: The Connection Setup of the Servo and the Camera with One Raspberry
Pi
3.2.3.2 Transmitter
The second application in our project is the underwater ROV controlled by Li-Fi. As
mentioned previously, we control what we wish to transmit and receive through the
Li-Fi modules using UART communication, so we use the serial function of the pyserial
library. In the case of the ROV application, what we wish to transmit are commands
from one raspberry pi, which acts as our remote controller, to a second raspberry pi
inside the ROV, which is connected to all of the ROV’s components.
Since we have a transmitter and a receiver, both sides have programs.For both trans-
mitter and receiver we use raspberry pis and python v2. The receiver raspberry pi is
also connected to an Arduino, so we write an Arduino program for it too. We start with
the transmitter.
1. We begin by importing all the libraries that we’ll need, which include serial, used
to transmit data serially, time and datetime, and Tkinter which is used to create
the graphical user interface.
import serial
# ser = serial . Serial ( ’/ dev / ttyAMA0 ’ , 38400)
from Tkinter import *
import datetime
import time
from threading import Thread
2. We create the graphical user interface. We create a Tkinter window which we

name root, and then to this window we add a frame that contains the button for
the camera, and also the slider for the servo.
3. We create the functions that are called for each GUI interface. The function for
the slider is called every time the position of the slider changes. Each time it does,
it first transmits the number ”1” over UART communication. Then, it takes the
value from the slider, which has a range from 0 to 180, and changes it to the duty
cycle needed to change the position of the servo. It does that by dividing it by 10
and then adding 2.5. After that, it transforms the duty cycle to a format of XX.X
and then transmits this value serially.
4. As for the camera, we create a function picFunc() which is called when the button
is pressed. When it is called, the raspberry pi will transmit the number ”2” serially
over UART communication
class App :
def __init__ ( self , master ):

frame = Frame ( master )
frame . pack ()
scale = Scale ( frame , from_ =0 , to =180 ,
orient = HORIZONTAL , command = self . update )
scale . grid ( row =0)
def update ( self , angle ):

ser . write ("1")
duty = float ( angle ) / 10.0 + 2.5
r = ’{:04.1 f } ’. format ( duty )
print r
ser . write ( r )
def picFunc ():

print " Snap "
ser . write ("2")
root = Tk ()
root . wm_title ( ’ Servo Control ’)
app = App ( root )
bottomFrame = Frame ( root )
bottomFrame . pack ( side = BOTTOM )
snapButton = Button ( bottomFrame , text = " Snap " , command = picFunc )
snapButton . pack ( anchor = S )
5. The last part of the transmitter code is the one that sends commands to control the
propellers of the ROV. For these controls we use the WASD keys on the keyboard.
We first create functions for key press and key release. The key press function,
when called, will check which key it was that was pressed. The keys that we check
for are the W, A, S, and D. Each of these 4 keys will transmit a different command
for a different state of movement of the ROV(”f” for forward, ”b for backward, ”l”
for left, and ”r” for right). When W is pressed, ”f” will transmitted. When A is
pressed, ”l” will be transmitted. When S is pressed, ”b” is transmitted, and when
D is pressed, ”r” will be transmitted. As for the key release function, there is only
one condition. Whatever key is released, an ”i” will be transmitted, for Idle.
def on_key_ release ( event ):

global h a s _ p r e v _ k e y _ r e l e a s e
h a s _ p r e v _ k e y _ r e l e a s e = None
print " Idle "
ser . write (" i ")
def on_key_press ( event ):

if ( event . char == " w "):
print " Forward "
ser . write (" f ")
elif ( event . char == " s "):
print " Backward "
ser . write (" b ")
elif ( event . char == " a "):

print " Left "
ser . write (" l ")
elif ( event . char == " d "):

print " Right "
ser . write (" r ")
def o n _ k e y _ r e l e a s e _ r e p e a t ( event ):
h a s _ p r e v _ k e y _ r e l e a s e = root . after_idle ( on_key_release , event )
def o n _ k e y _ p r e s s _ r e p e a t ( event ):
if h a s _ p r e v _ k e y _ r e l e a s e :
root . after_cancel ( h a s _ p r e v _ k e y _ r e l e a s e )
h a s _ p r e v _ k e y _ r e l e a s e = None
else :
on_key_press ( event )
6. The final step is to bind all these callback functions to the key press and key release
events of all the keys. We use the bind function and bind to each of the WASD
key press and release events the callback functions we defined.
frame = Frame ( root , width =100 , height =100)
frame . bind (" < KeyRelease -w >" , o n _ k e y _ r e l e a s e _ r e p e a t )

frame . bind (" < KeyPress -w >" , o n _ k e y _ p r e s s _ r e p e a t )
frame . bind (" < KeyRelease -a >" , o n _ k e y _ r e l e a s e _ r e p e a t )

frame . bind (" < KeyPress -a >" , o n _ k e y _ p r e s s _ r e p e a t )
frame . bind (" < KeyRelease -s >" , o n _ k e y _ r e l e a s e _ r e p e a t )

frame . bind (" < KeyPress -s >" , o n _ k e y _ p r e s s _ r e p e a t )
frame . bind (" < KeyRelease -d >" , o n _ k e y _ r e l e a s e _ r e p e a t )

frame . bind (" < KeyPress -d >" , o n _ k e y _ p r e s s _ r e p e a t )
root . mainloop ()
3.2.3.3 Receiver (Raspberry Pi)
1. After we’re done with the transmitter, we start with the receiver raspberry pi.
Again, we begin with the initialization and importing the libraries we need. This
time, we import both serial and smbus to be able to use both UART and I2C com-
munication: UART with the transmitter raspberry pi and I2C with the Arduino.
Also, We import the RPio library and initialize the pin for the servo, which is pin
18 (GPIO 01) and set it as a PWM pin. We also set the raspberry pi as the master
in the I2C connection.
import serial
import smbus
import time
import RPi . GPIO as GPIO
GPIO . setmode ( GPIO . BCM )
GPIO . setup (18 , GPIO . OUT )
pwm = GPIO . PWM (18 , 100)
pwm . start (6)
bus = smbus . SMBus (1)
# This must match in the Arduino Sketch

SLAVE_ADDRESS = 0 x04
2. After that, create a while loop in which we constantly read the data received
through UART. We then create several different conditions using if statements for
all the different cases depending on the value of the data received. There are 7
different cases.
3. The first case is if the received message is the number ”1”. If that is the case,
then the receiver will know that it should receive a value for the servo, which is
the required duty cycle to change its angle. It will loop 4 times to get the duty
cycle which was transmitted in the form ”XX.X”, and then it will put the 4 values
together and change them to type float. This float value is then used to change
the angle of the servo, using the ChangeDutyCycle function.
4. The second case is if the received message is the number ”2”. In this case, the
receiver will know that it should a take a picture with the USB camera connected
to it and save it timestamped on the desktop in the raspberry pi.
5. The other 5 cases are related to the control of the propellers. They are the 5
states of ROV movement: forward, backward, left, right, and idle. The raspberry
pi receives commands from the transmitter regarding the input from the user, and
it relays those commands to the Arduino through I2C. When it receives an ”f” from
the transmitter, it transmits an ”f” to the Arduino through I2C communication.
Likewise, if it receives a ”b”, ”l”, ”r”, or ”i”, it transmits it to the Arduino.
while True :
a = ser . read ()
if a == "1":
s = ""
arr = []
count = 0
for count in range (4):
p = ser . read ()
arr . append ( p )
s2 = ""
seq = ( arr [0] , arr [1] , arr [2] , arr [3])
seq2 = s2 . join ( seq )
duty = float ( seq2 )
pwm . Ch an g eD ut yC y cl e ( duty );
elif a == "2"
os . system (" fswebcam -d / dev / video0 -r 352 x280 / home / pi / Desktop /\% s . jpg " \% datetime . datet
elif a == " f ":

print " Forward "
bus . write_byte ( SLAVE_ADDRESS , ord ( ’f ’))
elif a == " b ":
print " Backward "
bus . write_byte ( SLAVE_ADDRESS , ord ( ’b ’))
elif a == " r ":
print " Right "
bus . write_byte ( SLAVE_ADDRESS , ord ( ’r ’))
elif a == " l ":
print " Left "
bus . write_byte ( SLAVE_ADDRESS , ord ( ’l ’))
elif a == " i ":
print " Idle "

bus . write_byte ( SLAVE_ADDRESS , ord ( ’i ’))
3.2.3.4 Receiver (Arduino)
1. As previously mentioned, the receiving end of the system consists of a raspberry

pi connected to the receiver module of the Li-Fi transceiver where the stream
of encoded binary data is re-assembled in a string representing the sent control
command.
2. Electronic Speed Controllers ESC control Brush-less DC motors as servos. Hence,

it is required to employ the Servo library for enabling Arduino control over the
ESCs.
3. Soon after including the servo library, three servo objects were created for each
ESC.
4. Each object is attached to a pwm pin on the Arduino. In our case, we have
attached the left ESC (connected to the port propeller) to pin 6 and the right ESC
(connected to the starboard propeller) to pin 9.
5. Once the Escs are connected to a sufficient power source, it starts beeping after
8 seconds. In other words, it is implying that the ESC is waiting for an input,
specifically a pulse width modulation input. When the Electronic speed controller
receives an input from the pwm pin, it disarms and stops beeping.
6. The position of the propeller is determined by a value written to the ESC by the
Object.write() function. The values that could be written in this function range
from 0 → 180. When 0 is inputted in the write function, the propeller mounted
on the corresponding ESC will move at full speed in one direction, while 180 will
move it at full throttle in the opposite direction. In case the given input is close
to 90, at that point the propeller mounted on that ESC will stop its rotation.
7. In order to make the propellers rotate, each ESC should be disarmed by initially
inputting a 0 into the write function. A delay of 5 ms is applied after initialization.
8. Since we have established a slave-master connection between the receiving rasp-

berry pi and an Arduino, we have created a function (wire.read()) which reads a
byte sent from the master (receiving raspberry pi). As mentioned previously, A
character will be sent from the transmitting raspberry pi to the receiving raspberry
pi, and it will be forwarded to the arduino using the smbus approach, arduino
will move the propellers upon the character received from the master.
9. Hence, we have programmed the propellers to move the Remotely Operated Vehicle
(ROV) forward when character ’f ’ is received. Moving the ROV forwards requires
having the propellers rotating in counter directions. For that reason, each ESC is
programmed to rotate the propeller mounted on the motor connected to it in an
opposing direction to the other propeller has. In this state, The right esc receives
a value between 0 → 90 meanwhile giving a value between 90 → 180 to the other
esc.
# include < Wire .h >

# include < Servo .h >
Servo rightservo ; // create a servo object for the right servo

Servo leftservo ; // create a servo object for the left servo
int SLAVE_ADDRESS = 0 x04 ; // part of the i2c initia lizatio n
void setup ()
{
Serial . begin (9600);
Wire . begin ( SLAVE_ADDRESS ); // part of the i2c i nitializ ation

Wire . onReceive ( p rocessMe ssage ); // function to call when data is received
rightservo . attach (9); // attaches the servo on pin 9 to the right servo object
leftservo . attach (6); // attaches the servo on pin 6 to the left servo object
rightservo . write (90); // initialize both escs to 0 speed to disarm them
leftservo . write (90);
delay (5000);
}
void loop ()
{
}
void processM essage ( int n )
{
char ch = Wire . read ();
if ( ch == ’i ’)
{
Serial . println (" Stop ");

rightservo . write (90);
}
else if ( ch == ’f ’)
{
Serial . println (" Move forward ");
}
else if ( ch == ’b ’)
{
Serial . println (" Move backward ");
// rightservo . write (130);
// leftservo . write (100);

else if ( ch == ’r ’)
{
Serial . println (" Move right ");
}
else if ( ch == ’l ’)
{
Serial . println (" Move left ");
}
}
10. It took several trials underwater to decide the values giving the best response to
the chosen control command. Through testing, we have noticed that the left motor
is more powerful than the right motor. Henceforth, it was taken into consideration
during the calibration process that a motor is slower than the other.
11. In case the user wishes to move the ROV to the right, the left propeller rotates at
a higher speed than the right propeller in the same direction. Supposing the user
has pressed the ’d’ button, the left propeller has to move in the opposite direction
while having the right propeller moving forward. This is due to the fact that the
left propeller is faster than the right propeller.
3.3 Hardware Implementation
3.3.1 Li-Fi based File Sending Application
The Li-Fi based File Sending Application is an embedded application which depends
upon a certain procedure for configuring the receiver module to receive from the LED
Matrix at the needed distance. The distance, at which the receiver is set up to, should
be kept constant throughout the sending process. The setting up procedure of the Li-Fi
based File sending application is as follows:
1. First and foremost, the Receiver and the transmitter modules are connected to a
raspberry pi as shown in Figures Fig.3.21 and Fig.3.20. It is required to connect the
baseboard of the Li-Fi compatibles to: 5v, 3.3 v, and the UART pins on the rasp-
berry pi which are the UART0TxDGPIO (GPIO 14) and UARTT0RXD(GPIO
15).
Figure 3.17: Shows the Connections of Baseboard of the Li-Fi Transmitter Module
to the Raspberry Pi
Figure 3.18: Shows the Connections of Baseboard of the Li-Fi Receiver Module to
the Raspberry Pi
Figure 3.19: Shows the Internal connections of the Li-Fi Receiver Module
2. Afterwards, the LED matrix is connected as follows in Fig.3.20. An external power

source of (12v) is needed to brightly light up the LED panel, which is censorious
for maintaining the continuity of data stream. A LED stand is utilized at this
stage considering the significance of the stability of the LED Matrix.
3. The receiver module is then placed in the field of sight of the LED Matrix where a
clear line of sight is preserved. In this step, both the transmitter and the receiver
modules should be in config mode during the setting up phase.
Figure 3.20: Shows the Connection of the LED Matrix to the Transmitter Module
Figure 3.21: The Overall Connection of the LED Panel to the Receiver Module
Figure 3.22: Config Mode

4. The pot shown in Fig.3.23 is rotated until the indicator LED glows up show that
the sensibility of the photo-diode (PD) on the receiver module to the lightening of
the LED matrix has been verified.
Figure 3.23: The Steps Followed in Configuring the Receiver Module
Finally, the mode shown in Fig.3.22 is changed into run mode instead of config mode
by removing the jumper from the config mode and placing it into the run mode.
3.3.2 Remotely Operated Vehicle (ROV)
The underwater ROV application, like the file transfer application, has a transmitter
side and a receiver side, as shown in fig 3.24. The transmitter consists of only a raspberry
pi connected to a Li-Fi Tx module and a monitor, keyboard, and mouse for interface.
The Li-Fi Tx module is connected to a LED matrix, and a 12V Pb battery which powers
the LED matrix.
On the receiver side, the raspberry pi is connected to all of the ROV’s components. The
camera is connected to a USB port on the raspberry pi. The servo has 3 pins: power,
which is connected to the 5V pin on the raspberry pi; ground, which is connected to the
ground pin on the raspberry pi; and a control line, which is connected to pin 18 on the
raspberry pi (GPIO 01).
Also, the raspberry pi is connected to an Arduino through I2C. The SDA pin on the
raspberry pi is connected to the SDA pin on the Arduino, SCL is connected to SCL,
and a ground pin on the pi is connected to a ground pin on the Arduino.
Figure 3.24: ROV System Model
All of the components on the receiver side were put together using an ROV kit bought
from the openROV website. The ROV kit consists of: ROV main frame, propellers,
brush-less dc motors, a servo motor, a camera, and battery tubes. While following
the instructions given in the manual, some changes have been made. For instance, the
controller board that contains the software of the Remotely Operated Vehicle (ROV)
and the tether cable have been removed. The shafts of the horizontal propellers are
mounted in opposite directions on the brush-less DC motors as shown in Fig.3.25. Each
ESC is connected on one end to the 3 phases of a brush-less DC, and on the other end
connected to the Arduino. They’re connected to the Arduino through 2 pins: ground
and a control pin, which must be a PWM pin. We use pin 6 and 9 on the Arduino for
the left servo and the right servo respectively. A separate external power supply, shown
in Fig.3.26, is connected to the ESC. Three 3.3 volts LiFePo4 batteries cells are placed
in series in each battery tube supplying 9.9 volts. Each battery tube supplies enough
voltage for the brush-less DC motor utilized in this prototype. The camera came with a
cylindrical enclosure where electronics will be enclosed. Since safety of the components
from shorting and water is crucial, we have isolated the connections and secured them
using a waterproof 2 ton epoxy and electric tapes.
Figure 3.25: Propellers and brushless DC motors

Figure 3.26: The Main Frame of the ROV

Figure 3.27: ROV Camera

Chapter 4
Project Management
4.1 Team Members
• Raghad JZ Abuolwan She is an Electrical Engineering student graduating in

spring 2017. She is a reliable and a responsible team member. Having decent re-
searching skills, she was able to guide the team members in researching throughout
the semester. One of her main weaknesses is that her knowledge about coding is
limited to C++. In addition to that, she gets nervous easily. Still, she cooperates
well with the team and works well under pressure. This team member is diligent
and devoted for this research, as she attends team team gatherings and follows
up with the supervisors of this graduation project. She is also responsible for im-
plement the ROV along with noorhan as well as assisting the group with coding
process of the ROV and the File sending application, in addition she is required
to assist the leader in work distribution and giving ideas.
• Aya Iyad Murad She has been in charge of checking the connection of the file
transfer, as well as testing the file transfer implementation for the Tx and Rx. She
was responsible for reading and searching about both Li-Fi systems; in addition
to that, she will work with Fatima in programming the file transfer and the ROV
applications. Also, she is responsible to double-check the Python codes that other
members provided.
• Fatima Omar Al-Baiti She is a computer engineering student graduating in

spring 2017. She is diligent and punctual, and loves a good challenge. Although she
is a bit lacking in self confidence, she is a critical thinker and always does her best
to come up with ideas and solutions to problems. She was charged with research
about the two Li-Fi applications and initial designs. She is capable of programming
in several programming languages, including C, C++, Java, R and others, and is
85
Chapter 4. Project Management 86
in charge of programming the Raspberry Pis in both Li-Fi applications alongside

Aya.
• Nourhan Khalid Ahmed As a leader, she was and still responsible for assigning
the tasks and dividing them, also communicating with the group members. She is
the calmest person in the group and always optimistic even in the hardest situa-
tions. She has good abilities in researching and achieving the needed information.
Although She has a limited knowledge in programming, she accepts challenges,
and she is interested and willing to learn new stuff in this capstone journey. She
will be assigned to work with Raghad on assembling the ROV. Moreover, learning
the python programming language to help in the controlling codes.
4.2 Schedule Managment
The original plan is shown in Fig. 4.1. The Gantt Chart shows the plan that we had
went through to complete this project. Our aim was to give each task enough time to be
completed and achieved successfully. However, due to the not predicted problems that
we had faced, we dedicated more time to some tasks compared to others. Although a
minimal modification were made in the schedule, yet we were able to manage finishing
on time as mentioned in the Gantt Chart.
Figure 4.1: Gantt Chart depicting our schedule for the project
4.3 Task Division
The task division in this project was made in a way to make sure that all the students
are participating and contributing in each part of the project, with the load distributed
equally. The fact that we are four students coming from Electrical Engineering and Com-
puter Engineering background helped a lot in achieving our goal and gaining knowledge
about the two fields. The two Electrical Engineering students (Raghad JZ and Nourhan
Khalid) were responsible of the hardware and implementation of the ROV Kit. While
the two Computer Engineering students (Fatma Al Baiti and Aya Murad) were in charge
to do the programming parts in controlling the underwater robot. All of us had an idea
of what the others were doing, and the meetings were conducted weekly to update each
others about the latest progress achieved. We all had contributed in the file sending
application similarly since that its a new technology introduced to us all. And wasnt a
pure Electrical neither a Computer skills.
Progress Report: Light Fidelity (Li-Fi) Enabling Applications
• Task1: (Literature review) Writing 5 pages for the proposal

Assigned to: Raghad JZ Abuolwan
Description Deliverable: Showing the advantages of optical underwater sys-
tems over acoustic systems/ Line-of-sight as the optimal solution for least power
attenuation / writing the motivation for the proposal/ writing about indoor based
Li-Fi communication (Describing a system) / 3 proposed Designs for LED panels.
Deadline: Saturday 12/11/2016
Input: Literature review (5 researches/referencing included in the document)
Output: Progress in the proposal
• Task2: Background
Assigned to: Nourhan Khalid Abdelhady
Description Deliverable: Introducing the Li-Fi technology and its founder. A
full explanation of the Li-Fi working process.
Input: Objectives, online sources
• Task3: Literature review + background

Assigned to: Fatima Al-Baiti, Aya Murad
Description Deliverable:Writing about the history and types of ROVs (back-
ground), photophone (literature review), misconceptions about Li-Fi (background)
Input: Online articles and researches, ROV website (links included in document)
• Task4: Testing the file sending through wi-fi, using two raspberrys
Assigned to: Nourhan Khalid, Aya Mourad, and Fatima Al-Baiti
Description Deliverable: establish a connection between the two raspberrys

and send a picture as a file from the first raspberry to the second one. We used
two TVs as the output display monitor, and we used Ethernet cable to get internet
access to the raspberry.
Deadline: Friday 11/11/2016
Input: A client sending code and a server receiving code
Output: Kept receiving the same error over and over. We will refer to Eng.
Yasmina to figure where the error comes from
Progress Report: Light Fidelity (Li-Fi) Enabling Applications
• Task1: Sending bytes serially through two raspberries

Assigned to: Aya Murad, Fatma Al-Baiti
Description: In this task, I am required to turn a file into an array of bytes,
and print them out. Also, sending those bytes through serial communication to
another ip address.
• Task2: coming up with FSM for programming the ROV

Assigned to: Nourhan Khalid, Raghad JZ
Description: In this task, I am required to decide the controlling components and
implement FSM for the ROV also, working on studying the python programming
language to code the FSM
• Task3: Working on assembling the ROV kit

Assigned to: Nourhan Khalid
Description: In this task, I am required to follow the building instructions and
finish Guide1,2. Deadline: Saturday 28/1/2017
4.4 Team Communication
In order to maintain an effective and productive team communication, we had conducted

different methods of meetings on a sequence pattern. First, we had set a weekly face
to face meeting in order to update each other about the new achievements in our tasks.
Also, we had a WhatsApp group to talk about and discuss the meetings time and daily
updates. With our advisor Dr. Montasir, we used to send a calender event to confirm
the meetings time, and they were usually set twice a month for all the latest results
and system errors. A sample of the calendar events is shown in Fig.4.2 and Fig.4.3. As
that we are a team consist of two majors (Electrical and Computer), we had shared the
different knowledge between each others and ended up with a strong background of the
opposite major.
Figure 4.2: Calendar events done on February

Figure 4.3: Calendar events done on March

4.4.1 Teamwork Evidence
Figure 4.4: The Computer Engineering Team Working on the Hardware

Figure 4.5: The Electrical Engineering Team Working on the Software

Chapter 5
Discussion and Results
5.1 Overall System Model
The conventional model of a Li-Fi based system consists of the fundamental components:
• A LED Matrix for high coverage area
• A Transmitter Module based on an LED driving circuit
• A Receiver Module
• A photo-diode / Photo Array for higher sensitivity
5.2 Initial Results
Regarding the file transferring task, we wanted to explore the raspberry and compati-
bles specifications and working process. We had to learn the python programming for
Raspberry pi; however due to our lake of knowledge with the python programming, we
considered learning from scratch to overcome beginners level. We installed the operating
system and py-serial package which was provided in the manual. Moreover, we used a
displaying monitor, keyboard, and mouse, as our interface with the Raspberry. Also,
to give the transmitting and receiving commands, we went through the steps in the
manual to configure the Li-Fi compatibles. After that, we tested the Rx (receiver) and
Tx (Transmitter) to make sure theres no technical errors. The code for testing the Rx
is shown in Fig 5.1 .
After running the code by the sudo python filename.py, we press on the S2 button on
the lifi compatible. The below output shows up on the raspberry screen as in Fig.5.2
95
Chapter 5. Discussion and Results 96
Figure 5.1: The Code Used for Testing the Receiving side
Figure 5.2: ’researchdesignlab.com’ Printing
Moreover; the communication between the Tx and Rx Li-Fi compatibles is done through
running the below code shown in Fig. 5.3. After this step, we should be able to transmit
any typed massages in the Tx side and receive at the Rx side.
Figure 5.3: Communication Code

5.3 Final Results
5.3.1 File Transfer Application
This section is dedicated for evaluating the speed and the time that is required to send
several types of files serially between two raspberry pis. The time duration of the file
arrival is evaluated with an accurate python timer.
In the first experiment, due to the way pyserial forwards data, the transmitter sent each
integer in the decimal byte as an individual byte. The result demonstrated previously is
different from what was sent on the transmitter side, has directed us to create a protocol
that solves this problem. Hence, we developed the code in section 3.2.2.3. As shown in
Fig.5.4, the time taken by the receiver to print the bytes as a single array is 1.8795540328
seconds. However, this code is sufficient only for files, which do not have large sizes such
as the text file containing ABC112233. For the sake of measuring the code efficiency,
an image array of bytes was sent from the transmitter and took a significant amount
of time to be received using this code. Consequently, to increase the efficiency and the
speed of sending files in general, we developed a faster and more user friendly protocol.
Figure 5.4: Shows the Time Calculated to Send a Text File with Byte-array Approach
In order to transmit our files, we first turn them into a stream of strings for pyserial to
be able to write it byte by byte. For that, we use base64 to encode it. Base64 is a list
of 64 characters, each of which consists of 6 bits. Encoding in base64 means to turn a
byte of 8 bits into one of the 6 bit characters of 64. We use it in our program to make
it easier to send data byte by byte as string. [20]
We begin with a text file. Our text file consists of 13 bytes, including the header and
footer. When we encode it using base64, and print its length, we find that the encoded
file consists of 20 bytes. The reason for the increased size of the file after encoding it is
that the original file consists of 8-bit bytes, and each 6 bits are bunched together instead.
Because of that, every 3 bytes become 4. [20]
Figure 5.5: Text File Transmitter Code Using Encode Method
Before we transmit the encoded file, we first transmit its length. This is important
because we need to know how many times the receiver must loop until it has the entire
encoded file. Since we can’t know how many digits the length will be, we decide to use
the byte array method here, just for the length. However, instead of using 8 bits, we use
24 bits or 3 bytes. Since 224 = 16777216, that means that we are limited to a maximum
size of approximately 16MB. We can make this maximum size higher if we just increase
the number of bits. However, we feel this size is enough for our experiments, as we are
limited with the speed of our hardware. The Rx receives the length and uses it in a
for loop, appending each byte it receives to an initially empty variable of type string.
When it is done looping, the string variable will contain our transmitted file. We can
then turn it back to its original form using the b64decode command to decode it using
base64. Each 4 bytes turn into 3 again and the file size decreases back to the original.
We then write it back to a file again, and the received file is created on the desktop as
we chose.
Next we move on to the user interface, since we wish to give the user a choice of the file
and file type to transmit. For that, we have a GUI that contains an entry widget and
a browse button that chooses a file path through an open file window, as well as radio
buttons that output values from 1 to 3 (1 for image, 2 for text, and 3 for audio). In
the end, we have a send button that takes the value of the entry widget, which is a file
path, and the value from the radio button, which is a number corresponding to the file
type. When the send button is pressed, first the selection value is transmitted, then the
length of he encoded file, and then the encoded file itself.
Figure 5.6: Transmitter Graphical User Interface (GUI)
On the receiver end the first thing to reach is the number indicating the file type. We
use if statements to determine what to do for each case. Depending on the file type, the
file extension varies, and that is what makes the difference when saving the file, writing
it in the same way we did before.
When we used the bytearray method to send an image, it took a very long time, how-
ever, when we used a timer to calculate how long it took to transmit the same image
(approximately 60KB) it took 20 seconds.
Figure 5.7: Shows the Time Calculated to Send an Image File with Encode Approach
Also, the time it took to send a 200KB audio file was 70 seconds using the encode
method. Using the byte-array method, it took too long to manage an experiment.
Figure 5.8: Shows the Time Calculated to Send an Audio File with Encode Approach
As a final experiment, we tried sending files of several different sized, and used the timer
code to find out exactly how much time it took for each file to be transferred from one
pi to another through light. The following table shows the result of this experiment.
File Size (kB) Encoded File Size (bytes) Duration (s)
34.6 47216 12.3867

77.9 106328 27.7805
51.3 70040 18.3357
114.5 156324 40.8378
576.4 786952 205.388
5.3.2 Underwater ROV Application
The ROV consists of 3 main components to control: the camera, the servo that changes
the position of the camera, and the 3 brush-less DC motors which control the movement
of the ROV underwater (2 in the horizontal axis and 1 in the vertical axis). For each of
these 3 components, we have different and unique commands to transmit through light.
When these commands are received on the other end, the receiver will know what action
to take.
Both the camera and the its movement are controlled by user through a graphical user
interface, or a GUI, as shown in fig 5.9 To take a picture, the user presses a button. This
button will then call a function, which will proceed to transmit the number ”2” serially
through UART.
Figure 5.9: Transmitter Graphical User Interface (GUI)
As for the servo which moves the camera, the user can change its angle with a slider GUI.
The slider has the range of values from 0 to 180, which are the values of the angles that
the servo can be in. This range is then scaled down using a formula to a range between
2.5 and 20.5, which is approximately the range of PWM pulse values that control a servo
motor. The angle of a servo motor is changed by sending it pulses with different lengths.
To make it go to 0 degrees, we send it a pulse that is high for 1 ms, then low for the
rest of the signal. To make it go to 180 degrees, we send a pulse that is high for 2 ms,
and to make it go to 90 degrees, we send a pulse that is high for 1.5 ms, and any values
between 1 ms and 2 ms change the angle between 0 and 180 accordingly. [21]
We use the ChangeDutyCycle function to create the PWM signals. This function
takes a percentage between 0 and 100, with 0 being a signal high 0% of its length, and
100 being a signal high 100% of its length. Since we set the frequency of the the servo
to 100Hz, that means that it needs a range of approximately 10-20% duty cycle. That
is why we get the scaled value from the slider and transmit it to the receiver. But first,
we transmit the number ”1”. This is to let the receiver know that the action it must
take is related to the servo. when the number ”2” is sent to the receiver, the camera
takes a shot saves it in the desktop with a specified resolution.
After that, we format the duty cycle using .format to make sure that it is always in the
format ”XX.X”. The reason for this is to make the format of the value uniform, because
otherwise the receiver won’t know the exact number of digits it should be receiving.
Lastly, the brush-less DC motors which move the ROV underwater can be controlled
by the user with keyboard keys. Depending on which key is pressed, the ROV will go
from one state of movement to another. By default it is in the idle state. When the user
presses the WASD keys, the ROV will go to the Forward, Left, Downward, or Right
state respectively. When the user releases the pressed key, the ROV will go back to its
initial Idle state. To achieve this, we bind the key press and key release events of each
of the WASD keys to our GUI frame. To each of these bound events, we add a callback
function. When the keys are pressed, a special command will be transmitted to tell the
receiver to make the ROV go to the corresponding state (”f” for forward, ”l”, for left,
”b” for backward, and ”r” for right). When any of the keys is released, the command
”i” will be transmitted, which will tell the receiver to go back to the Idle state. That
is meanwhile being in the idle state, the receiving raspberry pi sends the command ”i”
to the Arduino which accordingly stops the motion of the lateral propellers until a key
is pressed. Thus, the receiver will proceed its state transitions based on the connection
established between the 3 micro-controllers by this special command. The action of each
propeller is unique for each state and there motions combined creates the requisite state.
The reason for using a master/slave connection lies in that the Pulse Width Modula-
tion pin of the raspberry pi does not provide sufficient pwm voltages for controlling the
ESCs. The maximum value that is given by the raspberry pi is 3.3 volts. Consequently,
an Arduino uno is employed for supplying appropriate values of pwm voltages to the
Electronic Speed Controllers (ESC). On the Arduino, each ESC is attached to a pwm
pin. For continuous rotation servos such as BLDC, inputting values that range from 90
→ 0 and 90 → 180 to the .write() function enabled us to vary the speed and direction of
each propeller. For example, when values close to 90 is inputted to the .write() function,
the propeller stops its rotation. In case the input is 0, the motor will rotate at the
highest speed in a certain direction. In fact, the more the inputted value is closer to
zero (in 90 → 0 range), the faster it rotates. In the other range ( 90 → 180), the same
principle applies. The closer the value is to 180, the faster it will rotate in the opposite
direction.
The programming of each state is multifaceted as it can be achieved using different

combinations of propellers actions for the same state. For instance, in order to move
the ROV to the left or to the right, these states can be accomplished by either making
the lateral propellers rotate in the same direction or in counter directions with various
speeds. In our case, we decided which actions to be taken by each propeller depending
on the response and speed of each propeller. This is based on multiple practical trials
underwater. Throughout the implementation phase, we have initially programmed the
ROV parts separately using wired connections. Then its functionality using Li-Fi has
been established and verified.
We conducted a number of tests in order to find the right values that give us the
movement that we want. The tests were conducted in a water tank after properly sealing
all the water sensitive electronics. The tests were also made to prove the functionality
of our system, and the ability to remotely control the movement of the robot using
keyboard input.
After running both transmitter and receiver programs (the transmitter was run manu-
ally; however, the receiver was configured to run on boot), and placing the propellers
in the water, we tried pressing some of the WASD keys. Pressing the W key made the
ROV move forward, while pressing S moved it backward, and A and D moved it left and
right respectively. In all cases, once the key is released, the ROV’s motion stops. This
is how we developed the FSM, and so we can see that it is working in the way that is
supposed to. Some of the results can be seen in fig 5.10 and fig 5.11.
Figure 5.10: The ROV Moving Forward

Figure 5.11: The ROV Turning Right
5.4 Discussion of Problems
During our design and implementations phases, we have faced multiple problems. Some
of the problems that we have faced took a lot of time to solve, but there was some
minor problems that were easily solved. The following list contains the problems and
the solutions that were found towards the completion of our project.
• Problem 1: Initially, we have faced an issue while trying following the instructions
in the manual, which were provided in the RDL website from where we bought
the Li-Fi compatibles from. The code provided by the developing company was
not working during our initial testing.
Solution: We have found out that the problem was due to a mistake in the
code where the command ser.readline() was used. After noticing the mistake, the
command was replaced with ser.read() instead.
• Problem 2: Moreover, there was a major issue in the code that was provided,
which was made to send messages only, and what we want is to send files.
Solution: Developing a File sending protocol for sending files, we converted the
file into array string.
• Problem 3: The third problem that we faced is that we could not get the pro-
pellers to rotate while controlling them with the raspberry pi. This is due to the
fact that the pwm voltages provided from raspberry pi pwm pin is insufficient for
our ESCs.
Solution: After multiple trials to make the ESC work on the RPi, we have found
out that the Arduino provides the sufficient pwm voltages we need. We added an
Arduino to our prototype by connecting it with the rpi through I2c communication.
The ESCs were connected to the arduino.
5.5 Project Cost and Finances
Figure 5.12: Project Breakdown of Cost

Chapter 6
Conclusion and Future Work
6.1 Future Work
Many other adaptions, modifications, and upgrades could have been done in order to
increase the efficiency and effectiveness of the project, but due to the lack of time and
resources, they were not applied. Working on this thesis helped raising many questions
which we found answers for. As described before, the Li-Fi system consists of two sides
which are the Transmitter and the Receiver, and each has its role in modifying the system
productivity. We found out that by varying the distance between the Transmitter and
Receiver, we reach to a level that the connection will not be established. Thus, we had
to study the hardware itself and prepare a lot of experiments to clear this image.
1. First, we studied the Transmitter side to reach the following conclusion, the
strength of the LED Panel light helps in enhancing the system efficacy. More-
over, the area of the LED Panel has a role in increasing the transmission coverage
area. In other words, the larger the LED Panel, the higher coverage area we get.
And the more powerful the LED Panel, the more the distance could be varied. We
were able to attempt this assumption by running the transmission under different
lighting condition. Such as supplying the LED Panel by a 12V battery and less,
and record the transmission and configuration alternative.
2. Second, studying the Receiver side prime us to the following results, the Photo
Diode on top of the Receiver could be changed to any other light sensitive product
to enhance the light sensing ability at the Receiver. Which leads to diverse the
distance between the Rx and Tx with the same results.
110
Chapter 6. Conclusion and Future Work 111
6.2 Future Technologies
The common LED has already seen widespread use in applications such as lighting and
decoration. This is due to their low cost, reliability and simplicity. These same factors
also attribute to their implementation for use in data transfer applications through LiFi.
LiFi however means more than just reliable and low cost data transfer applications. LiFi
makes use of the visible spectrum of radio waves and so eliminates the use of the common
and crowded radio frequency range. LiFi can also transmit data faster more securely
when compared to the commonly used WiFi system.
LiFi can make use of the LEDs already implemented for lighting and decoration in order
to transmit data. LiFi and its use of LEDs make for a data transfer method that is
faster and more secure. This means that it can be seen in a range of applications in the
future, especially where security, speed and costs are of high concern.
• Underwater Communication Li-Fi is sufficient for the underwater communi-

cation due to the fact that light can penetrate water. While radio waves that the
Wi-Fi utilizes cannot penetrate water and the signal will fade as it travels through
the water.
• Industrial environment Successful commercial testing has already begun with a

company called Velmenni in Estonia where they were reporting network speeds of
up to 1Gbs which is on average 100 times faster than conventional WiFi systems.
The company implemented the LiFi technology through means of a smart lighting
system for industrial environments. Which meant that the lighting system could
continue its primary purpose of lighting but also transfer data through LiFi. This
shows the technologys readiness for the industry and how it can improve it.[22]
• Uniform data rated transfer In the case of many people in the room, getting
Internet access from the same source. If the source is the Li-Fi users will have a
chance of receiving higher data rates that it would be provided to them in case of
the Wi-Fi. Thus, the larger the number of users the slower the download speed
it be when using Wi-Fi. While with the Li-Fi each user is given full channel data
rates. This concludes that Li-Fi data rate and transmission speed is 1000 times
greater than the Wi-Fis used data rate and transmission speed.
• Security The fact that light cannot penetrate walls creates a more secure com-
munication environment in contrast with the case of Wi-Fi networks.
Chapter 6. Conclusion and Future Work 112
6.3 Conclusion
In conclusion, this project has employed one new technology and that is Li-Fi. For
the first application, efficient file transfer, we found out that the best way to transmit
data is byte by byte using pyserial. To achieve this, we use base64 encoding and if
statements for the different file types. As for our second application, the underwater
exploration robot, we plan to transmit commands in the same way. Due to hardware
limitations, both systems can only run uni-directionally, and live streaming of the cockpit
is not possible. For the underwater robot, we will take pictures that will be saved for
later extraction. For creating a more productive model, it would be more efficient to
choose an upgraded hardware circuitry that provides pi-direction data transmission. For
implementing this, the hardware should contain a LED Panel (PD) as well as a Photo-
detector (PD) in both sides. In our design, we are only able to transmit the data in one
direction due to hardware limitations, which is also a reason to justify the inability of
this prototype to send real time video transmission to the user in the opposite direction.
Hence, the availability of a bi-directional circuitry is essential for creating more efficient
applications.
Appendix A
Pictures
Showing below are the pictures when we were testing if the ROV move efficiently un-
derwater.A.1, and A.2
Figure A.1: The ROV Moving Forward
113
Appendix A. Images 114
Figure A.2: The ROV Turning Right
Figure A.3: Shows Propellers Test
We have used an Electronic Speed Controller(ESC) in order to change the direction and
speed of the propellers. We used three of them to control the three motors in the ROV,
and we connect them as shown in figure A.4.
Figure A.4: ESC connections to the ROV Battery
Figure A.5: An ESC

This A.6 is the first stand that we have used to hold the LED Matrix.
Figure A.6: Light Stand

The ROV has a camera that takes pictures underwater, and it is enclosed with a cylinder
enclosure to protect it from water.A.7
Figure A.7: ROV’s Camera
A.8 shows the I2C connection that is used to connect between the Arduino and the
Raspberry Pi.
Figure A.8: Micro-controllers Connection

Lastly, A.9 and A.10 show the ROV when we were still developing it.
Figure A.9: ROV Under Construction
Figure A.10: The ROV Under Development

Appendix B
AFROESC manual
119
AfroESC 30A USER MANUAL
Thank you for purchasing AfroESC, with a high efficiency, all N-channel MOSFET design, jitter-free
hardware PWM input, and smooth power response! The AfroESC series ship with SimonK software,
suitable for multi-rotor use without the need to program or adjust settings.
Caution
With any new build or after making any changes, always test carefully in a controlled environment.
Ensure propellers rotate in the correct direction and are tightened, that all signal connections are
in the right order and firmly connected. Motors connected in the wrong order may result in
uncontrolled flips. Never attempt to stop propellers by hand, and maintain a safe distance at all
times.
The AfroESC 30A has a lightweight BEC, capable of about 0.5A, which should be sufficient to power
most flight boards, but not servos. A dedicated BEC is recommended where servos or other
devices are used.
There is NO protection against reverse polarity, which would reduce efficiency and add weight. Be
sure that you connect RED to POSITIVE (+V) and BLACK to GROUND when wiring or attaching
bullets to avoid damage.
Software and Updates
If desired, the firmware may be upgraded and/or customized to enable or disable various features
such as complementary PWM, brake, RC-Car mode, or adjust default settings such as endpoints
and motor timing. The firmware can be updated using similar procedures as for the KK(2) and
other projects based on ATmega hardware. For source code, binaries, and other information, see
http://github.com/sim-/tgy/ and http://0x.ca/tgy/.
The easiest way of updating is with the Afro USB Linker from HobbyKing attached to the regular
PWM input cable. Only the signal and ground connections are required. The boot loader speaks
STK500v2 at 9600 baud using the half duplex protocol implemented by the Afro USB Linker. Other
linkers (such as USB serial linkers) will not work at this time.
The KKmulticopter Flash Tool or any general AVR ISP software may be used with any of the above
options. See the above URLs for links and more information.
Default Settings
Input control is available through PWM, or through I2C (MK) or UART with additional wiring (auto-
detected).
For PWM input, motor stop / arm below 1060µs, full power at 1860µs.
For I2C input, motor stop / arm at 0, start at 1, full power at 247. BL-Ctrl V2 reverse supported.
For UART input, motor stop / arm at 0, start at 1, full power at 200.
Low-voltage cut-off (input voltage checking) and temperature limiting are not enabled, as reacting
to such conditions on a multi-rotor will likely be worse than ignoring them. Always use a LiPo
battery alarm or telemetry to avoid over-discharging LiPo batteries!
General Operation
Once an input signal is received that is low enough to reach the “neutral” or power-off area, the
ESC will arm (long beep), and the green LED will light. Once the signal enters the motor start
range, the ESC will attempt to start or run the motor, and continue to do so as long as input signal
is above the neutral position. The amount of power used for starting is not fixed, just based on the
power requested, limited and ramped at first to increase the chances of a successful start.
In general, the power handling should be as smooth as possible, but not limited or filtered once
running. The default PWM frequency is 18kHz with 800 distinct steps, but may be adjusted to any
frequency. During starting, the PWM frequency is halved both to assist starting of some difficult
motors and as an audible indication of this state.
There is no latching of stopped or start states, as doing so could make acrobatic manoeuvres
unsafe. It should not ever be required to re-arm the ESC unless some signal, power, or hardware
fault occurs. In the event that an object (such as a tree) is struck by a moving propeller, the motor
will limit the power output until timing is regained, but not require re-arming. In the event that the
propeller is workable, this may permit a safer landing.
If a commutation time-out or long demagnetization period is detected, the red LED will light. This
should not occur in normal operation. Very brief flashes during rapid acceleration indicate that the
demagnetization period exceeded the expected zero-crossing point and that countermeasures
have been taken to avoid loss of synchronization. The green LED will remain off once running until
the power is turned off and the motor stops.
Throttle Range Calibration

With normal PWM input, ESCs and flight boards should be configured to match the expected
working range. If unmatched, the motors may not start until higher throttle signal is given, may
start “hot” even with a low throttle, may reach full power early, or may not reach full power. In
many cases, end-point calibration is not required unless the flight board outputs different ranges.
First, remove all propellers! Check to see if there are calibration steps documented for your flight
controller board. KK2 boards have a two-button procedure that performs automatical calibration.
With KK boards, the Yaw pot must be set to the minimum position in order to enable pass-through
mode from the receiver input to the ESC output, and the ESCs are then calibrated to the radio's
throttle throw. With the Naze32, try the console settings “set minthrottle=1064” and “set
maxthrottle=1864”. The same settings may be used for AutoQuad or other boards that allow the
endpoints to be specified.
If none of the above options are available, calibration may be performed manually. First, remove
all propellers! Disconnect the power to the ESCs. Connect the ESC PWM input directly to the
receiver's throttle channel, or to a servo tester.
Set the radio throttle or servo tester to the highest position, then connect power to the ESC. The
motor should produce a series of initialization beeps increasing in pitch, followed by another beep
matching the pitch of the last initialization beep. This indicates that the calibration mode has been
entered, and the pulse length has been learned.
Move the stick or knob to the lowest position. Two beeps of the same pitch should be emitted. This
indicates that the low pulse length has been learned. If the RC Car-style reversible mode has been
enabled (RC_PULS_NEUTRAL), move the stick or knob to the center, and wait for three beeps. This
indicates that the neutral (center) pulse length has been learned.
The ESC will then save the settings and exit calibration mode. If the input is still at the same
position, the ESC will arm (producing a higher pitched, long beep), and function normally.
NOTE: Throttle calibration is disabled to avoid accidental calibration if the ESC is reset by brown-
out during previous operation. If the power is not connected cleanly during the above steps, the
power-up may also be detected as a brown-out. If the rising beeps are not heard while attempting
to calibrate, disconnect the power for a few seconds, then try again.
Troubleshooting
To aid with troubleshooting, the AfroESC sports “ready” (green) and “error” (red) LEDs. During
power-up, the MOSFETs and drive circuitry are checked to ensure correct operation. During this
test, it may be unsafe to beep an error. If no beeps are heard from the motor, check to see if the
error LED is flashing, which should be visible through the heat-shrink. If so, count the number of
blinks between pauses and refer to the following list:
1 flash: Phase A stuck high

2 flashes: Phase B stuck high
4 flashes: Phase C stuck high
5 flashes: AIN0 (center neutral) stuck high
6 flashes: Phase A low-side drive fault
7 flashes: Phase B low-side drive fault
8 flashes: Phase C low-side drive fault
9 flashes: Phase A high-side drive fault
10 flashes: Phase B high-side drive fault
11 flashes: Phase C high-side drive fault
If no wiring fault or short is visible, one or more MOSFETs may have failed. The ESC must be
repaired or replaced. Otherwise, if the hardware check passes, the reason for reset is checked and
indicated by beeping through the motor and LED flashing. There are four main beep pitches:
Beep 1: Lowest pitch (also red LED).

Beep 2: Medium-low pitch (also green LED).
Beep 3: Medium-high pitch (no LEDs)
Beep 4: Highest pitch (also red and green LEDs together).
Beeps 1, 2, and 3: Normal power-up with no special event detected. A longer beep 4 normally
follows to indicate that an arming signal was detected.
Beep 3, beep 1: Voltage brown-out detected (MCU voltage dropped below 4.0V). If this happens
during battery connection, it can be safely ignored. If this happens during use, the ESC may have
drawn more than the power source is able to provide, and the input voltage dropped below about
5V.
Beep 4: External reset. Should only occur after programming.
Repeating beeps 1, 1, 3, 3: Watchdog siren. Previous execution locked up or was not able to signal
proper status, so to prevent motor or other damage, the ESC reset itself. Check for moisture
problems or strong fields right next to the ESC. If nothing is found, the MCU may be faulty.
Once a valid input is connected and the ESC is sees an idle power request, a long beep 4 is played
and the green LED lit to indicate that the ESC is armed. This is required for all input sources, and
must be maintained at a rate of at least 20Hz, or power will be switched off. If the input signal
stops, the ESC will disarm after 2 seconds and play beeps 3 and 2 to indicate that the input
disappeared. The ESC will look again for valid input sources, or programming input via the Turnigy
USB linker.
If no input is detected for more than 8 seconds, a periodic beep 3 every 3 seconds will be emitted
(beacon mode). This may aid in the location of a crash, assuming the signal is lost.
Appendix C
Li Fi Compatibles manual
124
Li-Fi
LI-FI
www.researchdesignlab.com Page 1
Li-Fi
Table of Contents
Overview ....................................................................................................................................................... 3
Visible Light Communication ........................................................................................................................ 3
What is LI-FI?????? ....................................................................................................................................... 4
Features ........................................................................................................................................................ 4
Application .................................................................................................................................................... 5
Li-Fi Tx side .................................................................................................................................................... 5
Connection with LED Panel ........................................................................................................................... 6
Li-Fi Rx side.................................................................................................................................................... 7
Experimental Setup ....................................................................................................................................... 8
LI-FI CODE TX ....................................................................................................................................... 11
Li-Fi CODE RX ........................................................................................................................................ 11
Li-Fi
Overview
At the heart of this technology, a new generation of high-brightness light-emitting diodes. Very
simply, if the LED is ON, user can transmit a digital string of 1, if it’s OFF then user can transmit a string
of 0. It can be switched ON and OFF very quickly, which gives instant opportunity for transmitting data.
It is possible to encode data in the light by varying the rate at which the LEDs flicker ON and OFF to pass
different strings of 1s and 0s. The modulation is so fast that the human eye doesn’t notice. There are
over 14 billion light bulbs used across the world, which needs to be replaced with LEDs ones that
transmit data.
Visible Light Communication
Communication system components are:
1. A high brightness white LED which act as a communication source.

2. Silicon photo diode which shows good response to visible wavelength region.
LED illumination can be used as a communication source by modulating the LED light with the
data signal. The LED light appears to be continuous to the human eye due to the fast flickering
rate. The high data rate can be achieved by using a high speed LED’s and appropriate
multiplexing technique. Each LED transmits at different data rate which can be increased by
parallel data transmission using LED arrays.
Li-Fi
What is LI-FI??????
VLC represents only a fraction of what appears to be a much larger movement towards optical wireless
technologies in general. This larger world has been dubbed ‘Li-Fi’ (Light Fidelity) by people such as Dr
Harald Haas of Edinburgh University and organizations such as the Li-Fi Consortium.
Li-Fi is transmission of data through illumination of the LED by taking the fiber out of the fiber optics by
sending data through the LED light bulb that varies in intensity faster than the human eye can follow.
The LED blubs will hold a micro-chip that will do the job of processing the data.
The light intensity can be manipulated to send the data by tiny changes in the amplitude.
This technology uses visible spectrum of light, a part of the electromagnetic spectrum that is still not
greatly utilized.
In fact this technology transfers thousands of streams of data simultaneously in parallel in higher speed
with the help of the special modulation using a unique signal processing technology.
The light used to transmit the data is called D-light by herald hass, the inventor of LiFi.
Features
 Transmit data serially at 38400 baud rate
 Distance of 1 feet to 10 feet can be achieved
 low power requirement
 no effect on human health
 highly secure compared to Wi-Fi
 high data density because visible light can be well contained
Li-Fi
Application
 Indoor wireless open optical communication.
 Indoor navigation.
 Under water visible light communication.
 Smart indoor blind assistive application.
 Vehicle to vehicle communication.
 Depends on the LED power.
Li-Fi Tx side
• The Tx side will transmit the data.

• It is connected to arrays of led
through which data is transferred.
• This data will be received by the
receiving side(Rx) side .
Li-Fi
Connection with LED Panel
Li-Fi
Li-Fi Rx side
 The receiver side will receive the data that is
transmitted through the led panel
 This led can be displayed to the HyperTerminal of
the Pc by connecting a serial uart
Block Diagram
Li-Fi
Experimental Setup
 Make the required connection as show n in the pic
 Place the jumper in the configure mode
Li-Fi
 For the receiver section also place it in config mode
 Once both the jumper are in the configure mode place the led panel aligned to the receiver
at the same time move the pot of the receiver till you see the led glowing on once the led
glows means that the led panel is configured for that distance and angel
Li-Fi
 Now keep that led panel steady at that same place and change the jumper from configure to
run mode
In receiver side
In transmitter side
Li-Fi
CODE
(set baud rate to 38400)
LI-FI CODE TX
http://researchdesignlab.com/module-code-lifitx
Li-Fi CODE RX
http://researchdesignlab.com/li-fi-arduino-code.html
Appendix D
RDL Li-Fi
136
RDL_LI-FI
RDL_LI-FI
RDL_LI-FI
Contents:
Introduction……………………………………………………………………...3
Features………………………………………………………………………….3
Applications…………………………………………………………..…………3
Compatibility …………………………………………………………………...4
Package contains………………………………………………………………...4
Internal Block connections……………………………………………………...4
Installing pyserial package………………………………………………………5
Sample Python script …………………………………………………………...6
RDL_LI-FI
Introduction:
At the heart of this technology, a new generation of high-brightness light-
emitting diodes. Very simply, if the LED is ON, user can transmit a digital
string of 1, if it’s OFF then user can transmit a string of 0. It can be switched
ON and OFF very quickly, which gives instant opportunity for transmitting
data. It is possible to encode data in the light by varying the rate at which the
LEDs flicker ON and OFF to pass different strings of 1s and 0s. The modulation
is so fast that the human eye doesn’t notice. There are over 14 billion light bulbs
used across the world, which needs to be replaced with LEDs ones that transmit
data.
Features:
 It can transmit data 38400 baud rate serially.

 Distance can be achieved 1 Feet to 10 Feet for wireless open optical
communication*.
 High intensity LED matrix.
 High quality PCB FR4 Grade with FPT Certified.
Applications:
 Indoor wireless open optical communication.
 Indoor navigation.
 Under water visible light communication.
 Smart indoor blind assistive application.
 Vehicle to vehicle communication.
RDL_LI-FI
Compatibility:
 Raspberry Pi
 Raspberry Pi 2
 Raspberry Pi Model B+
 Raspberry Pi zero
Package Contains:
LiFi (Visible Light Communication) Compatible for Raspberry Pi + LED
Matrix
Note1 : The Raspberry Pi in the picture above is just for reference , it does not
include in the package.
Note2: Base board is only used for soldering the LiFi shield and establishing
the respective connectivity with Raspberry Pi I/O pins.
Note3: Single panel will give you the distance maximum up to 1Ft-30CM. By
cascading 4 LED panels you can communicate with distance of 120CM.
Internal Block connections:

Li-Fi Tx:
RDL_LI-FI
Li-Fi Rx
Installing pyserial package:
First download and install python serial package called pyserial from the below
site.
https://pypi.python.org/pypi/pyserial
unzip the file and enter into that folder using command
cd “package name”
inside the package name there will be setup file, called setup.py. install the
software by typing following command.
sudo python setup.py install
RDL_LI-FI
Setup file
Package name
Sample python code:
Please go through Lifi fine tune steps mentioned in the below link
http://researchdesignlab.com/projects/Li-Fi.pdf
Testing Lifi-Rx board:
 Connect Lfi-Rx board to one raspberry pi and open nano editor by typing
following command
Nano filename.py
RDL_LI-FI
 Type the following code inside the editor

import serial
ser = serial.Serial('/dev/ttyAMA0',38400)
while True:
p = ser.readline()
print p
RDL_LI-FI
 now run the code by following command
sudo python filename.py
When we press switch S2 on Li-fi board we can see research designlab.com is

printing on raspberry screen.
RDL_LI-FI
Testing Lifi-Tx board:
 Next connect Lifi-Tx to another raspberry board and run same test1.py
code on Lifi-Rx board. And press reset switch on Lifi-Tx board. This will
print researchdesignlab.com on Lifi-Rx raspberry pi screen.
RDL_LI-FI
Communication between Lif-Tx and Lifi-Rx:
 open nano editor in Lifi-Tx raspberry and enter following code
import serial
import time
ser = serial.Serial('/dev/ttyAMA0',38400)
while True:
a=raw_input("Type a message to Transmit: ")
ser.write( a)
time.sleep(5)
 Run the above code by typing following command. And at the same time
run Li-Fi –Rx code in another raspberry pi
sudo python filename.py
RDL_LI-FI
 We can see whatever message typed in Lifi-Tx is printing on Lifi-Rx.
LiFi-Tx
RDL_LI-FI
LiFi-Rx
Appendix E
Instructional Manual
149
Applications of Li-fi
Instruction Manual
June 2017
1 File Transfer Application

1. Connect each raspberry pi (transmitter and receiver) to a keyboard and
a mouse, and to a monitor through an HDMI cable then turn them on.
2. The Li-Fi compatibles require configuring it as follows:
• First and foremost, the Receiver and the transmitter modules are
connected to a raspberry pi as shown in Figures Fig.5 and Fig.4.
It is required to connect the baseboard of the Li-Fi compatibles to:
5v, 3.3 v, and the UART pins on the raspberry pi which are the
UART0TxDGPIO (GPIO 14) and UARTT0RXD(GPIO 15).
Figure 1: Shows the Connections of Baseboard of the Li-Fi Transmitter Module

to the Raspberry Pi
1
Figure 2: Shows the Connections of Baseboard of the Li-Fi Receiver Module to
the Raspberry Pi
Figure 3: Shows the Internal connections of the Li-Fi Receiver Module
2
• Afterwards, the LED matrix is connected as follows in Fig.4. An
external power source of (12v) is needed to brightly light up the
LED panel, which is censorious for maintaining the continuity of
data stream. A LED stand is utilized at this stage considering the
significance of the stability of the LED Matrix.
Figure 4: Shows the Connection of the LED Matrix to the Transmitter Module
Figure 5: The Overall Connection of the LED Panel to the Receiver Module
• The receiver module is then placed in the field of sight of the LED
Matrix where a clear line of sight is preserved. In this step, both
the transmitter and the receiver modules should be in config mode
during the setting up phase.
Figure 6: Config Mode
3
• The pot shown in Fig.7 is rotated until the indicator LED glows up
show that the sensibility of the photo-diode (PD) on the receiver
module to the lightening of the LED matrix has been verified.
Figure 7: The Steps Followed in Configuring the Receiver Module
• Finally, the mode shown in Fig.6 is changed into run mode instead
of config mode by removing the jumper from the config mode and
placing it into the run mode.
3. On the receiver raspberry pi, click on the menu button on the top left side
of the screen. Go to Programming, and from the the list that appears,
choose Python 2.
4. A python window will open. Go to File ¿ Open to choose the python file
to open from the browse window. In this case, it is FileR.py. When the
file opens, go to Run ¿ Run Module.
5. Repeat the previous 2 steps on the transmitter raspberry pi, but this time
run the FileT.py file. A graphical user interface will pop up as shown in
fig 8.
Figure 8: File Transfer Transmitter Graphical User Interface (GUI)
4
6. Click the browse button to choose the file you wish to send, and choose
the file type from the radio buttons. Click send to transmit, and the file
will appear on the desktop of the receiver raspberry pi.
2 Underwater ROV Application

1. Connect each of the ESCs to a battery.
2. Connect the Arduino to power first, then turn on the receiver raspberry
pi and the transmitter raspberry pi and connect to the transmitter pi to
a monitor, keyboard, and mouse.
3. Go through the same configuration steps mentioned in the previous section

(step 2 in section 1).
4. Wait for the raspberry pis to boot, then SSH to the receiver pi to remotely
control it. (Make sure to be connected to the dlinkdlink network use the IP
address 192.168.1.108; the username is pi and the password is raspberry)
5. On the receiver pi, type ”sudo python RovR.py” to run the receiver pro-
gram.
6. On the transmitter pi, open Python IDLE. From there open the RovT.py
and run it. A graphical user interface will pop up as shown in fig 9
Figure 9: ROV Transmitter Graphical User Interface (GUI)
7. Use the slider to change the angle of the servo motor, and the Snap button
to take pictures.
8. To move the ROV itself (brushless DC motors), first click on the GUI,
then use the WASD keys on the keyboard to control the movement.
5
Bibliography
[1] Li-fi over wi-fi in internet data. . URL http://www.ijireeice.com/upload/2015/

december-15/IJIREEICE%2032.pdf.
[2] ”what is li-fi?”. . URL http://purelifi.com/what_is_li-fi/.
[3] How does lifi work? . URL http://purelifi.com/what_is_li-fi/

how-does-vlc-work/.
[4] ”top 10 li-fi myths”. . URL http://visiblelightcomm.com/

top-10-li-fi-myths/.
[5] Evaluation of underwater optical-acoustic hybrid network. . URL http://nrlweb.

cs.ucla.edu/publication/download/806/chinacom14.pdf.
[6] ”just how little do we know about the ocean

floor?”. . URL http://theconversation.com/
just-how-little-do-we-know-about-the-ocean-floor-32751.
[7] Alan Jamieson. ”10 things you never knew about the ocean’s deep-
est places”. URL http://www.independent.co.uk/environment/
10-things-you-never-knew-about-the-oceans-deepest-places-a6907316.
html.
[8] ”how do rovs work?”. . URL http://www.rigzone.com/training/insight.asp?

insight_id=343&c_id=17.
[9] Communication networks/tcp and udp protocols. . URL https://en.wikibooks.

org/wiki/Communication_Networks/TCP_and_UDP_Protocols.
[10] ”implementation of a simple li-fi based system”. . URL http://www.ijcat.org/

IJCAT-2014/1-9/Implementation-of-A-Simple-Li-Fi-Based-System.pdf.
[11] Yasmina Al Khalil Mohammed Ghazal. ”iotsmartphonecontrolledsecuresubmissionofe-

assessments ”. 2015.
155
Bibliography 156
[12] ”an integrated, underwater optical /acoustic communications system”. . URL

https://www.whoi.edu/fileserver.do?id=64583&pt=2&p=76726.
[13] ”rov applications - design - cable3”. . URL http://www.rov.org/rov_design_

cables.cfm.
[14] Alexander graham bell made a wireless phone that ran on

sunshine”. . URL https://motherboard.vice.com/read/
alexander-graham-bells-wireless-phone-that-ran-on-sunshine.
[15] Selenium cell. . URL http://physics.kenyon.edu/EarlyApparatus/

Electricity/Selenium_Cell/Selenium_Cell.html.
[16] Raspberry pi. . URL https://www.raspberrypi.org/.
[17] Lifi visible light communication compatible for rasp-

berry pi”. . URL https://researchdesignlab.com/
lifi-visible-light-communication-compatible-for-raspberry-pi.html.
[18] Built-in functions. . URL https://docs.python.org/2/library/functions.

html#open.
[19] Raspberry pi and the serial port. . URL http://www.hobbytronics.co.uk/

raspberry-pi-serial-port.
[20] ”base64 encoding and decoding using python”. . URL https://code.tutsplus.

com/tutorials/base64-encoding-and-decoding-using-python--cms-25588.
[21] ”controlling servo motors”. . URL http://razzpisampler.oreilly.com/ch05.

html.
[22] ”about li-fi”. . URL http://www.velmenni.com/about-Li-Fi.php.

Li-Fi Based Application Final Report

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Li-Fi Based Application Final Report

Caricato da

Copyright:

Formati disponibili

College of Electrical and Computer Engineering

EEN450: Design Project (Capstone)

Li-Fi Based Applications

Aya Iyad Murad 1046415

A thesis submitted in partial fulfillment for the

I have acknowledged all main sources of help.

by Raghad JZ Abu-olwan 1045560

List of Figures viii

1.8 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Discussion and Results 95

5.3 Final Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6 Conclusion and Future Work 110

B AFROESC manual 119

C Li Fi Compatibles manual 124

D RDL Li-Fi 136

E Instructional Manual 149

1.1 Diagram of proposed system for file transfer using Li-Fi . . . . . . . . . . 5

2.1 The Transmitter side of the System . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Raspberry Pi Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 Gantt Chart depicting our schedule for the project . . . . . . . . . . . . . 87

5.1 The Code Used for Testing the Receiving side . . . . . . . . . . . . . . . . 96

A.1 The ROV Moving Forward . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.9 ROV Under Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

1.1 Problem Statement

1.1.1 File transfer application

1.1.2 Underwater Optical Communication

Figure 1.2: A Tethered ROV

1.3.1 What is Li-Fi

Figure 1.4: Frequency spectral

1.3.1.1 Li-fi vs Wi-Fi

Figure 1.5: Li-Fi vs Wi-Fi

1.3.2 Li-Fi working principle

Figure 1.6: Li-Fi principle

Figure 1.7: Li-Fi Transmitter and Receiver block diagrams

1. Transmitter section: The transmitter is a part of the visible light commu-

Source device → Data Reading Module → Data Conversion Module → Transmitter

• Data Conversion Module: It might encrypt the data at first. It represents

2. Receiver section: The Li-Fi receiver main components could be propagated

• Receiver Module: it includes the photo-diode which is main job to reveal

1.3.3 Misconceptions about Li-Fi

1.3.4 Harald Haas Achievement

Figure 1.8: Li-Fi system implemented by prof. Harald Haas

1.3.5 Optical Underwater Communication Systems

1.3.6 History of ROVs

1.3.7 UDP and TCP Protocols

1.4 Literature Review

1.4.1 Implementation of a file sending system using Li-Fi

1.4.2 Implementation of file sending system using Wi-Fi

1.4.3 Acoustic and optical underwater systems working principle

Communication using Radio Frequency is efficiently transmitting data at high speeds

1.4.3.1 Under Water Systems: A comparison between Underwater Acoustic

1.4.4 Line of Sight for underwater optical communication

1.4.4.1 Optical Systems

1. Ar : Representing the area of the receiver.

2. At : Representing the area of the transmitter.

3. β: Inclination angle to the receiver.

4. θ: Half of the transmitter field-of-sight.

5. L: Distance to the receiver.

Fig.1.11 models a transmitter A and a receiver B in an optical system, where transmitter

Figure 1.11: Illustrates the inclination angle β and θ diverge angle

be attenuated significantly in shorter distances. The effective range is inversely propor-

Figure 1.14: Photophone

1.5 Economic Impact Statement

1.6 Society Impact Statement