Localizare Folosind Dispozitive Mobile: Alexandru Popa

Universitatea Politehnica din Bucureşti
Facultatea de Automatică şi Calculatoare

Departamentul de Automatică şi Informatică Industrială
Lucrare de Licenţă
Localizare Folosind
Dispozitive Mobile
Alexandru Popa
Coordonatori Ştiinţifici
Prof. Dr. Ing. Nicolae Ţăpuş
As. Drd. Ing. Silvia Cristina Stegaru
Bucureşti, Iulie 2016

University Politehnica of Bucharest
Faculty of Automatic Control and Computers
Computer Science and Engineering Department
Diploma Thesis
Indoor Localization
Using Mobile Devices
by
Alexandru Popa
Supervisor: Prof. Dr. Eng. Nicolae Ţăpuş

Supervisor: Associate Prof. Drd. Eng. Silvia Cristina Stegaru
Bucharest, July 2016

Contents
Contents i
List of Figures ii
List of Tables iii
1 Introduction 1
2 State of the Art and Related Work 2
3 Hardware and Software Configuration 8

3.1 General description of the solution . . . . . . . . . . . . . . . . . . 9
3.2 WiFi Trilateration based on RSS measurement collection . . . . . 18
3.3 Hardware Implementation . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 ESP8266-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Raspberry PI 3 . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.3 Android-based smartphone . . . . . . . . . . . . . . . . . . 23
3.4 Software Implementation . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 The Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 The Access Points . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 The Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.4 The Client-Server Model . . . . . . . . . . . . . . . . . . . . 44
4 Case study 47
4.1 Results based only on raw RSS values . . . . . . . . . . . . . . . . 48
4.2 Results based on RSS measurement collection . . . . . . . . . . . . 50
5 Conclusions and Future Work 52
Bibliography 54
Listings 56
i
List of Figures
2.1 Positioning Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Detection techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Angle of arrival method . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Access Points Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Access Points Broadcast Range . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Lateration Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Invalid Case:r12 + L2 < r22 . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Invalid Case:r22 + L2 < r12 . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Invalid Case: x > l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Imperfect Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 ESP8266 Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . 20
3.9 Raspberry PI 3 Model B . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.10 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11 Started Service Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Interface for the MainActivity . . . . . . . . . . . . . . . . . . . . . . 31
3.13 Interface for the WifiActivity . . . . . . . . . . . . . . . . . . . . . . . 32
3.14 Interface for the AddMapActivity . . . . . . . . . . . . . . . . . . . . 34
3.15 Access point scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.16 Client - Server Communication . . . . . . . . . . . . . . . . . . . . . . 46
4.1 Localization Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Results based only on raw RSS values . . . . . . . . . . . . . . . . . . 49
4.3 Results based on RSS measurement collection . . . . . . . . . . . . . . 51
ii
List of Tables
3.1 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 FSPL constant dependence on units as computed in (3.5) . . . . . . . 11
3.3 ESP8266-01 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 raspi-config Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Samsung Galaxy S4 Mini Technical Specifications . . . . . . . . . . . . 24
3.6 Fields for the ScanResult class . . . . . . . . . . . . . . . . . . . . . . 29
3.7 ESP8266 Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 ESP8266 Security Modes . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 DbHelper Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.10 Packet Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Results based only on raw RSS values . . . . . . . . . . . . . . . . . . 48

4.2 Results based on RSS measurement collection . . . . . . . . . . . . . . 51
iii
Chapter 1
Introduction
Indoor localization represents a topic that aims to create systems and solu-
tions which can locate people or objects within an indoor environment. Although
there is no standard or best solution for indoor localization, systems have been
developed using a range of technologies such as optical, radio, magnetic or even
acoustic systems.
Regarding positioning in an outdoor environment, Global Positioning System
(GPS) is the technology developed by the United States of Defense and mainly
used for military purposes in navigation and coordinate measurements [13]. Other
applications of global navigation satellite systems have been deployed in a wide
range of domains such as tracking and asset management systems, transport
navigation and guidance or synchronization of telecommunications networks.
However, using GPS, the optimum signal performance can only be achieved
in an outdoor environment and not within an indoor environment. GPS is not
effective in urban areas, close to walls, buildings, trees, interiors and in under-
ground environments as the signal from the GPS satellites is too weak to come
across most buildings. This happens because the signal transmitted by a satellite
is affected by multiple reflections including roofs, walls and other objects causing
multi-path interference in an indoor setup.
Indoor localization can be defined as any system that provides a reliable
solution for acquiring a precise position in a closed area such as airports, hospitals
or shopping malls. Due to the nature of a closed structure, the development of
indoor positioning solutions raises a number of issues such as creating floor plan
based maps of indoor environments, using an appropriate and effective technology
and deploying the most suitable positioning devices.
In the present thesis, the main objective is implementing a cost-effective solu-
tion for indoor positioning using the trilateration method based on measurement
collection from two access points.
1
Chapter 2
State of the Art and Related

Work
The current position of a device is a very useful property in a variety of

applications and for many different operations. Because of the many available
technologies, a lot of analysis and research has been done in the area of localiza-
tion systems. At the current moment, the most prominent implemented wireless
positioning systems can be seen in Figure 2.1.
Positioning
Systems
Infrared Based Radio Frequency Ultrasound

Systems Based Systems Based Systems
Wireless LAN
RFID
Bluetooth
ZigBee
UWB
FM
Figure 2.1: Positioning Systems
2
CHAPTER 2. STATE OF THE ART AND RELATED WORK 3
Infrared based systems, usually available in a wireless technology, use the

spectral region of infrared for detecting people or objects. The great advantage
of infrared based systems is that they are lightweight. However, they usually use
a line-of-sight communication between the transmitter and the receiver which is
prone to interference from light sources and sunlight and generally have a high
implementation cost [14].
Ultrasound based systems use signals in a low frequency band to estimate
the position of emitter tags from the receiver. Such systems have a low level
of precision and are affected by interference from ultrasound signals emitted by
other sources [20].
The most advantageous technologies are the radio frequency technologies
mainly due to the fact that the radio waves can penetrate with ease through
obstacles like human bodies or building walls. Radio frequency based systems
also require less hardware comparing to other indoor positioning systems. More-
over, radio based technologies can be divided into wide band based technologies
(such as UWB) and into narrow band based technologies (such as RFID, Blue-
tooth, WLAN and FM).
Radio frequency identification (RFID) is a technology which aims at tracking,
management and automatic identification and uses radio signals to put an RFID
tag on people or objects, based on an unidirectional wireless communication.
The movement of objects in RFID are tracked over a distance of several meters
through a network of scanning devices which are radio enabled [12].
Bluetooth is a wireless standard which operates in the 2.4GHz ISM band.
Mobile phones, computers and almost every WiFi enabled mobile device have
an embedded bluetooth module [8]. Bluetooth comes with several advantages
such as small size, low cost and high security making it suitable for exchanging
information between devices. Positioning using bluetooth technology is based on
bluetooth tags which have an unique ID, used for localization. However, blue-
tooth technology has a significant response time for localization (around 10-30
seconds) because in each location discovery it executes the device detection pro-
cedure and the power consumption is high as well. Generally, bluetooth devices
are unsuitable for real-time positioning systems due to the significant latency.
An indoor positioning system based on bluetooth technology was developed
by 9solutions which uses tags that include a cell battery powered bluetooth radio
transceiver. The nodes forward the tags’ bluetooth transmissions to the Cell
Controller Unit (CCU) - a gateway device - which also sends the data to the server
via Wi-Fi/wired connection. The latest version of 9Solutions’ system includes an
app for the iPhone 4S which will operate with any mobile phone supporting
bluetooth 4.0 [5].
Frequency modulation (FM) radio based systems are widespread across the
globe preeminently in most households and in cars. The frequency band is split
into a number of different channels used by stations using the frequency-division

multiple access (FDMA) approach. Depending on the region, there are various
FM band ranges and channel separation distances. Research on indoor localiza-
tion using FM radio signals has been done in [17].
Another wireless technology standard developed for medium and short range
communications is the ZigBee technology. It presents several characteristics such
as the low-power consumption when the data throughput is not significant and
the signal range coverage of around 20 to 30 meters. The main drawback of the
ZigBee technology is that the distance calculation between two ZigBee nodes is
based on the received signal strength values. These values are distorted by a wide
range of signal types using the same frequency because Zigbee operates in the
unlicensed ISM bands [19].
Ultrawideband (UWB) is a radio technology for short distance, high-bandwidth
communication with strong multipath interferences. The UWB technology is de-
ployed for localization applications requiring a high level of accuracy (20 to 30
cm) which can not be generally achieved through the conventional wireless tech-
nologies presented above. UWB hardware is rather expensive as it requires a
stimulus radio wave generator and receivers which can capture the propagated
and scattered wave [20].
The most widespread approach for indoor localization are the WiFi position-
ing systems because they can detect and locate almost every WiFi enabled device
without requiring additional software or hardware manipulation. In addition, in
WLAN, line of sight is not a constraint as it was the case with infrared radiation
systems.
Most positioning systems using WLAN are based on measurements of the
properties of the received signal, the most widely used signal feature being the
received signal strength indicator (RSSI). WiFi based positioning systems have
several advantages as follows.
Regarding the cost, WLAN infrastructures implementation of position al-
gorithms does not need any additional hardware due to the fact that network
interface cards (NICs) are able to measure signal strength values from all wire-
less access points in range of the receiver. Thus, the NICs available on most
mobile devices can directly provide the signals needed for positioning. This so-
lution is particularly cost-effective for the deployment of location based systems
in commercial and residential indoor environments.
Another advantage is the fact that most WLAN positioning systems offer
scalability in regard with two aspects. Firstly, a WLAN localization system
does not require a dedicated infrastructure and, secondly, the number of mobile
devices used in localization is ever increasing. However, there are also certain
WLAN drawbacks such as signal attenuation of the static environment like walls
or movement of indoor objects [11].
The main location detection techniques are presented in Figure 2.2.
Position
Detection
Proximity Triangulation Scene Analysis
Direction based Distance based
Method based Methods Methods based

on angles based on time on signal property
Figure 2.2: Detection techniques
Proximity detection is a localization method based on connectivity in which

the position of the target is assessed using the cell of origin approach. The
precision of such a method depends on the signal strength and on the number
of access points deployed and it can be implemented with various technologies
presented above such as RFID, IR or bluetooth [9].
One of the most known methods is the triangulation which uses geometrical
interpretations to assess the subject’s position. This approach can be further
divided into angulation (direction based) techniques such as AoA and lateration
(distance based) techniques (e.g ToF, RTT, TDoA, RSS-based).
The angle of arrival (AoA) technique is used in determining the position of
RFID tags using two or more antenna arrays or highly directional antennas [18].
The angle of arrival of the received tag signal is assessed at each antenna array
and the location can be estimated using geometric equations as outlined in Figure
2.3. The drawback of this technique is the necessity for additional antennas with
the capacity to estimate the angles of arrival.
The lateration techniques determine the target position by measuring its dis-
tance from multiple known reference points. Time of Flight (ToF) is based on
precise synchronization between the arrival time of a signal sent by the target
device and the receiving access points. The distance between the receiving points
and the mobile device is calculated based on the speed of the signal and time de-
lay of the transmission. The general approach is to synchronize the target device
and the receiving nodes to the same time source. The benefit of such a method
is that multi-path reflections are filtered in indoor setups [16].
While ToF uses a synchronized time source of transmission, TDoA (Time
Difference of arrival) uses relative time estimations at each receiving access points
Figure 2.3: Angle of arrival method
with the purpose of finding the location [10]. In this approach, only the receiving
nodes are synchronized, and when a signal with unknown starting time arrives at
the receivers, the algorithm uses the difference of arrival to estimate the target’s
position.
If ToF and TDoA are based on time measurements from the source to the
receiver, Round Trip Time (RTT) method calculates the time of flight from the
transmitter to the receiver node and back. Thus, the increased complexity of the
location scheme development for time synchronization between wireless nodes is
avoided [1].
Signal property based methods are mostly applied in wireless positioning sys-
tems and calculate the distance to the mobile device using properties of the re-
ceived signal such as the received signal strength indicator (RSSI) which is highly
influenced by the environmental interference. To deploy methods based on the
signal properties, access points are generally preferred rather than WiFi routers
as they represent a less expensive solution.
WiFi RSS methods can be divided into two main categories: radio propaga-
tion based methods and fingerprint based methods [22]. The radio propagation
model-based methods deploy at least three access points whose coordinates are
known to approximate position with triangulation.
Fingerprint based methods use the RSS values to construct a fingerprint map
which is then used for real-time localization. The positioning process has two
phases: an offline phase in which a set of RSS values is collected by a measurer
with a mobile device in distinct locations. A fingerprint map is then constructed
based on this set of RSS values. The second phase is the online phase which
uses the RSS values of the target device and determines the best match in the
fingerprint map. However this method poses issues for different mobile devices
which can scan different RSS values in the same physical location [3].
Therefore, WiFi positioning systems are the most advantageous technology
for localization of easily accessible devices among the population such as smart-
phones. The idea of tracking smartphones through WiFi systems implies the
deployment of access points along with WiFi enabled mobile devices to locate
the approximate position. The implemented algorithm will use the user’s sig-
nal strength and frequency to determine the position through the trilateration
techniques.
Chapter 3
Hardware and Software

Configuration
Generally, an indoor localization system is comprised of core elements such

as the server and the clients, and several transceivers used in the positioning
algorithm. The clients serve as the targets or as the elements whose position has
to be determined. The transceivers measure or receive data necessary for the
algorithm from the clients and forward it to the server. It is also possible for
the client to measure certain parameters from the access points and then send
it to the server. The server implements the localization algorithm tracking the
position of the clients.
The client is a constituent element of the Client-Server model which acquires
data from or accesses a service provided by the server. In wireless networks,
the most often clients whose position is of interest are mobile devices with WiFi
capabilities.
At the present moment, the bulk of mobile devices amounts to smartphone
devices running on operating systems such as Android, iOS, Windows Phone,
Java ME and others. Because the statistics suggest that out of these, currently,
Android holds a 70.85% market share of the mobile operating systems [21], in the
present solution, a Samsung Galaxy S4 Mini GT-I9195 with the 4.2.2 JellyBean
version of Android installed was used as the client device.
The role of the transceivers is played by two wireless access points whose
positions are known. An access point is an element in a network which can
receive and transmit data from and to other stations. The primary role of an
wireless access point is to provide connectivity to a wired network for any WiFi
compliant device.
The access points where designed specifically for testing purposes and consist
8
CHAPTER 3. HARDWARE AND SOFTWARE CONFIGURATION 9
of an ESP8266-01 module connected to an Arduino board in order to configure

and power up the wireless chip.
The server was implemented using a Raspberry PI 3 micro-computer which
centralizes the data collected from the clients and from the access points, executes
the positioning algorithm to determine the position of the client and analyzes the
validity of the data.
The hardware configuration of the positioning system consists of several ele-
ments as presented in Table 3.1.
Software Hardware
Role Components
Samsung Galaxy
Client
S4 Mini
Raspberry PI 3
Server
Model B
ESP8266-01,
Access Points
Arduino Uno
Table 3.1: Hardware Components
Apart from the positioning goals, the localization system needs to meet several
other requirements:
• No special hardware required in the localization area
• Ease of maintenance and setup
• Localization with an accuracy error less than one meter
• Adaptable to system and environmental adjustments
• Can be used in large rooms
3.1 General description of the solution

Although, generally, in trilateration techniques, at least three WiFi access
points are deployed, the proposed solution will use the signal strength received
from only two access points, reducing the overhead and requiring less hardware
infrastructure.
The localization area is the space of a rectangle room whose dimensions are the
length L and width l. The objective of the positioning system presented in this
study is to accurately localize a mobile device in this area. One issue that is raised
is how to effectively position the two access points relative to the localization area
in order to acquire precise and sufficient measurement for positioning the mobile
device.
The mobile device will scan the connectivity data of all available access points
within range periodically at a configured refresh rate. Each scan result describes
information about an available access point such as the MAC address of the
network, the name of the network, the capabilities of the network (encryption
schemes, authentication, key management), the access point channel bandwidth,
the frequency of the channel, the received signal level and a time stamp in mi-
croseconds of the moment the respective result was last seen.
Out of all the detected access points, only the scan results of the two config-
ured access points will be analyzed and sent to the server for further analysis and
computation. However, these measurements may be erroneous and the algorithm
needs to account for these issues.
The properties of the underlying electromagnetic wave produced by the access
points is prone to reflections, scattering and diffraction. When there exists an
unimpeded line of sight (LOS) between the receiver and the transmitter, the
received signal strength is estimated using the free space propagation model.
This model states that the received signal power decreases with the square of the
distance [2] as shown in (3.1) . However, unobstructed LOS paths are rarely met
in real indoor or even outdoor environments.
1
RSSr ∼ , d - distance; RSSr - received signal power (3.1)
d2
The distance travelled by the signal from transmitter to receiver can be de-
termined by comparing the transmitter power and the receiver power. This dif-
ference is called ”path loss”. In real world situations, the path loss has a different
path loss - distance dependence in different environments. Because of that, the
received signal strength is also a function of the path loss exponent (symbolized
as n) as seen in (3.2):
RSSd0
RSSr = (3.2)
(d/d0 )n
where RSSd0 represents the received power at the distance d0 , which is gen-
erally a fixed constant. The distance is usually estimated using the log-normal
path loss model which is described in equation (3.3):

λ 1
RSSr = RSSt + 20 log + 10n log (3.3)
4π d
in which RSSt is the power at the transmitter, λ is the wavelength (expressed

in meters) and n is the path loss exponent. A particular case of (3.3) is the free-
space path loss model, which is obtained when n = 2 (3.4):
2
4πd
RSSF SP L =
λ
2 (3.4)
4πdf
=
c
where f is the frequency of the signal (expressed in Hertz) and c is the speed
of light in vacuum (expressed in meters per second). From (3.4), the received
signal strength can be expressed in dBm as follows:
RSSF SP L = 20 log10 d + 20 log10 f + k (3.5)
where k is a constant which depends on the frequency and distance units as

described in Table 3.2:
Frequency Distance
k
Unit Unit
Hz m -147.55
kHz m -87.55
MHz m -27.55
MHz km 32.45
GHz km 92.45
Table 3.2: FSPL constant dependence on units as computed in (3.5)
In Android systems, the WiFi Manager measures the frequency of the received
signal in MHz and the distance will be measured in terms of meters. Therefore,
from Table 3.2, the third constant will be used in the proposed solution:
RSSF SP L = 20 log10 d + 20 log10 f − 27.55 (3.6)
The distance between the access point and the mobile device can then be
expressed in meters as follows:
d = 10(RSSF SP L +27.55−20 log10 f )/20 (3.7)
However, this estimation needs to address several issues that can lead to errors
in the approximation of the distance.
Practically, when a radio wave comes across another wave with distinctive
electrical properties, the radio wave is either partially reflected and in some mea-
sure absorbed. As such, the reflection is generally determined by frequency, the
wave’s incidence angle and polarization. The diffraction component generates

a compensatory signal which allows the reception of the signal even behind ob-
structions.
Through the scattering process, widely used in radar techniques [4], the energy
is reflected in all or at least many directions. It directly depends on the frequencies
used in WiFi communications.
Many objects, whether still or moving, are the cause of scattering, reflections
and diffraction. Because of this, the RSSI measurement does not depend only
on distance, but also on the interferences between the receiver and transmitter.
Another issue is that although the physical position is not changed, the RSSI
values can still fluctuate if there are moving objects or people in the localization
area.
There are also blind spots, locations where no signal can be captured because
of the multi-path propagation. In such systems, an objective is to minimize or
even eliminate, if possible, the blind spots. This can be achieved by deploying
the transmitters in appropriate locations and as far from each other as possible
[2].
As there are only two access points used in the positioning process, they need
to be deployed in adjacent corners of the localization area as shown in Figure
3.1. Also, the maximum broadcast range of each access point has to cover the
entire area of localization, in order to successfully position the mobile device in
each point of the room as illustrated in Figure 3.2.
As one can observe in Figure 3.1, a system of coordinates was attached to the
localization area. The origin of the system is represented by the first access point,
while the second access points is places on the y-axis. The distance between the
two is equal to the length of the localization rectangle, namely L. As such, if the
coordinates of AP1 , relative to the Cartesian plane are (0, 0), then AP2 would sit
on the (0, L) point.
The distance estimated by the equation (3.7) can be used to create a circle
around each access point. Assuming that the mobile device is at the (x, y) point
in the localization area (which means that 0 ≤ x ≤ l and 0 ≤ y ≤ L), the strength
of the signal received from the access points defines two circles as shown in Figure
3.3.
Therefore, the mobile device is placed at a position where the circles defined
by the two access points intersect. It results that the point (x, y) must satisfy
the equation of the circle for both access points.
The standard equation form for any point (a, b) which lies on a circle with
the radius r whose center’s coordinates are (rx , ry ) is:
(a − rx )2 + (b − ry )2 = r2 (3.8)
• y
AP2
•
AP2
AP1
•
x
AP1
•
x
Figure 3.1: Access Points Deploy-

ment
Figure 3.2: Access Points Broadcast
Range
As seen in Figure 3.3, the equation (3.8) can be particularized for the two
circles defined by the signal received from the two access points:
x2 + y 2 = r12 (3.9)
x2 + (y − L)2 = r22 (3.10)
Substracting equation (3.10) from (3.9), the value of the y coordinate is de-
termined:
r12 − r22 + L2
y= (3.11)
2L
Substituting y in equation (3.9) it follows that:

2
r12 − r22 + L2

2
x + = r12 (3.12)
2L
with two solutions:
p
2r12 r22 + 2r12 L2 + 2r22 L2 − r14 − r24 − L4
x=± (3.13)
2L
(0,L)
•
AP2
r2
(x, y)
•
r1
AP1
•
(0, 0) x
Figure 3.3: Lateration Technique
This result in equation (3.13) explains why the two access points had to be
positioned on the same axis. The negative solution is not a valid one as 0 ≤ x.
Therefore:
p
2r12 r22 + 2r12 L2 + 2r22 L2 − r14 − r24 − L4
x= (3.14)
2L
Another issue that has to be addressed is whether x is always a real number,

that is whether the term under the square root is positive or not. A necessary
and sufficient condition is that r1 , r2 and L are the side lengths of a triangle
because of the following identity:
2(r12 r22 + r12 L2 + r22 L2 ) − r14 − r24 − L4 =

(3.15)
(r1 + r2 + L)(r1 + r2 − L)(r1 − r2 + L)(r2 + L − r1 )
The identity (3.15) proves that if r1 , r2 and L are the side lengths of a triangle,
which means that r1 + r2 > L, r1 + L > r2 and r2 + L > r1 , then the expression
2(r12 r22 + r12 L2 + r22 L2 ) − r14 − r24 − L4 is positive. In Figure 3.3, it can be observed
that r1 , r2 and L form indeed a triangle.
Another condition for y to be positive (inside the localization area) is that
r12 + L2 ≥ r22 (3.16)
This translates into the fact that the angle between r1 and the y-axis needs
to be acute or right (lower than or equal to 90◦ ). Similarly, y ≤ L is equivalent
with:
r12 − r22 + L2
≤ L ⇔ r22 + L2 ≥ r12 (3.17)
2L
which means that the angle between r2 and the y-axis also need to be acute
or right. These assertions can be observed in Figure 3.4 and 3.5. For example, if
the angle between r1 and the y-axis is obtuse, then y is negative, and the point
(x, y) is outside the localization area as shown in Figure 3.4. The other invalid
case, r22 + L2 < r12 is presented in Figure 3.5.
y (x, y)
•
•
(0,L) AP2
y
(0,L)
•
AP2 AP1
•
(0, 0) x
AP1
•
(0, 0)• x
(x, y)
Figure 3.4: Invalid Case:r12 +L2 < r22 Figure 3.5: Invalid Case:r22 +L2 < r12
The equality cases r12 + L2 = r2 or r22 + L2 = r12 are reached when the triangle
is right angled. This means that either y = 0 or y = L and these cases correspond
to the situation where the target device lies on the border of the localization area.
The above conditions cover the cases when the calculated position is not
contained by the upper and lower sides and by the left side of the localization
area.
Another possible erroneous case is when x > l, shown in Figure 3.6.
•
(0,L) AP2
• (x, y)
AP1
•
(0, 0) x
Figure 3.6: Invalid Case: x > l
The condition imposed in this situation is that in the triangle formed by r1 , r2

and L the altitude corresponding to L should not be greater than l, that is:
hL ≤ l (3.18)
Considering the definition of the area
L · hL
A= (3.19)
2
and Heron’s formula
p
A= s(s − r1 )(s − r2 )(s − L) (3.20)
r1 + r2 + L
where s = is the semiperimeter, equation (3.18) can be rewritten
2
as:
p
2 s(s − r1 )(s − r2 )(s − L)
≤l (3.21)
L
Conditions (3.15), (3.16), (3.17) and (3.21) ensure that the determined posi-
tion will be contained in the localization area. As such, the position of the mobile
device has the following coordinates:
p
2r12 r22 + 2r12 L2 + 2r22 L2 − r14 − r24 − L4

x

=
2L (3.22)

y r12 − r22 + L2
=
2L
when r1 , r2 and L are the side lengths of an acute or right-angled triangle.

It can be said that the solution is a perfect solution, which means that the
system defined by the two circle equations has a unique solution. In case r1 , r2
and L are not the side lengths of a triangle, the system provides insufficient
information because the circles do not intersect at all, as one can observe in
Figure 3.7.
These situations are the result of incorrect measurements caused by the mobile
device or by many interference factors such as environmental changes, obstacles,
multipath reflection. In such cases, an approximation of the location can be
determined by finding the point for which the distance to the two circles is min-
imum. Another idea is to store the received signal strength values in the ”blind
spot” areas, similarly to the fingerprinting approach.
There are also cases when the circles intersect at incorrect positions. This is
caused by erroneous estimations of the distance between the target device and
the access point. In indoor localization systems, trilateration techniques based
on raw WiFi signals, generally have an error of a few meters.
(0,L)
•
AP2
AP1
•
(0, 0) x
Figure 3.7: Imperfect Solution
3.2 WiFi Trilateration based on RSS measurement collec-

tion
The positioning algorithm will find the coordinates of the mobile device based
on the received signal strength and the frequency of the signal captured by the
mobile device. Furthermore, in order to improve the accuracy of the localization,
the position will be estimated as an average of measurements stored in a queue
by the server.
The queue size is proportional with the accuracy of the positioning algorithm.
As the size increases, so does the precision of the localization. However, the size of
the queue is also directly proportional with the processing time of the information
by the server. Hence, a more accurate positioning will take a longer time and
will use more CPU time on the server. This could prove costly if there are more
client devices connected to the server which run the positioning algorithm at the
same time on different threads.
In order to improve the localization algorithm and to decrease the number of
the ”blind spots” described in the previous section, signal strengths levels of the
two access points deployed in the room have to be measured in positions where
the algorithm is not accurate enough.
Because of the environmental interference, the RSSI values fluctuate at dif-

ferent time stamps in the same physical position. Therefore, the application
measured the RSSI levels 10 times in each of the 10 distinct locations and the
average value was used.
In certain locations of the room such as behind a still object, or in a posi-
tion where another device which uses electromagnetic waves was operating, the
RSSI levels are inaccurate. Therefore, the RSSI values in these positions were
calculated and stored by the server application.
The algorithm will then check all the stored values and in case of a match,
the associated real position will be used further in the algorithm. This step is
similar to the fingerprinting approach, however it uses less overhead as it stores
only positions for which imperfect measurements are frequent.
3.3 Hardware Implementation
The main hardware components of the localization system are the ESP8266-
01, a WiFi module used to design an access point, the Raspberry PI 3, which
plays the role of the server and a Samsung Galaxy S4 Mini device to run the
client application.
This section describes the hardware configuration of these elements.
3.3.1 ESP8266-01
ESP8266 [7] is a high integration wireless SoC which has been designed for
mobile and Internet of Things applications. It can host the application by itself
or the Wireless networking functions can be offloaded from another application
processor. In such applications, in order to boost the system’s performance a
cache memory was integrated. Using the module as a WiFi adapter, any mi-
crocontroller based design with connectivity interfaces (such as UART/I2C or
SDIO/SPI) can obtain wireless internet access.
WiFi location-aware devices, WiFi position system beacons and security ID
tags are important domains of ESP8266 Internet of Things applications.
ESP8266 is one of the most integrated WiFi chip in the SoC’s industry. It
requires minimal external circuitry and it integrates the power management mod-
ules, low noise receive amplifier, power amplifier, RF balun, antenna switches.
The entire structure, along with the front-end module, is devised for the purpose
of occupying a minimal PCB area.
Apart from the wireless functionalities, an enhanced version of Tensilicas L106

Diamond series 32-bit processor is integrated, with on-chip static RAM memory.
ESP8266 is usually embedded with devices specific to other applications through
its GPIO pins.
The main features of the ESP8266 module are summarised below:
• Supports the 802.11 b/g/n WiFi protocols
• Low power 32-bit microcontroller unit
• 10-bit analog digital converter
• Self-contained TCP/IP protocol stack
• In 802.11b the maximum output power is +19.5dBm
• It can operate with a diversity of antennas
• WiFi 2.4 GHz which supports two security protocols WPA/WPA2
• Integrated smart link function for iOS and Android-based devices.
• It can wake up and send packets in less than 2 milliseconds
• The temperature range is -40C ∼ 125C
• It can operate as a station (STA), access point (AP) or both (STA + AP)
ESP8266-01 has only 8 pins and is the smallest module in the ESP8266 family.
The ESP8266-01 pin configuration can be seen in Figure 3.8 [6].
Figure 3.8: ESP8266 Pin Configuration

The RST (reset), VCC, GND and CH PD (chip select) are pins needed for the
operation of the module, while the other four pins can be used as I/O pins,
although they also have specific functions. The RX/TX pins are used for the serial
I/O communication and to program the chip, while the GPIO0 and GPIO2 set the
mode in which the module powers in. Each pins role can be seen in Table 3.3.
Pin Name Function Details

VCC Power Powers up the chip 3.3V
GND Ground
Resets the module when
RST Reset 5V compliant
pulled to ground
CH PD Chip Select Enables the module 3.3V
Serial input
RX Receive 5V compliant
into the module
Serial output
TX Transmit 3.3V
from the module
General Purpose Used to establish when
GPIO0 3.3V logic,
Input/Output 0 to boot into the bootloader
maximum 12mA
General Purpose
GPIO2 Detects boot-mode
Input/Output 2
Table 3.3: ESP8266-01 Pins
3.3.2 Raspberry PI 3
The Raspberry PI 3 is the latest generation model of Raspberry Pi, a mini-PC

with a powerful CPU and wireless functionality. It is low cost, high capability
computing board with a great level of performance, connectivity and power man-
agement.
It uses a new ARM Cortex A53 CPU which is a quad-core 64-bit chip that
operates at 1.2GHz. Compared with the other boards of the Raspberry family it
has a better performance and new capabilities and it’s the first board which does
not use a 32-bit chip.
The model deployed as server in the localization system is the Raspberry PI
3 Model B, whose main features are shown in Figure 3.9 [15].
The main addition of the Raspberry PI 3 is the WiFi integration. The
802.11b/g/n protocols are supported by the WiFi chip, providing access to WLAN
networks and ensuring autonomy from the wired connections.
Figure 3.9: Raspberry PI 3 Model B
Apart from the WiFi capabilities, Raspberry PI 3 has adopted Bluetooth

4.1 as standard. Bluetooth 4.1 provides smart connectivity, an improved data
transfer and ensures coexistence with 4G.
The Raspberry PI 3 Model B uses a 5V micro USB power supply. The current
required by the Raspberry PI is dependent on the devices connected to it. Usually,
the Model B requires around 700-1000 mA and, but the current necessity may
increase as other devices connect to the various interfaces of the Raspberry PI 3.
The Raspberry PI 3 has no on-board storage, but it has a Micro SD card
slot. The system will use a 32GB micro SD card which has been flashed with the
Raspbian operating system.
Raspbian is the official operating system supported by Raspberry PI, recom-
mended for normal use on a Raspberry board. It is a free Debian-based operating
system, enhanced for the hardware of Raspberry PI. Raspbian is specifically de-
signed for Raspberry PI, having over 35000 compiled software packages. Several
programming tools and software such as Scratch, Sonic PI, BlueJ, Mathematica
are installed by default in the Raspbian operating system.
The APT (Advanced Package Tool) is a free software that manages the in-
stallation, upgrade and removal of software packages. It is a piece of software
that comes from the Debian OS.
The raspi-config application is a configuration tool which targets the Rasp-
bian operating system. This tool has several options available as described in
Table 3.4.
Option Function
The OS can use all
Expand File System
the card storage space
Password reset
Change User Password
option
Enable Boot to Boot into Scratch, Command
Desktop/Scratch line or Desktop
Regional and
Internationalisation Options
language settings
Sets up Raspberry
Enable camera
PI camera
Add to online map
Add to Rastrack
(Rastrack)
Overclock CPU
Overclock
up to 1000 MHz
Overscan, Hostname,
Memory Split, SSH,
Advanced Options
Device Tree, SPI,
Serial, Audio
About ’raspi-config’ Tool Help
Table 3.4: raspi-config Options
The file config.txt is a configuration file that stores parameters which would
be found in BIOS on a conventional PC. Several low level parameters of the
Raspberry PI 3 subsystems can be modified through this file such as memory
parameters, network parameters, boot and overclocking options.
In the present localization system, the operating system used is the Raspbian
Jessie, released in May 2016 and with the 4.4 kernel version. The operating
system was installed using the NOOBS package, an easy to use OS installer for
the Raspberry PI, which incorporates Raspbian.
3.3.3 Android-based smartphone
The client device on which this system was tested is a Samsung Galaxy S4
Mini GT-I9195 smartphone running the 4.2.2 JellyBean version of the Android
operating system. The main technical specifications of the device can be seen in
Table 3.5.
The smartphone runs the client application which was developed using the
Android Studio IDE. The application can be run successfully on any Android-
based smartphone which has wireless capabilities and runs any version of Android
OS 4.2.2 or higher.
Technical Specifications
Battery 1,900 mAh
124.6 x 61.3 x 8.94mm,
Size
107g
Android OS
Operating System
JellyBean 4.2.2
Memory 8GB memory
Wi-FI 802.11a/b/g/n, GPS,
Connectivity
Bluetooth 4.0, NFC
CPU Clock 1728 MHz
RAM Capacity 1.5GB (1.3GB accessible)
Display resolution 540 x 960
Table 3.5: Samsung Galaxy S4 Mini Technical Specifications
For a successful positioning the device needs to be inside the localization

area with the wireless functions enabled. These are necessary for measuring the
received signal strength from the access points and for connecting to the server
which runs the positioning algorithm.
3.4 Software Implementation
As mentioned in this chapter’s introduction, the present localization system

targets Android-based mobile devices and it is comprised of a client application
running on the Android OS, a server program, which is written in Java program-
ming language and uses a MySQL database and two access points.
In the present system, the access points were designed specifically for testing
purposes and were implemented based on the ESP8266-01 WiFi module presented
in a previous section and the Arduino board, but the system can use any wireless
device configured as an access point.
The client application is highly configurable and it can be configured to work
with any access point deployed in the specified locations as in Figure 3.1. Also
the server program can run on any wireless enabled device which is configured as
an access point.
The Android application contains an activity for the configuration of local-
ization system named Settings. In this view, the user can set the IP address of
the server and the password, specify the encryption protocol used by the server
and indicate the SSIDs of the access points used in the positioning algorithm.
The user can also add new maps which will be stored by the server and select
any of the maps available on the server. Each map needs to be configured by
indicating the height and width of the real room in meters and by using a unique
suggestive name for the map.
The server program runs on a Raspberry PI 3 model B, presented above. Its
main purpose is to use the frequency and RSSI measurements received from the
client application in the positioning algorithm. Based on the input data, the
algorithm calculates the current location of the mobile device. The data is then
sent to the Android application.
The server also stores maps uploaded by the users in a local MySQL database.
The client application can see all the available maps, and the user can select any
desired map.
The client-server communication was done using the KryoNet API. KryoNet
represents a Java library used for implementing the client-server model over a
network using TCP and UDP packets for communication.
The system’s architecture is shown in Figure 3.10.
Figure 3.10: System Architecture
3.4.1 The Client
The target mobile device runs an Android application which is comprised of

two main meta-components:
• A sniffing service - the component which collects information from the access
point
• User interface activities - several activities which display access points mea-
surements, the current location of the device, configuration and available
maps information
Each of the above components communicate with the server through the Kry-
oNet API and between each other.
The sniffing service uses the WifiManager, a primary class which manages the
WiFi connectivity in Android OS, in order to collect all positioning information
from the access points. This data is used to display access points measurements
to the user in real time and it is also sent to the server in order to calculate the
current position.
The UI activities use controls of the Android framework to display the cur-
rently selected map, the position on the map in real time, access points data,
configuration settings in a user-friendly interface.
Each class, activity and service contains a private static final string named
TAG which is initialized with the name of the class. This field was used during
development to write log statements.
The sniffing service
This component is comprised of the WifiScanning class which extends the

Service class and overrides its main methods.
The Service class is a component of the Android framework used for oper-
ations which take a long period of time. Service does not implement a user
interface, running in the background.
A Service can be used in two forms: started or bound. A started Service is
initiated when the startService() method is called by an application compo-
nent and it can run in the background for an indefinite period of time. A bound
Service is initiated by calling the bindService() method. This method is raised
by an application component which wants to interact with the service. Several
components can bind to the service, and the service is destroyed when no other
component is bound to it anymore.
The WifiScanning class is called from the main thread using the startService()
method. As such, the WifiScanning class was implemented following the life cycle
of a started Service which is described in Figure 3.11.
Call to
startService()
onCreate()
onStartCommand()
Service
running
onDestroy()
Service
shutdown
Figure 3.11: Started Service Life Cycle
In the onCreate() method, WifiScanning initializes several of its fields. It

creates a instance of the LocalBroadcastManager class, which will be used to send
data to user interface components when the service scans the networks available.
The WifiManager is initialized using the getSystemService() method. This
method requires a parameter to specify which system service has to be retrieved.
For the WifiManager, the method is called as seen in 3.1 with an explicit cast to
the WifiManager class.
Listing 3.1: getSystemService() call

( WifiManager ) getSystemService ( Context . WIFI_SERVICE ) ;
An instance of Timer class is also created. This instance is used for scheduling
a TimerTask to be executed in a background thread at a regular interval of time.
The TimerTask class runs an update task in a separate thread which uses the
WifiManager instance to request a scan of the available access points with the
startScan() method.
The Timer instance plans the update task to be run at a periodic interval
of time with the schedule() method. This method receives as parameters the
TimerTask object, a delay (set to zero) and the refresh rate in milliseconds.
During the testing of the localization system, the refresh rate was set to
10000, meaning the client application scans the access points every 10 seconds.
This interval ensured a satisfying usage of the smartphone’s battery as well as
updating the UI in a user appeasing time interval.
The WifiScanning class also has a private nested class named WifiReceiver
which extends the BroadcastReceiver class.
BroadcastReceiver is a class which responds to broadcast messages sent by the
system or by other application components. Once a broadcast message arrives,
the onReceive() method is executed.
The WifiReceiver is instantiated during the service’s onCreate() method.
After the object is created, the WifiReceiver also needs to be registered in order
to listen to specific intents.
For receiving data, a IntentFilter was created to filter only for broadcast
messages from the WifiManager which announce that the scan results requested
by the WifiManager.startScan() are available. This is done by specifying the
constant WifiManager.SCAN RESULTS AVAILABLE ACTION as parameter in Intent-
Filter’s constructor.
The last step in the onCreate() method is to register the WifiReceiver. This
is achieved by calling the registerReceiver() method with the WifiReceiver
instance and the IntentFilter object as parameters.
After the onCreate() method is completed, the TimerTask scans the ac-
cess points periodically at every 10 seconds. When the scan is completed, the
system sends a broadcast message which is caught by the WifiReceiver. In the
onReceive() method, the data is collected and then filtered for the access points
required by the positioning system.
The WifiManager.getScanResults() returns an ArrayList of ScanResult ob-
jects for each of the available access points.
The ScanResult class contains information about an access point discovered
by the WifiManager. The main fields of class and the data stored in them are
detailed in Table 3.6.
Since in the application, not all the available fields of ScanResult class will be
required, a separate class named WifiMeasurement was implemented. This class
contains the SSID, BSSID, frequency, level and timestamp fields.
The ArrayList of ScanResults is then looped through and, by checking the
SSIDs, only the configured access points are selected. For each of them, a new
Field Details Data Type

Last seen time
timestamp long
in microseconds
The RSS indicator
level int
in dBm
The channel
frequency int
frequency in MHz
Access point
channelWidth int
channel bandwidth
Access point authentication,
capabilities String
encryption and key management
The name of
SSID String
the network
Access point
BSSID String
MAC Address
Table 3.6: Fields for the ScanResult class
WifiMeasurement is selected and added to a new ArrayList. In the same loop,

a packet message is created which contains the frequency and level of the two
access points.
Using an asynchronous task which runs on a separate thread, the packet
message is sent to the server and the client application waits for a reply. The
server runs the positioning algorithm and sends back a response packet which
contains the calculated coordinates of the mobile device.
If the response from the server is not null, meaning the position is a valid
one, the coordinates are sent by the WifiScanning service to the MapActiv-
ity which displays the location on the map view. This is achieved by calling
the sendBroadcast() method of the LocalBroadcastManager object instanti-
ated earlier. The sendBroadcast() method requires an Intent with the action
POSITION DATA and the coordinates added as extra data using the putExtra()
function.
Also, using the same method, another broadcast message containing the Ar-
rayList of WifiMeasurement objects is sent to the WifiActivity method to display
the available information for the access points of interest.
When the WifiScanning service is destroyed, the onDestroy() method is
called. In order to handle the life cycle correctly, in this function the WifiReceiver
instance is unregistered by calling the unregisterReceiver() method. More-
over, the TimerTask execution is terminated by invoking the Timer’s cancel()
method and the task is further removed from the Timer’s task queue by using
Timer.purge().
The WifiScanning service fulfills the main task of fetching information about
the access points, processing it and then forwarding the data to the application
components which require this information at a periodical interval of time.
User Interface Components
The user interface is comprised of several activities:
• MainActivity - launcher activity where the application starts
• WiFiActivity - describes the access points information in real time
• MapActivity - component which displays the map and the current location
on the map
• AddMapActivity - activity for uploading a new map on the server
• SettingsActivity - configuration preferences
• SelectMapActivity - displays all maps available on the server and the user
can select the current map in this activity
When the user starts the application, MainActivity is launched and from this
activity the user can access the other components of the application as seen in
Figure 3.12.
In the onCreate(), apart from configuring the interface controls, the applica-
tion sends a ping message to the server to check that the server is available and
within range for a wireless connection. If the ping is successful, the application
tries to establish a connection to the access point’s network configured on the
server.
This is achieved again using an instance of WifiManager which is created as
shown in Listing 3.1. The next step is to create a WifiConfiguration object and
to set the SSID and the preshared key because the server is using the WPA-PSK
encryption protocol.
Once the configuration is created, the network needs to be added to the
set of configured networks. This is accomplished by invoking the WifiMan-
ager.addNetwork() method which returns an ID of the newly created network.
The last step is to effectively connect to this new network as shown in Listing 3.2
(serverWifiManager is the WifiManager object).
Figure 3.12: Interface for the MainActivity
Listing 3.2: WiFi Connection

serverWifiManager . disconnect ( ) ;
serverWifiManager . enableNetwork ( ID , true ) ;
serverWifiManager . reconnect ( ) ;
The mobile device is now connected to the network of the server. Another
information the client sends to the server is the ID of the current map. The server
uses this ID to acquire map information (access points location, map dimensions)
from the database. This is called the initialization step: the server now only needs
access point Wifi measurements in real-time to run the positioning algorithm.
The WifiActivity displays real-time measurements of the two access points
using a ListView and a custom adapter named ScannedNetworksAdapter. Using
a local BroadcastReceiver, the activity catches AP scan results. The Scanned-
NetworksAdapter displays the information as shown in Figure 3.13.
Figure 3.13: Interface for the WifiActivity
The most important activity of the application is the MapActivity. This

activity uses a custom made control named MapView in order to display the
current selected map and the current position.
The Position class contains data about a location (the coordinates, whether
it is an access point or not). The PositionMarker class implements displays the
point at the Position coordinates and the CurrentPositionCircle class draws a
circle around the current marker.
The current position is displayed in red, while the positions of the access
points (as deployed in Figure 3.1) are drawn in blue.
The MapView class extends the FrameLayout class. Its constructor invokes
a protected method named initView() which creates an ImageView control to
display the map on and a child FrameLayout which acts as a content View for
the PositionMarker and CurrentPositionCircle.
In the onCreate() method of the MapActivity, the PositionMarker and Cur-
rentPositionCircle (in blue) for the two access point are drawn. Also, a Broad-
castReceiver is instantiated in order to catch the POSITION DATA messages from
the WifiScanning service.
Each time data is received from the WifiScanning service, the coordinates are
scaled for the mapView object as shown in Listing 3.3.
Listing 3.3: Scaling coordinates

mapX = ( serverX ∗ mapView . getMeasuredWidth ( ) / RealWidth ) ;
mapY = ( serverY ∗ mapView . getMeasuredHeight ( ) / RealHeight ) ;
Using mapX and mapY, a new Position object is created. Then, the method
MapView.showPosition() is invoked. This function adds a new PositionMarker
for the new Position and removes from the container all previous markers, ex-
cepting the access points as seen in Listing 3.4.
Listing 3.4: Adding a new PositionMarker

PositionMarker marker = new PositionMarker ( getContext ( ) ,
position , contentFrame ) ;
for ( PositionMarker m : positionMarkers . values ( ) ) {
if ( ! m . getPosition ( ) . isAP ( ) )
m . removeFromContentFrame ( ) ;
}
positionMarkers . put ( position , marker ) ;
contentFrame . addView ( marker ) ;
The PositionMarker objects are stored in a HashMap<Position, Position-

Marker> collection and the function FrameLayout.addView() adds the new Po-
sitionMarker to the MapView.
The removeFromContentFrame() method calls the FrameLayout.removeView()
function in order to remove the CurrentPositionCircle from the FrameLayout.
The contructor of the PositionMarker class draws the marker for the position
and if the position is not an access point the function setisCurrentPosition()
is called. This method creates a new CurrentPositionCircle and this new object is
added to the contentFrame using the FrameLayout.addView() method as above.
The CurrentPositionCircle class extends the View class. In its constructor,
it acquires the density of the metrics using the getDisplayMetrics() method
which contains a density field. The stroke width for the circle is calculated as
the double of the density, and the radius is also scaled with respect to the density.
Two Paint objects are created: filledPaint for drawing the circle and
strokePaint for drawing the borders. The configuration of a Paint object can
be seen in Listing 3.5.
Listing 3.5: Paint Object Configuration

linePaint = new Paint ( ) ;
linePaint . setAntiAlias ( true ) ;
linePaint . setColor ( Color . RED ) ;
linePaint . setStyle ( Style . STROKE ) ;
linePaint . setStrokeWidth ( widthStroke ) ;
The getLayoutParams() method sets the margins for the CurrentPosition-

Circle object and in the onDraw() method the circle is drawn using a Canvas
instance and invoking the Canvas.drawCircle() method.
If the user wants to add a new map on the server, the AddMapActivity
requires the user to select the image from the Gallery, to add the name of the
map and the real dimensions in meters as shown in Figure 3.14. All this data is
then sent to the server using an UploadMap packet message.
Figure 3.14: Interface for the AddMapActivity

From SettingsActivity the user can edit server connection information such
as:
• IP of the server
• TCP and UDP ports used for communication
• Server network password
• Access points SSID
The SelectMapActivity allows the user to select which map to display in the
MapActivity. It sends a DownloadMap packet message to the server and the
server responds with a list of all available maps in the database.
All the maps are displayed using a ListView control and when the user selects
an item, the application sends another DownloadMap packet message with the
ID of the map. This time, the server responds with the information configured
for the map.
3.4.2 The Access Points
The access points have been implemented by connecting an ESP8266 module

with an Arduino board and using the Arduino software to configure the access
point functionality.
The ESP8266 requires a 3.3V input through its VCC pin. This voltage can
be obtained from the Arduino 3.3V output pin. However, although the ESP8266
can draw around 250 mA and can require up to 230 mA when using the wireless
interface, the 3.3V output pin from Arduino can provide only maximum 50 mA.
A voltage of 3.3V with the required current can be drawn from the Arduino
5V output pin using two 1N4007 rectifier diodes and a capacitor as shown in
Figure 3.15.
The two ESP8266 working as access points have been configured using AT
commands, also known as Hayes commands. The AT Command set is a standard
command language which offers a series of functions and operations for changing
the connection parameters of the ESP8266 module.
A serial communication has to be established in order to send the AT com-
mands to the ESP8266 through the Arduino. The serial communication between
the ESP8266 module and the Arduino board is done through the Arduino built-in
UART interface on pins 0 and 1.
Figure 3.15: Access point scheme
In order to realize a serial communication on other digital pins of Arduino

Board, the Software Library needs to be included. In Figure 3.15 the RX and
TX pins of the ESP8266 chip are connected to the digital pins 2 and 3.
An example of setting up a serial communication is presented in Listing 3.6.
Listing 3.6: Serial Communication Arduino

#include <SoftwareSerial . h>
% RX − d i g i t a l p i n 2 ( c o n n e c t with TX o f t h e o t h e r d e v i c e )
% TX − d i g i t a l p i n 3 ( c o n n e c t with RX o f t h e o t h e r d e v i c e )
SoftwareSerial serialESP8266 ( 2 , 3 ) ;
void setup ( )
{
Serial . begin ( 9 6 0 0 ) ;
serialESP8266 . begin ( 9 6 0 0 ) ;
}
Through the established serial communication, AT commands are sent as a

series of strings adding the new line and carriage return characters at the end of
the string.
The command 3.7 can be used to see the module firmware version:
Listing 3.7: AT Command for Firmware Version

AT+GMR
which has the following output result:
AT version : 0 . 4 0 . 0 . 0 ( Aug 8 2015 1 4 : 4 5 : 5 8 )

SDK version : 1 . 3 . 0
Ai−Thinker Technology Co . , Ltd .
Build : 1 . 3 . 0 . 2 Sep 11 2015 1 1 : 4 8 : 0 4
The module ESP8266 has three different operating modes:
• Station - the module acts as a client and can connect to an access point;
• Access point - other clients can connect to the module, including another
ESP8266 module which operates as a station;
• Station and access point - the module operates in both modes simultane-
ously.
To set the operating mode of the ESP8266, the command in Listing 3.8 can
be used:
Listing 3.8: Wifi Mode AT Command

AT+CWMODE=<cwmode>
The value <cwmode>corresponds to the operating mode as described in Table

3.7.
Operating Mode Acronym Value

Station STA 1
Access Point AP 2
Station & Access Point STA + AP 3
Table 3.7: ESP8266 Operating Modes
In order to establish how fast the serial data is transmitted, the baud rate
has to be set as shown in Listing 3.9.
Listing 3.9: Data Transmission Speed AT Command

AT+CIOBAUD =9600
and for the changes to take effect, the following command resets the ESP8266
module.
Listing 3.10: Reset AT Command

AT+RST
The setup of the ESP8266 as an access point is done by the command in

Listing 3.11.
Listing 3.11: AT Command for AP Parameters Configuration

AT+CWSAP=<SSID>,<password >,<channel >,<encryption mode>
SSID represents the name of the network that the client will see when connect-
ing to the network. The password is used to guarantee the security of the network
according to the encryption mode. If the encryption mode is set as Open, then
any user can connect to the network without providing a correct password. The
third parameter specifies what network channel is used by the ESP8266 module.
The encryption parameter sets the security mode as described in Table 3.8.
Security mode Value

OPEN 0
WEP 1
WPA-PSK 2
WPA2-PSK 3
WPA/WPA2-PSK 4
Table 3.8: ESP8266 Security Modes
Out of these security modes, the safest and the most commonly used is the
WPA2-PSK protocol.
The IP address of the access point is set as in command 3.12.
Listing 3.12: AT command for IP Address Configuration

AT+CIPAP=" 192.168.0.1 "
and the setup of the MAC address is the last configuration step:
Listing 3.13: AT Command for MAC Address Configuration

AT+CIPAPMAC="12:3a:9b:ff :56:0 a"
3.4.3 The Server
The Raspberry PI was configured as an access point on the interface wlan0.

This way, any client application can connect to the server program and run the
positioning algorithm.
Using the KryoNet library, the client sends to the server a LocalizationRequest
packet which contains the frequency and the received signal strength indicator of
the two available access points. The server uses this information to calculate the
current position and sends a LocalizationResponse back to the client.
The Server as Access Point
As the Raspberry PI 3 has on-board WiFi, configuring it as an access point

requires no additional hardware and only a few software packages. The two
required packages are hostapd and dnsmasq. hostapd allows the built-in WiFi
to be host an access point and dsnmasq is a package that offers DHCP and DNS
services.
The first step is to assign a static IP to the wlan0 interface. In the Raspbian
Jessie OS, the dhcpd program handles the interfaces for dynamic assignment of
IP address. Since the wlan0 will have a static IP address, at the end of the
dhcpd.conf file, the line 3.14 was added.
Listing 3.14: Deny DHCP for wlan0

denyinterfaces wlan0
The /etc/network/interfaces was edited to include the static configuration

of wlan0 as shown in Listing 3.15.
Listing 3.15: wlan0 Static Configuration

allow−hotplug wlan0
iface wlan0 inet static
address 1 9 2 . 1 6 8 . 3 5 . 1
netmask 2 5 5 . 2 5 5 . 2 5 5 . 0
network 1 9 2 . 1 6 8 . 3 5 . 0
broadcast 1 9 2 . 1 6 8 . 3 5 . 2 5 5
The next step is to configure the hostapd service. For this purpose, the
configuration file /etc/hostapd/hostapd.conf was created.
Listing 3.16: The hostapd.conf File

interface = wlan0
ssid = PI_AP3
ignore_broadcast_ssid = 0
channel = 1
driver = nl80211
macaddr_acl = 0
hw_mode = g
auth_algs = 1
wpa = 2
wpa_passphrase = myPassword
wpa_key_mgmt = WPA−PSK
rsn_pairwise = CCMP
wmm_enabled = 1
The options in the hostapd.conf configure the main parameters of the access
point. The option ignore broadcast ssid = 0 is used to allow only users which
know the network name to connect. macaddr acl = 0 specifies that there is no
filtering after the MAC address. The hw mode = g option indicates that the
access point uses a 2.4GHz band.
The next four lines, specify that the encryption protocol used by the network is
WPA2 with a preshared key. rsn pairwise = CCMP indicate that the Advanced
Encryption Standard (AES) should be used, while wmm enabled = 1 indicates the
use of Wi-Fi Multimedia (WMM) to register data packets in order to enhance
the quality of service over the network.
In order for hostapd service to use this configuration file, the line 3.17 was
added in the default file /etc/default/hostapd.
Listing 3.17: Configuration of Path towards hostapd.conf Gile

DAEMON_CONF = "/etc/ hostapd / hostapd .conf"
The above configurations are enough to start the access point, but in order
to connect to it and receive an IP address, the dnsmasq service needs to be
configured. To that end, the /etc/dnsmasq.conf config file was edited as shown
in 3.18.
Listing 3.18: The dnsmasq.conf File

interface = wlan0
bind−interfaces
listen−address = 1 9 2 . 1 6 8 . 3 5 . 1
server = 8 . 8 . 8 . 8
dhcp−range = 1 9 2 . 1 6 8 . 3 5 . 5 0 , 1 9 2 . 1 6 8 . 1 . 2 0 0 , 6h
The first line specifies that the wlan0 is the interface used by the access point
and bind-interfaces attaches the interface to ensure that the packets are sent
on the wlan0 interface.
The listen-address setting indicates explicitly the IP address to listen on.
The last line from the /etc/dnsmasq.conf sets the range of assignable IP ad-
dresses between 192.168.35.50 and 192.168.35.200 with a lease time of 6h for each
IP address.
To complete the configuration of the server as an access point, one more step
was required: to enable packet forwarding. In order to acquire IPv4 forwarding,
in the /etc/sysctl.conf, the following line was added:
Listing 3.19: Configuration for IPv4 Forwarding

net . ipv4 . ip_forward = 1
which will enable ip forwarding on reboot. If the Raspberry PI has an inter-

net connection on the Ethernet link, NAT has to be configured from the eth0
interface to the wlan0 interface in order to share the internet connection over
WiFi. However, the localization server will not require connection to the internet
as it only communicates with the clients devices.
The server is now configured as an access point, and it only needs to start the
dnsmasq as shown in 3.20.
Listing 3.20: Start dnsmasq Command

sudo service dnsmasq start
and hostapd service as in Listing 3.21.
Listing 3.21: Start hostapd Command

sudo service hostapd start
After these commands the server works as an access point and the client
application can connect to the server.
The Server Program
The server runs a Java Application which uses the KryoNet library to com-
municate with the client applications. Also, the server uses a MySQL database
to store the available maps and to log any connection and any information sent
between the client and the server.
MySQL is installed on the server as follows:
Listing 3.22: MySQL Install Command

sudo apt−get install mysql−server mysql−client
The setup of the server using KryoNet is described in the Client-Server Model
section and the packet classes used to send response and request message between
the client and the server are described in Table 3.10.
In order to connect to the database, the JDBC:MySQL driver was used. This
driver comes in a Connector/J package which has to be added as an external
library to the server application. The Connector/J package used on Raspberry
PI was mysql-connector-java-5.1.6-bin.jar.
The connection to the MySQL database in the application is created using the
DriverManager.getConnection() function. This method requires three parame-
ters: the user, the password and the URL (which is ”jdbc:mysql://localhost:3306”
since the database is on the same host as the server application and 3306 is the
designated port to communicate data).
The server also uses a DbHelper class to facilitate the access to the MySQL
database. This class defines several functions to ease INSERT and SELECT opera-
tions with the database. All these methods are described in Table 3.9.
Apart from querying the database for logging information and map data, the
server implements the positioning algorithm. The input required by the algorithm
consists of the level and frequency fields for the two configured access points
and the output it produces are the two coordinates of the mobile device. Also,
the length L of the real localization area is required and this is acquired from
the database, after the client sends the Initialization packet with the currently
selected map ID.
The first step in the algorithm is evaluating the radius of the two circles
using the formula in 3.7. For this purpose, a new method getDistance() was
implemented which receives the frequency and level of one access point and
returns the radius of the circle as a double.
The next step is checking the validity of these radii. For this sake, a separate
method validityCheck() was created. This function requires the two radii r1
and r2 as input parameters and returns a boolean.
Method Details
Saves the client IP
logPing() and current time
in the Pings table
Saves the client IP
logInitialization() and the map ID
it currently uses
Saves the measurements
logLocalizationRequest()
received from a client device
Saves the positioning
logLocalizationResponse()
algorithm output
If the client uploads a
insertMap() map to the server,
it is saved in the database
If the client selects a new map,
selectMap() the server acquires the blob
of the map from the database
Selects the names of all
getAllMaps()
maps available in the database
Table 3.9: DbHelper Methods
The validityCheck() method verifies the conditions imposed in (3.15), (3.16),

(3.17) and (3.21), that is r1 , r2 and L have to be the side lengths of a triangle and,
moreover, that triangle has to be acute-angled where r1 and r2 intersect with the
y-axis. The return value is true if all the conditions are satisfied, or false when
one of them is false.
If the computed radii pass the validityCheck() method, the coordinates of
the current position are assessed using the formula in (3.22) and then those values
are stored in two double variables.
In order to achieve a more precise evaluation of the current position, consec-
utive measurements are stored in local queue and the position sent to the client
application is the average of all the values stored in the queue.
During testing, the size of the queue was set to 10. In the beginning, the
position are stored in the queue and the client received the average position.
Once the size limit is reach (there are 10 positions in the queue), the least recent
position is removed from the queue and the new one is added.
Once the average position is evaluated, the data is used to create a new Lo-
calizationResponse object, which is sent to the client application to be displayed
in the MapView control.
3.4.4 The Client-Server Model
Communication between client and server was handled using the KryoNet
API. This API is comprised of Kryo, the serialization framework, and a series of
functions designed for transferring serialized objects across the network.
In order to run a server, an instance of the Server class has to be created and
the method start() creates a new thread which handles any connection request
from a client and notifies the listeners.
The Server constructor can customize the buffer sizes, an object buffer and
a write buffer. When the server, receives an object, the bytes are queued in the
object buffer until the transfer is complete and after that the deserialization of
the object begins. The write buffer is used to serialize objects that are send over
the network.
Because of that, the size of the two buffers need to be greater than the largest
incoming and outgoing objects. In the localization system, the server was instan-
tiated as shown in Listing 3.23.
Listing 3.23: Server Instantiation

Server server = new Server ( 2 6 2 1 4 4 , 2 6 2 1 4 4 ) ;
as the map sent over the network can have a significant size in bytes. The
same principles are applied for the client component.
Before any network communication occurs, a necessary step is registering
the classes of the objects sent over the network. This step has to be done on
both the client and the server and it is mandatory that the same classes are
registered on both sides and in the same order. As such, a separate method
named registerPackets() was created for both the client and the server.
One class is registered creating a Kryo object by calling Server.getKryo() and
then invoking the Kryo.register() method. The register() method receives
as parameter the class to register and this registration step needs to be done for
all classes used in sending data between client and server.
The classes in Table 3.10 were registered in registerPackets().
For the sake of handling incoming packets, a Listener has to be implemented.
The Listener can then be instantiated and added to server using the method
Server.addListener(). The Listener class has the following important methods
which can be overriden:
• connected() - this method is invoked when the connection between client

and server is established
Packet Class Usage

Checks the connectivity
Ping
with the server
Informs the server which
Initialization
map is currently used
The client sends the
LocalizationRequest input data for the
positioning algorithm
The server sends the
LocalizationResponse output of the
positioning algorithm
The client requests a map
DownloadMap or information about all
maps in the database
The client sends a new
UploadMap
map to the server
The server sends all available
MapDatabase
maps to the client
Table 3.10: Packet Classes
• received() - this function is called whenever a packet object is received
• disconnected() - called when the connection is terminated.
The received() handles the capture of objects send over the network by
clients. This method usually contains checks over the received object using the
instanceof keyword. Once the type of packet is determined, the server casts
the object to the corresponding class and saves a log in the database.
Depending on the type of packet, the server may respond to client or just
save the data in the database. For example, if the server receives an UploadMap
packet, he saves the map in the database and does not send a response back. If
the server receives a LocalizationRequest packet, after the positioning algorithm
it will respond with a LocalizationResponse packet. Figure 3.16 emphasises all
the packets sent between server and client.
Both the client and the server send data across the network using the sendTCP()
method. The last step in configuring the server is to bind the TCP and UDP
port. This is accomplished by invoking the Server.bind(tcpPort, udpPort).
A Client is set up in a similar manner. The main difference is that instead of
binding the TCP and UDP ports, the client will connect to the server over the
same ports by invoking the connect() method as shown in Listing 3.24.
Client Server
Ping
Ping
Initialization
UploadMap
DownloadMap[All]
MapDatabase
DownloadMap[Map]
UploadMap
LocalizationRequest
LocalizationResponse
Figure 3.16: Client - Server Communication
Listing 3.24: Client Connection

client . connect ( timeout , serverIP , tcpPort , udpPort ) ;
The timeout parameter specifies the amount of time in milliseconds after

which the client will stop trying to connect to the server if not successful.
Chapter 4
Case study
The presented localization system was deployed in a 5m x 3m room (5m in

length and 3m in width). The middle of the room has an unobstructed line of
sight with the two access points, but there are several obstacles to be considered
as seen in Figure 4.1.
Figure 4.1: Localization Room
47
CHAPTER 4. CASE STUDY 48
Firstly, there is a bunk bed between the two access points which distorts
the received signal strength of the access point which sits on the opposite of
the client device with respect to the bed. There are also two partial false walls
which separate the upper part of the room from the rest and several other objects
standing near the edge of the room.
Although any device which was using electromagnetic waves in the room was
disabled during the testing of the localization system, there were other devices
such as wireless routers and other mobile devices which were operating in nearby
rooms and could not be disabled due to obvious reasons.
4.1 Results based only on raw RSS values
Initially, the localization system was tested storing only perfect solutions in
server queue. Imperfect measurements that do not pass the validityCheck()
function are discarded. If any of the conditions in (3.15), (3.16), (3.17) or (3.21)
are not true, then coordinates are not assessed for the respective set of r1 and r2 .
The results are presented in Table 4.1 and Figure 4.2. The green nodes are
the real positions, while the red nodes are the measurements provided by the
localization algorithm.
Real Measured
position coordinates
(1, 1) (2.28, 0.86)
(0, 0.2) (0.3, 0.01)
(2.7, 0.8) (1.52, 2.41)
(2.6, 3) (2.35, 2.78)
(1.5, 2.5) (2.11, 2.04)
(2, 5) (2.08, 3.34)
(3, 0) (1.87, 1.01)
(2.5, 2) (1.84, 1.67)
(0, 5) (0.13, 4.13)
(1, 4) (2.11, 3.87)
Table 4.1: Results based only on raw RSS values
It can be observed in Figure 4.2 that the points which are close to the walls,
or points for which the line of sight with one of the access points is obstructed
by the bunk bed or other object, have a greater error.
For example, it took ten measurements for the point (0, 0.2) (which means 100
seconds, since the refresh rate is 10 seconds) to find a valid pair (r1 , r2 ). This is
•
•9 •6
AP2
•9
•10
•10
•6
•4
•4
•5
•3
•5 •8
•8
•1 •7
•1 •3
•2
AP1
• •2 •7 x
Figure 4.2: Results based only on raw RSS values
due to the fact that the bunk bed represents an obstruction in the line of sight be-
tween AP2 and the client device, resulting in a r2 value significantly greater than
r1 + L, which fails the side lengths condition in the method validityCheck().
The points in the center which have an unimpeded LOS with the access points
are generally better estimated.
The average error is presented in (4.1).
10
1 Xp
∆= |xmeasured − xreal |2 + |ymeasured − yreal |2 ≈ 1.57m (4.1)
10
1
4.2 Results based on RSS measurement collection
During the first experiment, many measurements provided by the WifiMan-

ager proved to be incorrect, and thus discarded by the algorithm.
In the second approach, the values that do not pass validityCheck() test,
are not discarded anymore, if they fail only one condition. If more than one
condition is incorrect, then the measurement is not considered in the algorithm.
Depending on the failed condition, the coordinates which best approximate the
invalid case are added to the queue. This is done as follows:
• If r1 + r2 < L (the circles do not intersect), then x gets the average value
r1 + L − r2
of previous measurements and y = (the point which lies at an
2
equal distance from the two circles).
• If r12 + L2 < r22 , then y = 0 and x is calculated as in (3.22).
• If r22 + L2 < r12 , then y = L and x is calculated as in (3.22).
• If hL > l, then x = l and y is calculated as in (3.22).
Apart from considering the best estimation of an incorrect measurement, this

approach also stored several average measurements using a HashMap collection
for specific points where invalid (r1 , r2 ) pairs were frequent.
Each (r1 , r2 ) pair that the server receives from the client is compared with
the values in this collection. If any of the stored values matches the pair, the
associated real position is considered in the positioning algorithm.
This experiment was conducted in the same real positions as in the previous
section. The results can be seen in Figure 4.3 and Table 4.2.
Compared with the first test, this approach provided better results with a
lower average error as shown in (4.2).
10
1 Xp
∆= |xmeasured − xreal |2 + |ymeasured − yreal |2 ≈ 0.67m (4.2)
10
1
•
•9 •6
AP2
•9 •6
•10
•10
•4 •4
•5
•5
•8
•3 •8
•1
•1
•3
•2 •7
•2
AP1
• •7 x
Figure 4.3: Results based on RSS measurement collection
Real Measured
position coordinates
(1, 1) (1.65, 1.47)
(0, 0.2) (0.24, 0.61)
(2.7, 0.8) (1.62, 1.83)
(2.6, 3) (2.25, 2.91)
(1.5, 2.5) (1.85, 2.25)
(2, 5) (1.92, 4.67)
(3, 0) (2.41, 0.61)
(2.5, 2) (2.24, 1.79)
(0, 5) (0.06, 4.58)
(1, 4) (0.88, 4.15)
Table 4.2: Results based on RSS measurement collection
Chapter 5
Conclusions and Future Work
The current localization system uses a trilateration-based approach in a wire-

less environment. While usually there three or more access points deployed, in
this solution there are only two in order to simplify the hardware infrastructure.
Since there are only two access points, the reference measurements do not provide
sufficient information for an accurate localization.
Although the positioning system does not require special hardware and it is
adaptable to environmental changes, the main drawback in reaching room level
accuracy are the great number of possible interferences which distort the RSSI
values.
Because of that, WiFi trilateration usually has an localization error of a few
meters. In order to decrease this error, during the practical testing of the posi-
tioning system, a few estimations were considered.
During the testing, two approaches were implemented. The first method,
based only on RSSI measurements, does not accomplish a satisfying accuracy.
The other method, does not discard invalid measurements, but tries to find a
point in the localization area which best approximates the incorrect values.
Apart from considering imperfect solutions, this second method also uses WiFi
measurement collection. Several coordinates were stored by the server application
in locations where imperfect measurement were constant such as after the bunk
bed or near the walls. These erroneous received signal strengths were caused by
reflections, scattering and diffraction.
This is caused by the fact that when the line of sight is impeded, RSS are
lower than the normal value, and the calculated distance is greater than the real
one. That is why in both situations, there was a great number of imperfect
solutions.
52
CHAPTER 5. CONCLUSIONS AND FUTURE WORK 53
Future work will be focused on how the system behaves when there are several
mobile devices in the localization area, and what is the overhead at which the
server can assess multiple positions for different devices in the same localization
area at the same time.
In order to obtain a better precision in the localization algorithm, the number
of considered measurements needs to be increased. As such, future research will
study the effect of increasing the queue size and will aim to determine a satisfying
precision-time ratio.
Also, the system will try to use other technologies to acquire localization
information from multiple sources. The positioning can be improved significantly
by using various technologies such as RFID or bluetooth.
For the sake of improving the localization accuracy, other signal propagation
models will be tested and the system’s performance will be compared with the
same system when acquiring wireless data from three or more access points.
Other further work for the indoor localization system may include implement-
ing a WiFi fingerprinting in all the positions of the localization area.
Bibliography
[1] A. Bahillo and S. Mazuelas, Indoor Location based on IEEE 802.11 Roundtrip Time
Measurements with two-steps NLOS mitigation, (2009).
[2] Atreyi Bose and Chuan Heng Foh, A Practical Path Loss Model For Indoor WiFi
Positioning Enhancement, (2007), 2.
[3] B. Viel and M. Asplund, Why is fingerprint-based indoor localization still so hard?,
Proceedings of the IEEE International Conference on Pervasive Computing and
Communication Workshops (PERCOM WORKSHOPS ’14), March 2014, pp. 443–
448.
[4] B.H. Fleury, P.E. Leuthold, Radiowave propagation in mobile communications, 72–
85.
[5] Claire Swedberg, Lipa Betoni Uses Bluetooth-Based RTLS to Manage Production,
(January 2012).
[6] ESP8266-01, ESP8266-01 Pin Configuration, https://forum.arduino.cc/index.

php?topic=283043.0, As seen in June 2016.
[7] Espressif Systems IOT Team, ESP8266EX Datasheet, http://bbs.espressif.

com/, 2015.
[8] F. Subhan, H. Hasbullah, A. Rozyyev, and S. T. Bakhsh, Indoor positioning in Blue-

tooth networks using fingerprinting and lateration approach, Proceedings of the In-
ternational Conference on Information Science and Applications (ICISA ’11), April
2011.
[9] H. Liu, H. Darabi, P. Banerjee, and J. Liu, Survey of wireless indoor positioning
techniques and systems, (2007), 1067–1080.
[10] Hesham Ibrahim Ahmed, Ping Wei, Imran Memon, Yanshen Du, Wei Xie, Estima-
tion of Time Difference of Arrival (TDOA) for the Source Radiates BPSK Signal,
(May 2013).
[11] M. A. Youssef, A. Agrawala, and A. U. Shankar, WLAN location determination via

clustering and probability distributions, IEEE International Conference on Pervasive
Computing and Communications, 2010, pp. 67–90.
54
BIBLIOGRAPHY 55
[12] M. Vossiek, L. Wiebking, M. Glanzer, D. Mastela, and M. Christmann, Wireless

local positioningconcepts, solutions, applications, Proceedings of the IEEE Radio
and Wireless Conference (RAWCON 03), September 2007, pp. 580–585.
[13] National Research Council (U.S.). Committee on the Future of the Global Posi-
tioning System; National Academy of Public Administration, The global positioning
system: a shared national asset: recommendations for technical improvements and
enhancements, National Academies Press, 2013.
[14] R. Casas, D. Cuartielles, A. Marco, H. J. Gracia, and J. L. Falco, Hidden issues in

deploying an indoor location system, IEEE Pervasive Computing, 2007.
[15] Raspberry, Raspberry PI 3, https://appdevelopermagazine.com/3688/2016/2/

29/Raspberry-Pi-3-Model-B-Offers-Built-in-Wireless-LAN-and-Bluetooth/,
As seen in June 2016.
[16] Ravindra S and Jagadeesha S N, Time of arrival based localization in wireless sensor
networks: a linear approach, (August 2013).
[17] V. Moghtadaiee, A. G. Dempster, and S. Lim, Indoor localization using FM radio

signals: a fingerprinting approach, Proceedings of the International Conference on
Indoor Positioning and Indoor Navigation (IPIN 11), September 2011.
[18] Waleed Alsalih, Abdallah Almaaitah, and Wadha Alkhater, RFID Localization Us-
ing Angle of Arrival Cluster Forming, (2014).
[19] X. Hu, L. Cheng, and G. Zhang, A Zigbee-based localization algorithm for indoor
environments, Proceedings of the International Conference on Computer Science
and Network Technology (ICCSNT 11), December 2011, pp. 1776–1781.
[20] Z. Li, W. Dehaene, and G. Gielen, System design for ultra-low-power UWB-based
indoor localization, Proceedings of the IEEE International Conference on Ultra-
Wideband (ICUWB ’07), September 2007, pp. 580–585.
[21] Zack Epstein, Apples mobile market share sees big drop
in May as Android skyrockets, http://bgr.com/2016/06/02/
apples-mobile-market-share-sees-big-drop-in-may-as-android-skyrockets/,
As seen in June 2016.
[22] Zengwei Zheng, Yuanyi Chen, Tao He, Fei Li, and Dan Chen, Weight-RSS: A
Calibration-Free and Robust Method for WLAN-Based Indoor Positioning, (2015),
1–3.
Listings
3.1 getSystemService() call . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 WiFi Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Scaling coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Adding a new PositionMarker . . . . . . . . . . . . . . . . . . . . . 33
3.5 Paint Object Configuration . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Serial Communication Arduino . . . . . . . . . . . . . . . . . . . . 36
3.7 AT Command for Firmware Version . . . . . . . . . . . . . . . . . 37
3.8 Wifi Mode AT Command . . . . . . . . . . . . . . . . . . . . . . . 37
3.9 Data Transmission Speed AT Command . . . . . . . . . . . . . . . 37
3.10 Reset AT Command . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.11 AT Command for AP Parameters Configuration . . . . . . . . . . 38
3.12 AT command for IP Address Configuration . . . . . . . . . . . . . 38
3.13 AT Command for MAC Address Configuration . . . . . . . . . . . 38
3.14 Deny DHCP for wlan0 . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.15 wlan0 Static Configuration . . . . . . . . . . . . . . . . . . . . . . 39
3.16 The hostapd.conf File . . . . . . . . . . . . . . . . . . . . . . . . 40
3.17 Configuration of Path towards hostapd.conf Gile . . . . . . . . . 40
3.18 The dnsmasq.conf File . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Configuration for IPv4 Forwarding . . . . . . . . . . . . . . . . . . 41
3.20 Start dnsmasq Command . . . . . . . . . . . . . . . . . . . . . . . 41
3.21 Start hostapd Command . . . . . . . . . . . . . . . . . . . . . . . 41
3.22 MySQL Install Command . . . . . . . . . . . . . . . . . . . . . . . 42
3.23 Server Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.24 Client Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
56

Localizare Folosind Dispozitive Mobile: Alexandru Popa

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

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

Localizare Folosind Dispozitive Mobile: Alexandru Popa

Caricato da

Copyright:

Formati disponibili

Universitatea Politehnica din Bucureşti

Facultatea de Automatică şi Calculatoare

Bucureşti, Iulie 2016

Supervisor: Prof. Dr. Eng. Nicolae Ţăpuş

Bucharest, July 2016

List of Tables iii

2 State of the Art and Related Work 2

3 Hardware and Software Configuration 8

5 Conclusions and Future Work 52

2.1 Positioning Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1 Access Points Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Localization Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Results based only on raw RSS values . . . . . . . . . . . . . . . . . . 48

State of the Art and Related

The current position of a device is a very useful property in a variety of

Infrared Based Radio Frequency Ultrasound

Figure 2.1: Positioning Systems

Infrared based systems, usually available in a wireless technology, use the

into a number of different channels used by stations using the frequency-division

The main location detection techniques are presented in Figure 2.2.

Proximity Triangulation Scene Analysis

Direction based Distance based

Method based Methods Methods based

Figure 2.2: Detection techniques

Proximity detection is a localization method based on connectivity in which

Figure 2.3: Angle of arrival method

Hardware and Software

Generally, an indoor localization system is comprised of core elements such

of an ESP8266-01 module connected to an Arduino board in order to configure

• No special hardware required in the localization area

• Ease of maintenance and setup

• Localization with an accuracy error less than one meter

• Adaptable to system and environmental adjustments

• Can be used in large rooms

3.1 General description of the solution

in which RSSt is the power at the transmitter, λ is the wavelength (expressed

RSSF SP L = 20 log10 d + 20 log10 f + k (3.5)

where k is a constant which depends on the frequency and distance units as

RSSF SP L = 20 log10 d + 20 log10 f − 27.55 (3.6)

d = 10(RSSF SP L +27.55−20 log10 f )/20 (3.7)

wave’s incidence angle and polarization. The diffraction component generates

Figure 3.1: Access Points Deploy-

x2 + (y − L)2 = r22 (3.10)

Substituting y in equation (3.9) it follows that:

Figure 3.3: Lateration Technique

Another issue that has to be addressed is whether x is always a real number,

2(r12 r22 + r12 L2 + r22 L2 ) − r14 − r24 − L4 =

r12 + L2 ≥ r22 (3.16)

Another possible erroneous case is when x > l, shown in Figure 3.6.

Figure 3.6: Invalid Case: x > l

The condition imposed in this situation is that in the triangle formed by r1 , r2

Considering the definition of the area

and Heron’s formula

when r1 , r2 and L are the side lengths of an acute or right-angled triangle.

Figure 3.7: Imperfect Solution

3.2 WiFi Trilateration based on RSS measurement collec-

Because of the environmental interference, the RSSI values fluctuate at dif-

3.3 Hardware Implementation

Apart from the wireless functionalities, an enhanced version of Tensilicas L106

• Supports the 802.11 b/g/n WiFi protocols

• Low power 32-bit microcontroller unit