UPTEC F 16057
Examensarbete 30 hp
September 2016
Design and Implementation of a Demonstrator
for a Bluetooth Low Energy Based Fleet Service
System for Hand-Held Gardening and Forestry
Products
Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student
Abstract
Design and Implementation of a Demonstrator for a
Bluetooth Low Energy Based Fleet Service System for
Hand-Held Gardening and Forestry Products
Amanda Nordhamn
Today, large companies specialized in forestry or park maintenance may own very large machine fleets consisting of hundreds of
trimmers, chainsaws and brush cutters. Husqvarna Group, whose core business lies within high-end forestry and gardening products, has noticed that such companies tend to buy cheaper, low quality forestry and gardening products. The reason is thought to be that the companies lack a proper overview of the service status and utilization levels of their machines, leading to insufficient
service, causing machines to break prematurely and making it hard to motivate investments in more expensive products. Hence, the companies usually adopt a consumerist approach, and buy cheaper products that are thrown away upon breaking.
To make their products more attractive to machine park owners, Husqvarna want to explore the area of Internet of Things and equip their machines with sensing and communication capabilities. Collected data could be used to provide an overview of machine usage and service requirements to the machine parks owners, and could make it easier for machine park owners to dimension their machine fleet. In addition to this, a machine monitoring system where specific operator behavior can be tracked could enable identification of operators who consistently mistreat their
machines by, for example, running the machine engine at nonoptimal rotation speeds.
In this master's thesis, a demonstrator of the working principle of a Bluetooth Low Energy based Fleet Service System is designed and implemented, complete with an evaluation of if received signal strength indicator (RSSI) is a good enough distance estimator to determine which operator operates a certain machine.
Experiments carried out indicate that while RSSI is not a good estimator of distance, it could be used to determine the operator in closest proximity given that operators are not allowed to work closer than within a 10 m radius of each other.
Ämnesgranskare: Thiemo Voigt Handledare: Anders Mattsson
Populärvetenskaplig sammanfattning på svenska
Fler och fler produkter utrustas med sensorer och kommunikationsegenskaper i syfte att övervaka, kontrollera eller bevaka delar av sin omgivning och/eller sig själva. Till viss del handlar det om nya produkter med nya tillämpningsområden, som till exempel aktivitetsarmband, men även för produkter som traditionellt inte haft sådana egen-skaper finns det potential att skapa nya användarvärden genom att utrusta dem med sensorer.
På samma sätt som aktivitetsarmband används för att samla in data rörande bland an-nat hur användaren rört sig, skulle liknande lösningar kunna monteras på handhållna maskiner för att övervaka till exempel deras utnyttjandegrad och vibrationsnivåer. Så-dan data skulle kunna ligga till grund för utvärderingar av servicebehov och, om det finns mätbara indikationer på felaktig användning och möjligheter att särskilja data från olika maskinoperatörer, användas för identifiering av operatörer som opererar maskiner felaktigt.
I detta examensarbete har grunden till ett sådant övervakningssystem utvecklats i form av en demonstrator. Två sensorer, en som är tänkt att monteras på maskinen i fråga och en som ska bäras för identifiering av användaren, har programmerats så att den sensor som användaren bär kontinuerligt sänder en signal, medan sensorn monterad på maskinen kontinuerligt loggar sådana signaler och deras signalstyrka. Via en mobilapp för Android laddas datan sedan över från maskinsensorn och upp i en molnbaserad databas i realtid.
Tester av demonstratorn har gjorts i olika miljöer, eftersom den signalstyrka mask-insensorerna uppmäter från användarsensorerna inte bara beror på avståndet dem i mellan, utan även på hos signalen propagerar och reflekteras i objekt som träd och byggnader. Resultaten visar på att den mottagna signalstyrkan kan användas för att förutsäga operatören av en maskin ifall någon typ av algoritm som eliminerar vari-abilitet i värdena appliceras.
Acknowledgements
First and foremost, I’d like to thank Åke Cederblom for all his guidance and encourign-ing words. I’d also like to thank Thiemo Voigt for his support both before and durencourign-ing this thesis was written. Lastly, I’d like to thank everyone I’ve gotten to know during my years at Uppsala University, without whose friendship I wouldn’t have gotten this far.
Contents
1 Introduction 1 1.1 Main objective . . . 2 1.2 Methodology . . . 2 1.3 Results . . . 2 1.4 Thesis outline . . . 2 2 Background 4 2.1 Wireless Sensor Networks . . . 42.2 Bluetooth Low Energy . . . 5
2.2.1 Overview of the core system architecture . . . 5
2.3 Received signal strength indication . . . 9
2.4 Data smoothing techniques . . . 10
2.5 Hardware . . . 10
2.5.1 TI Simplelink SensorTag CC2650 . . . 10
2.5.2 LG Nexus 5X . . . 11
2.6 Software . . . 11
2.6.1 IAR Embedded Workbench . . . 11
2.6.2 Android Studio . . . 11
2.6.3 Firebase . . . 12
3 Related work 14 4 Design and Implementation 15 4.1 System hardware . . . 15
4.2 The system entities in short . . . 16
4.2.1 Operator tag . . . 16
4.2.2 Machine sensor . . . 16
4.2.3 Smartphone . . . 17
4.3 System requirements and design choices . . . 17
4.4 Operator tag and machine sensor application implementation details . . 17
4.4.1 Synchronizing the machine sensor with the operator tag . . . 18
4.4.2 Storing data in the machine sensor . . . 19
4.4.3 Machine sensor behavior when in a connection . . . 19
4.5 The Android application and Real time database . . . 20
4.5.2 The user interface . . . 20
4.5.3 Organizing the data . . . 22
4.5.4 Bluetooth functionality . . . 22
4.5.5 Storing data in the cloud . . . 24
5 Evaluation and discussion 25 5.1 The finished demonstrator . . . 25
5.2 Evaluation of the relationship between RSSI and distance . . . 26
6 Conclusions and Future work 32 6.1 Conclusions . . . 32
List of Figures
2.1 An overview of the layers of the BLE stack. . . 6 2.2 The BLE link layer state machine. The arrows indicate permitted
transi-tions between the states. . . 7 2.3 The GATT server hierarchy. The profile is at the top level, and defines at
least one service. A service may contain a number of characteristics, the entity in which modifiable data is stored. . . 8 4.1 Illustration explaining how the time instances where the machine sensor
is permitted to scan are calibrated. The arrows represent advertisements sent by the operator tag. . . 19 4.2 The login activity of the application. If the credentials of a user is entered,
the main activity will be loaded. . . 21 4.3 Main activity of the application. The applications Bluetooth features run
in the background, while information such as when the application last connected to the Firebase database is displayed. . . 21 4.4 Depiction of the flow of the Android application. The scan filters are
fetched from the Firebase database using the userid of the user. . . 23 5.1 Each star represents a measurement point of the time it took to read a
specific number of RSSI records. The line is the least squares fit to the measurement points. As expected, the time increases close to linearly with the number of records read. . . 26 5.2 The red stars represent the mean of 5 RSSI values at different distances,
and the bars the standard deviation. The measurements were collected in an obstacle free environment. The theoretical values correspond quite well with the measured values, with the exception of the measurements at 12.5 m. . . 27 5.3 The red stars represent the mean of 5 RSSI values at different distances,
and the bars the standard deviation. The measurements were collected in a wooded environment. It is clear that an exact distance cannot be determined using the measured RSSI values. . . 28 5.4 One of Husqvarna’s trimmer models. The machine sensor would be mounted
near the engine in a real life scenario. . . 29 5.5 RSSI measurements Scenario I in dBm. The RSSI varies between -45
5.6 RSSI measurements Scenario II in dBm. The RSSI varies between -61 dBm and -82 dBm. Comparing to Figure 5.5, this implies that comparing raw RSSI values could lead to erroneous predictions of the operator of a certain machine. . . 30 5.7 The calculated moving average and weighted moving average for the
RSSI measurements from Scenario I. With a moving average algorithm applied, RSSI vary between -56.5 dBm and -47.3 dBm. . . 31 5.8 The calculated moving average and weighted moving average for the
RSSI measurements from Scenario II. With a moving average algorithm applied, RSSI vary between -77 dBm and -63.3 dBm. . . 31
Abbreviations
API Application Programming Interface BLE Bluetooth Low Energy
IDE Integrated Developing Environment MCU Micro Controller Unit
RF Radio Frequency
RSSI Received Signal Strength Indicator
Bluetooth SIG Bluetooth Special Interest Group UI User Interface
Chapter 1
Introduction
Internet of Things is the network of things, such as buildings, household appliances or even trash cans, that have been equipped with wireless communication abilities to enable transmission and/or reception of data that is meaningful to its application. During the last couple of years, the interest in Internet of Things and its applications has sky rocked. Part of the reason for this is that wireless sensors have become smaller and cheaper than ever before.
For some companies, this opens up the possibility to add customer value to their products by providing product data and data analysis to the users of their products, enabling applications such as machine health monitoring. One of the companies look-ing into this is Husqvarna.
Husqvarna are traditionally known in Sweden for their now abandoned production of motorcycles and sewing machines, but in modern days they have mainly produced gardening and forestry products, ranging from chainsaws to trimmers and lawn mow-ers. Their products mainly target the professional market segment, as opposed to individual customers.
One of Husqvarna’s important market segments consists of companies that specialize in forestry or park maintenance. Such companies often own a very large fleet of ma-chines, sometimes referred to as machine parks. Because the machine park owners have trouble attaining an overview of the service needs and utilization levels of their large machine fleets, their machines often break prematurely. This in turn makes it harder for them to motivate investments in more expensive, high-end products such as the ones produced by Husqvarna.
If machine park owners could obtain information concerning the service levels and usage of their machines, it could help them maintain a functioning and properly di-mensioned machine fleet. Introducing such a system (in this report refereed to as a Fleet Service) in Husqvarna products would make Husqvarna’s high end products more attractive to machine park owners. The infrastructure of the Fleet Service could also potentially be extended so that individual user behavior can be tracked, enabling identification of operators operating machines in harmful manner.
1.1
Main objective
The main objective of this thesis is to design and develop a demonstrator for a Fleet Service. The demonstrator should demonstrate the working principle of a Bluetooth Low Energy (BLE) based Fleet Service and be able to transport data from a sensor (to be mounted onto a machine) to a cloud based server. The machine sensor should also register the received signal strength from sensors to be worn by the operators. In addition to this, a research questions will be investigated and discussed. The research question is:
• Is RSSI sufficiently accurate to correctly predict the user of a certain machine in the intended user environment?
1.2
Methodology
In this thesis work, an emphasis is put on demonstrating the working principle of an BLE based Fleet Service, rather than on investigating what actual machine park owners would be interested to gain from such a service and designing a service that suits their needs.
It should also be noted that due to time and complexity reasons, the demonstrator will not be integrated with real Husqvarna products to collect actual sensor data. However, with an infrastructure in place, extending the data sent to include actual sensor data should be simple.
1.3
Results
A prototype demonstrating the working principle of a BLE based Fleet Service System was designed and implemented. Experiments carried out indicated that while RSSI is not a good estimator of distance, it could be used to determine the operator in closest proximity given that operators are not allowed to work closer than within a 10 m radius of each other for workplace security reasons.
1.4
Thesis outline
This thesis consists of 6 chapters:
• Chapter 1 introduces the reader to the purpose of this thesis.
• Chapter 2 provides a comprehensive background to Wireless Sensor Networks, BLE and the hardware and software used in the developing process.
• Chapter 4 describes the design and implementation of the prototype.
• Chapter 5 includes an evaluation on the suitability of using RSSI to determine the operator of a certain machine in the system.
• Chapter 6 discusses the results of the thesis, including a discussion of the future possibilities for the system.
Chapter 2
Background
In this chapter, material necessary to understand the rest of the thesis is presented. This includes background on wireless technologies, BLE, and how to estimate dis-tance based on signal strength. The hardware and software used in the project are also described.
2.1
Wireless Sensor Networks
Technology advancements in recent years have made for cheap, small and energy effi-cient sensor nodes. A network of sensor nodes with wireless communication capabil-ities can be referred to as a wireless sensor network (WSN) [1]. WSNs are commonly used to facilitate wireless collection of sensor data, for example when monitoring the temperature in a certain environment. In an industrial setting, WSNs may be used for machine health monitoring, by monitoring e.g. vibration levels and wear [2]. Two of the most relevant communication standards for WSN are IEEE 802.5.14 and BLE. IEEE 802.5.14 is the basis of protocols such as Zigbee and WirelessHart [3].
In Table 2.1 some relevant features of BLE and Zigbee are presented. The main reason that the Fleet Service demonstrator developed in this thesis is BLE-based is that BLE is incorporated in nearly all new smartphones on the market, eliminating the need for an external gateway router for internet access. That Zigbee has longer range and supports a larger number of network topologies than BLE is deemed less important for this project.
Table 2.1: Comparison between relevant features of BLE and Zigbee. The technolo-gies have fairly similar properties, with BLE having a slightly higher throughput and internet access through smartphones, while Zigbee has a longer range and supports a larger number of network topologies.
Technology BLE Zigbee
Typical data throughput (kbps) 295 250
Supports beacon functionality Yes No
Supported network topologies Peer to peer, Star Star, tree, mesh
Range (m) 50 100
Internet access Through smartphone Gateway needed
May be run with coin cell battery? Yes Yes
2.2
Bluetooth Low Energy
Bluetooth Low Energy, commonly denoted as Bluetooth LE or BLE, is one of the forms of Bluetooth Wireless Communication, the other one being Bluetooth Basic rate/En-hanced Data Rate. BLE is a newer version of the Bluetooth protocol released in 2010. Rather than being an improved version of Bluetooth BR/EDR, the different versions of the protocol are suitable for different use cases. BLE targets applications where low power consumption, complexity and cost are more important than data throughput. All Bluetooth devices have a unique 48-bit address that can be used to identify the device [4].
2.2.1
Overview of the core system architecture
The Bluetooth core system architecture is defined by the Bluetooth Special Interest Group (Bluetooth SIG) in the so called core specification. The document defines how Bluetooth communication is to be conducted, on all levels of the Bluetooth stack. An overview of the different communication layers is found in Figure 2.1. In the sections following, some of the core features of the different layers will be described, starting from the bottom layer, the physical layer.
Physical layer
The physical layer is responsible for the hardware operations carried out when trans-mitting and receiving data over a wireless protocol. BLE operates in the 2.4 GHz ISM frequency band, the ISM band used for most wireless communication. 40 channels are used, of which three are used as advertising channels and the rest are used for communication between connected devices [4].
Figure 2.1: An overview of the layers of the BLE stack.
Link layer
The link layer handles establishment and management of communication links. The operation of the BLE link layer can be thought of as a state machine with five states; advertising state, standby state, scanning state, connection state and initiating (a connection) state. The link layer may only operate in one state at a time, and may not enter states arbitrarily. Figure 2.2 depicts the different states and the permitted transitions. Depending on if the connection state is entered from the initiating state or the advertising state, a device will be operating as a master or as a slave respectively. There are four types of advertising events: connectable directed, connectable undi-rected, non-connectable undirected and scannable undirected. Directed advertising targets a certain device, while undirected advertising does not.
Both advertising and scanning may be filtered in the link layer, so that the device only scan for or responds to peer devices with certain addresses. The polices that regulates filtering are referred to as white list polices. Utilizing white list polices may lower power consumption, since processing irrelevant to the device’s application at higher layers can be avoided [4].
L2CAP
The logical link and adaptation layer (L2CAP) acts as an interface between the higher and lower layers of the Bluetooth Stack. It segments and reassembles data packets, provides support for retransmission and error control, and provides quality of service (QoS) management [4].
Figure 2.2: The BLE link layer state machine. The arrows indicate permitted transi-tions between the states.
Security manager
BLE communication may be carried out under different levels of encryption and au-thorization. These procedures are defined by the security manager. The process where two Bluetooth devices share their security features and temporary encryption keys is called pairing. Devices that have been paired may share encryption keys for future reference. This process is called bonding. Pairing is not a requirement to enable communication between two BLE devices [4].
Attribute Protocol
The Attribute protocol (ATT) and the generic attribute profile (GATT, the subject of next paragraph) together define how data is transferred in BLE. As seen in Figure 2.1, the ATT protocol operates at a lower level than GATT. The ATT protocol defines the data entity "attribute", which are the building blocks of GATT. The ATT protocol also defines the operations that can be conducted on an attribute and what security measures needs to be fulfilled to do so (if any) [4].
Generic Attribute Profile
The Generic Attribute Profile (GATT) defines the operations and framework for data transfer. Two roles are defined, the GATT server and the GATT client. The two roles are not mutually exclusive and they are not tied to any particular GAP role (see next paragraph) or link layer state. Put simply, a GATT client requests and receives data from a GATT server, whose function is to make the data it stores available to the GATT client. The GATT client must have conducted a so called service discovery before it
can start reading and writing to the GATT server. During a service discovery, all the GATT servers services, characteristics and their properties are exposed to the GATT client. If the client does not have a trusted relationship with the server (the devices are not paired or bonded), it must rediscover the server every time a connection is established.
Within the GATT Server, data is organized in a hierarchy (see Figure 2.3). The profile itself is at the top level. The profile defines one or more services. Each service may contain a number of characteristics. It is within the characteristics that the actual data is stored. All characteristics have a declaration that define their data format and permitted operations, such as if the characteristic can be read or written from a remote device.
Figure 2.3: The GATT server hierarchy. The profile is at the top level, and defines at least one service. A service may contain a number of characteristics, the entity in which modifiable data is stored.
Generic Access Profile
All BLE devices must implement the Generic Access Profile (GAP). Four GAP roles are defined: Central, Peripheral, Observer and Broadcaster. A combination of roles is also permitted. Each role defines the required features and functions of the Bluetooth
lay-ers. For BLE, this profile defines the Link Layer, Security Manager, L2CAP, Attribute Protocol, and Physical layer. Various functions and behaviors such as connection es-tablishments are also described by the GAP.
A device operating in the central role may scan for advertising devices, and initiate connections to those who are connectable. If a connection is successfully established, the device will be the master of the connection since it entered the connection from the initiating state. A central device must have both receiving and transmitting capa-bilities.
A peripheral device cannot initiate connections, but it can be connected to by a central device. Because it will enter the connection state from the advertising state, it will in that case operate as a slave. A peripheral device must have both receiving and transmitting capabilities.
A device operating in the observer role is a device which, similarly to a device op-erating in the central role, scans for advertising Bluetooth devices. Unlike a central device, it does not support connections. It must have a receiver, but a transmitter is optional. An observer must implement passive scanning.
A broadcaster uses advertisements to broadcast data. In contrast to a peripheral device, it does not support connections. A broadcaster must have a transmitter but it is optional for it to have a receiver. It must be able to advertise with a non-connectable undirected event [4].
2.3
Received signal strength indication
The quality of a signal can be evaluated using a number of different criteria, such as signal to noise ratio (SNR), bit error rate (BER) or RSSI. RSSI evaluates the received signal power and is often expressed in either dB or dBm. It is defined as:
RSSI = 10 log
P
RXP
Ref(2.1)
where
P
RX is the received signal power andP
Ref a reference power, usually 1 mW[5]. Assuming that the a signal follows the log-normal path loss model, the RSSI can be calculated as:
RSSI
dBm= −(10 ∗ n ∗ log(d) + A)
(2.2)where
n
the attenuation factor,d
is the distance between the transmitter and receiver in meters and A is a measured reference RSSI in dBm at d = 1 m. The attenuation fac-tor depends on the signal environment and is equal to 2 in a free space environment. However, in real environments, signal propagation and thus the attenuation factor is affected by phenomena such as reflection, absorption and interference [5].Because RSSI is affected by the antenna gains, two devices might not measure the same RSSI even if they receive the same transmitted signal at the same distance and environment if they have different chip sets.
2.4
Data smoothing techniques
Moving averages can be used to smooth variations and fluctuations in any time series data, and is commonly used when analyzing different financial data such as stock prices.
The most simple form of moving average is calculated as the mean of the n previous data points d, or:
SM A =
1
n
∗
nX
i=1d
M −i.
(2.3)A weighted moving average assigns different weights to the data points. This may for example be useful if recent data should be given greater significance than less recent data. If weights are assigned as weight w for data point
d
m, weight w-1 for data pointd
m−1 etc. all the way down to weight w = 1, the WMA can be expressed as:W M A =
w
n∗ d
m+ w
n−1∗ d
m−1+ ... + d
m−n+1w
n+ (w
n− 1) + .... + 2 + 1
(2.4)
2.5
Hardware
In this section, the hardware used to develop the Fleet Service demonstrator is de-scribed.
2.5.1
TI Simplelink SensorTag CC2650
Simplelink SensorTag is a sensortag manufactured by Texas Instruments, TI. The SensorTag is built around the multi-standard CC2650 wireless micro controller unit (MCU). The CC2650 MCU features a 2.4 GHz transceiver that is compatible with BLE, Zigbee and 6LoWPAN. The main processor of the CC2650 is a Cortex M3, while the radio frequency, RF, core is run by an external Cortex M0 processor. The ultra low power consumption of the processors and radio makes it possible to run the CC2650 with a CR2032 coincell battery. It may also be powered through an external power source during programming and debugging. The most power consuming features of the CC2650 is the RF features. In receiving mode, the current draw is around 6 mA. In transmitting mode, the current draw is 6.1 mA with an output power of 0 dBm or 9.1 mA with an output power of 5 dBm [6].
The SensorTag runs TI-RTOS, a real time operating system developed by TI.
2.5.2
LG Nexus 5X
The smartphone application was developed for and tested on a LG Nexus 5X. The Nexus 5X runs Android. Android is the dominating mobile operating system for smart-phones, with 66% of the world market share [7]. Android is developed and maintained by Google. The latest version of Android at the time of app development was Android 6.0, also called Android Marshmallow, and this has been the targeted version for the developed application.
2.6
Software
In this section, the software used when developing the applications for the TI Sen-sorTags and LG Nexus 5X is described.
2.6.1
IAR Embedded Workbench
IAR Embedded Workbench is an integrated development environment (IDE) by IAR Systems. It features powerful tools for developing embedded software, such as a C/C++ compiler and debugging tools. IAR Embedded Workbench is a common tool used when developing applications for embedded systems and has been used to de-velop the applications for the TI SensorTags.
2.6.2
Android Studio
While several different IDE’s can be used to develop Android applications, Android Studio is the most common, and official, IDE. It was used to develop and debug the Android application.
Android Studio projects contains modules. All projects contain the Android App mod-ule, but may also contain test modules and library modules. Each Android App Mod-ule contains source files (java code), resource files (non-code resources such as visual components and layout files) and a so called app manifest. The app manifest declares important information regarding the application, such as the permissions it may need to access the phones hardware resources, minimum application programming inter-face (API) level needed to run the app and the components used by the app [8]. An example of a component that may be declared is a so called activity. Activities are the components that enable the user to interact with the application. An application typically consists of more than one activity, and each activity usually has a layout file that defines its layout as well as a source file that defines how the activity will behave.
Android BLE API
Support for BLE was introduced in Android 4.3, API Level 18. Out of the 4 GAP roles, it only supports the central role. It supports operation both as a GATT server and GATT client.
To enable BLE features, an app has to have three app manifest permissions: the "Bluetooth", "Bluetooth Admin" and any of "Access location: Fine" or "Access location: Coarse" permissions.
Even if BLE consumes less power than classic Bluetooth, scanning for peripheral devices is quite power consuming. Once the requested device is found, scanning should be stopped. The results from a scan are delivered through a callback function. White list scanning is possible.
Once a device is found, it is possible to connect to it. Also in this case, the results are delivered through a callback function. When connecting to a device’s GATT server, the option exists to pass a variable that enables automatic connection to the specific device whenever it is proximity and advertising. With this option enabled, the appli-cation will continuously perform a scan in the background and connect to the specific device once it is available. However, the scanning interval for the background scan is long (presumably to prevent battery drainage), resulting in that it typically takes long before the remote device is found.
If a connection is successfully established, the Android device can perform a ser-vice discovery to discover the remote deser-vice’s characteristics. If any are found, the Android device can attempt to read, write or subscribe to notifications about charac-teristic value changes. Once the Android device is done, it should disconnect or close the connection to the GATT server [9].
2.6.3
Firebase
Firebase is a platform owned by Google that provides cloud services such as real-time databases, cloud messaging and user authentication. With the free version of Firebase, a host can store up to 1 GB of data in the database. For this project, Firebase was used to allow for user authentication and to store data in a database. This might not be the best choice for Husqvarna in the future since they may not want to depend on an external provider for these services, but it was used in this project to illustrate the concept because it is free and fast to deploy.
Firebase databases are, unlike most databases, not relational databases, but instead so called NoSQL databases. Data is therefore not organized in the typical tables found in relational databases. In Firebase, the database instead takes the form of a JSON tree. JSON is a data format commonly used in data-interchange applications. A JSON tree is simply a tree structure where the nodes are JSON objects.
may be an advantage to denormalize data in NoSQL databases to achieve a flat data structure. An obvious disadvantage of this is update problems (updates requiring changes in more places than one) and data redundancy (the same value is represented in several places).
Chapter 3
Related work
A number of studies have been conducted regarding the use of RSSI measurements for localization. Many of the studies have focused on indoor localization. For exam-ple, in 2007 Zhou and Pollard estimated the distance between two devices operating on classic Bluetooth based on RSSI, with the devices in line of sight of each other at distances ranging between 0 to 6.8 m. The calculated mean absolute error was measured to be 1.2 m [10].
Dong and Dargie also evaluated the reliability of using RSSI for indoor localization in 2013. They state that fluctuations in the signal strength are too high for RSSI to be used for indoor localization even when a moving average is used [11].
Work has also been performed relating to RSSI in outdoor environments. For example, Liu et al. investigated the possibility to estimate face-to-face proximity using RSSI values collected by smartphones under different conditions, where the outdoor case was one of the studied cases, in 2014. The effect of the direction of the phones was also investigated. They found that RSSI values recorded with Bluetooth could be used to detect proximity in their use cases and that the orientation of the phones had little effect on the RSSI measurements [12].
During their work on a method for outdoor localization system Peng and Sichitiu noted that, to their surprise, RSSI measurements were not affected to any large extent in a heavily wooded area in comparison to an area without any significant obstacles [13]. Several articles focus on how to improve distance estimation algorithms based on RSSI measurements. In 2015, Svevcko et al published an article where a particle filter for distance estimation with RSSI values was developed and evaluated. They utilized several receiving antennas [14]. Oliviera et al. investigated relative localiza-tion for mobile robots based on RSSI measurements. They used a Kalman filter and the Floyd–Warshall algorithm to smooth the RSSI measurements [15]. The effect of antenna polarization on accuracy of location identification was investigated in 2009 by Huang et al. They state that antenna polarization should be taken into account to achieve greater location accuracy [16].
Chapter 4
Design and Implementation
In this chapter, the design and implementation of the Fleet Service demonstrator is explained. Some basic requirements on the system are presented, as well as the enti-ties required to design the system. When all hardware parts of the Fleet Service have been established, the implications of their properties on the design are presented. After that the design choices made when designing the demonstrator are presented, followed by sections describing some details of the design and implementation.
4.1
System hardware
The Fleet Service demonstrator should demonstrate the working principle of a BLE-based Fleet Service. It is developed under the assumption that RSSI will prove to be a good enough estimator of the most likely user. This assumption is evaluated in Chapter 5.
Under this assumption, three units are needed to form the basis of a Fleet Service: 1. An operator tag, to be worn by the machine operator, uniquely identifying the
operator.
2. A machine sensor, to be mounted on a machine, collecting machine data and information about the operator tags in its range.
3. A smartphone, to be carried by machine operators. Data will be collected and uploaded to a cloud based database through a smartphone application.
At first sight, the operator tag might seem redundant since one might think that the smartphones could be used both for identification of the operator and data collection. However, the introduction of the operator tag eliminates the variability in RSSI that would otherwise be introduced if operators have different smartphones with different Bluetooth radios.
To demonstrate the concept, it was deemed sufficient that only collected RSSI values and not real sensor data should be reported by the machine sensor to the phone, since
the same principle used to send this data could be used to send sensor data.
In this project, operator tag and the machine sensor applications are implemented on TI SensorTags, and the smartphone application is developed to run on a LG Nexus 5X phone.
4.2
The system entities in short
In this section, the purpose of the operator tag, machine sensor and smartphone are expanded upon and the functionality needing implementation for this to be achieved is outlined. For each of the entities, any restriction the entity might put on the overall system design is presented.
4.2.1
Operator tag
The operator tag has one purpose only - to enable identification of a certain operator. It does not have to be able to connect to any device in order to do so. Transmission of any advertisement data is sufficient, since the Bluetooth address of the tag is unique and can be used by the receiver of the advertisement to identify the transmitter. The operator tag thereby exhibits the behavior of device operating as a BLE Broadcaster. According to the Bluetooth SIG core specification, the longest possible advertising interval for a BLE device is 10,24 s. To ensure that several beacons can coexist with-out packet collisions, a random delay of 0-10 ms is added to the defined advertising interval by the Bluetooth stack. Each transmission typically lasts no longer than one millisecond.
The power consumption of the operator tag will depend on how often it advertises. To achieve a low energy consumption the advertising interval should be long.
4.2.2
Machine sensor
The machine sensor should be able connect to the smartphone to transfer data, which is typical for a BLE device operating in the Peripheral role. It should also be able to receive advertisement packages from the operator tags, which is typical behavior for a BLE device operating in the Observer role. These kinds of multiple roles are supported by the Bluetooth SIG core specification and by the SensorTag hardware. The power consumption of the machine sensor is dependent both on the time it spends in the scanning state and in the advertising/connected state. To achieve a low power consumption, the time spent in these states should be minimized but still be sufficient to provide effective communication. Data should only be stored on the machine sensor for a limited time before being forwarded to enable near real time analysis of the data. Also, no data should be deleted from the machine sensor before it is confirmed that the data has been fetched by a smartphone.
4.2.3
Smartphone
The smartphone should be able to find and connect to machine sensors in its proximity to collect data from them. This is typical for a device operating in the central role, which is also the only role supported by Android’s BLE API. This also means that the smartphone will be the master when connected to a machine sensor.
The time it takes to find, connect and fetch data from a peripheral device is non-negligible and has to be taken into account when designing the system, since the machine sensor cannot scan for operator tags while connected to the smartphone.
4.3
System requirements and design choices
The requirements on the system can be summarized as: • The operator tag should advertise at least every 10,24 s.
• The machine sensor should divide its time between scanning for operator tags and being connectable to by smartphones in a fashion that minimizes the time it has to scan or be in a connection.
No formalized requirement on how often the machine sensor should scan for operator tags had to be taken into account. However, a sufficient amount of data points to make it possible to make some prediction of which operator tag is closest to the machine at an instance of time should be generated. At the same time, the number of required data points should preferably be kept low since collecting many data points would require the operator tag to transmit more often and thereby increase its power consumption. One data point per operator tag (up to 8 operator tags) and 10 second period was deemed sufficient for these reasons.
Since the machine sensor cannot scan for operator tags while being connected to a smartphone, the main issue that had to be addressed with the system design was how the machine sensor should fulfill both its purposes in a power efficient fashion. A design choice to introduce two different modes for the machine sensor was made, one where it was discoverable for other BLE devices and one where it was permitted to scan. The machine sensor should switch between these modes in an appropriate fashion.
4.4
Operator tag and machine sensor application
imple-mentation details
In this section, some of the critical elements of the implementation of the applications for the operator tag and machine sensor are described.
4.4.1
Synchronizing the machine sensor with the operator tag
As mentioned in Section 4.3, one data point per operator tag during a 10 second period should be collected for every operator tag (up to 8 operator tags) in proximity. This could quite easily be achieved by for example letting the operator tag advertise every second and the machine sensor scan for one second every 10 seconds. However, since both devices run on coin cell batteries this has to be achieved with a more power efficient approach.
As explained in Section 4.3, the machine sensor has to divide its time between scan-ning and being available for a connection. It is decided that during every 10 second period, the machine sensor is permitted to scan for operator tags during a five sec-ond window. This means the operator tags must advertise at least every 5 secsec-onds in order to be detectable by the machine sensor.
Keeping this in mind, the regularity of the operator tag’s advertising can be utilized to cut down the machine sensor scanning time considerably, since if the machine sensor receives a advertisement from an operator tag at time
a
t, the time of the nextadvertisement
a
t+1is simplya
t+1= a
t+ 5s + randomdelay,
(4.1)where the random delay is the 0-10 ms added to ensure that broadcaster can coexist (see Section 4.2.1). Since the machine sensor may only scan for a five second period every 10 s, it is
a
t+2that is of interest. Utilizing Equation 4.1,a
t+2must lie within theinterval
a
t+ 10s ≤ a
t+2≤ a
t+ 10s + 20ms.
(4.2)Since the transmission of the advertisement typically takes no longer than 1 ms this means scanning can be reduced to 20 ms per operator tag and 10 second period. Given that the sensor environment is dynamic and operator may move in and out of a machine sensors range, the machine sensor should conduct a longer scan from time to time. This ensures that operators who have moved in range are detected, and that operators who have moved out of range are no longer accounted for. The time of these events are currently set to once every minute. The procedure is describe in Figure 4.1.
Implementing the synchronization on the machine sensor
This section gives a short overview of how the synchronization is actually imple-mented on the TI Sensortag.
The machine sensor has to be able to collect data from up to 8 operator tags. Upon initialization of the machine sensor, 8 timers are initialized and stored in an array.
Figure 4.1: Illustration explaining how the time instances where the machine sensor is permitted to scan are calibrated. The arrows represent advertisements sent by the operator tag.
During the 5 s scan events, the addresses of the found operator tags are also stored in an array. A found device is classified as an operator tag if it is advertising non-connectable and its advertisement data include the key "HQtag" (short for Husqvarna tag). The index an operator tag gets assigned in this array is used to pair the tag with one of the 8 timers, which is started when the advertisement is received.
The timers are set to run out shortly before the advertisement from the operator tag is expected. When the advertisement is received, the address it was sent from is used to find the index of the operator tag, which in turn is used to restart the correct timer. When the timer that triggers the longer 5 second scan expires, the array of operator tags is reset. This ensures that the machine sensor stops scanning for operator tags that are no longer in proximity.
4.4.2
Storing data in the machine sensor
When an advertisement from a device that is classified as a operator tag is received by the machine sensor, the address of the transmitter and the RSSI are stored in a circular buffer. Because the machine sensor is not meant to be used for persistent data storage, this buffer is currently set to store up to 20 data records.
4.4.3
Machine sensor behavior when in a connection
When the machine sensor is in a connection, the oldest piece of data from the circular buffer that has not yet been fetched by a smartphone is stored in a characteristic in the sensor’s GATT server. All data associated with operator tags in proximity is stored
in the same characteristic in the GATT Server. This characteristic is 12 bytes long. Bytes 1-6 stores the MAC address, bytes 7-8 the measured RSSI and bytes 9-12 the time in milliseconds since the machine was started. The characteristic has both read and write permissions, to enable an implementation of acknowledged reads.
The Android BLE stack does not natively support acknowledged read operations, but since no data should be removed from the machine sensor before it has been stored in the phone memory, a simple acknowledgement mechanism was implemented. When an acknowledgement from the smartphone is received by the machine sensor, it checks if there are more un-fetched data in the circular buffer. If there are, it writes the now oldest piece of data to the GATT server. When there is no more data, it writes a message where all bytes are zero to the GATT server.
4.5
The Android application and Real time database
In this section, the design and implementation of the Android application is presented.
4.5.1
Application overview
The Android application has two main purposes;
1. It should scan for nearby machine sensors, connect to them and fetch relevant data without any user interaction.
2. It should act as a gateway to the cloud service where data should be permanently stored without any user interaction.
Different user may have permission to connect to different groups of machines. Data regarding users and their permissions should be stored in the cloud service and it should not be possible to alter this data from the Android application.
4.5.2
The user interface
Since the main purpose of the application is to carry out actions without the need for user interaction, a simple user interface (UI) was designed and implemented. The UI consists of only two activities, a login activity and the main activity.
Figure 4.2 display the login activity. Upon pressing "Submit", checks to ensure that the input is valid are conducted before any connection to the cloud service is estab-lished. Providing that the entered information matches that of an existing user, the user is sent to the main activity. This activity is displayed in Figure 4.3. This activity simply displays some useful information such as the most recent time instance the application connected to a machine and the address of that machine, and also the last time instance data was successfully uploaded to the real-time database.
Figure 4.2: The login activity of the application. If the credentials of a user is entered, the main ac-tivity will be loaded.
Figure 4.3: Main activity of the application. The applica-tions Bluetooth features run in the background, while informa-tion such as when the applica-tion last connected to the Firebase database is displayed.
4.5.3
Organizing the data
Since the database is a NoSQL database, data is stored in a JSON tree structure rather than in traditional database tables. The structure of the tree is seen below. 1 {"hfsprototype": {
2
3 "users": { 4 "$userid": [
5 {"name": "First name", "value": "Amanda"},
6 {"name": "Usertag", "value": "B0:B4:48:C8:73:81"}, 7 "machine groups":[
8 {"name": "Trimmers", "value": true}
9 ] 10 ] 11 } 12 13 "machine groups": { 14 "Trimmers": [
15 {"name": "B0:B4:48:D3:06:85", "value": "true"}, 16 {"name": "B0:B4:48:C3:09:76", "value": "true"},
17 ] 18 } 19 20 "data records": { 21 "B0:B4:48:D3:06:85": [ 22 "$recordid":[
23 {"name": "rssi", "value": "-75"}, 24 {"name": "time", "value": "10245"},
25 {"name": "usertag", "value": "B0:B4:48:C8:73:81"}
26 ]
27 }
28 }}
The userid is unique to a specific account and may be fetched when authenticating a user. In this projects, nodes "users" and "machine groups" can only be modified using the Firebase console in the web application. The reasoning for this is that only administrators should be allowed to add users and machines to the system. The data records on the other hand are added as data is pushed by an application user to the database. Data records are ordered by what machine sensor fetched the data.
4.5.4
Bluetooth functionality
The Android application should be able to run even when the UI is not active. To achieve this, the Bluetooth features are implemented in a so called Service, bound
to the main activity, and the activity acquires a partial wake-lock upon creation. The partial wake-lock ensures that the CPU keeps running even if the screen turns off due to inactivity. A flow diagram for the rest of the program flow can be found in Figure 4.4. When the application is started, the user’s userid is used to fetch the names of machine groups that the specific user have permission to connect to. The names are in turn used to fetch the Bluetooth addresses to machines belonging to any of those machine groups. The addresses are used to create the scan filters used by the application. The phone then enters the scanning state. If a peripheral device is found, the phone will attempt to connect to the GATT server of the found device. When this has succeeded, the phone will continuously read from the GATT server until it reads a characteristic where all bytes are zero. When such a message is read, it closes the connection and re-enters the scanning state.
Figure 4.4: Depiction of the flow of the Android application. The scan filters are fetched from the Firebase database using the userid of the user.
4.5.5
Storing data in the cloud
When any data has been fetched and converted to the right format, the application attempts to push this data to the Firebase database. If no internet connection is currently available, data is automatically cached and uploaded to the database as soon as an internet connection is available. This data persistence lasts over one app session only.
Chapter 5
Evaluation and discussion
In this section, the resulting demonstrator is evaluated. The accuracy of distance estimations based on RSSI measurements collected with the demonstrator is also evaluated and discussed.
5.1
The finished demonstrator
The finished demonstrator has been tested and is functioning according to the re-quirements. It has been tested with two operator tags (and other Bluetooth devices) in proximity, and RSSI values transmitted by the operator tags were successfully col-lected and saved to the cloud based database while the other Bluetooth devices were ignored.
Since there exists no method to synchronize the advertising of the operator tags, it is possible for two operator tags to advertise at the same time. However, the risk is very small. Given that the advertising start randomly during a 5 s period and last for only 1 ms, the risk that any two operator tags will transmit at the same time is 0.02
%
. In an environment with 7 operator tags already running, the probability of an 8th operator tag starting to advertise at the same time as any of the other is 0.14%
. All elements of the communication between the machine sensor and the smartphone that takes time are interesting to study because they give indications to how much data can be read during the 5 s window where the machine sensor is allowed to com-municate with the smartphone. These elements include the time it takes to connect to the GATT server and the time it takes to read different quantities of data.Because of this, the time it takes for the demonstrator to fetch different quantities of RSSI records was investigated. The result is presented in Figure 5.1. Each RSSI record consisted of 16 bytes of data. The times in this figure are the time from when read characteristic is first called until the indication that there is no more data is read. Hence it does not only include the time it takes to read the characteristic, but also the time it takes to write the acknowledgement to the machine sensor. It does
not include the time it takes to connect to the GATT server. As expected, the time increases close to linearly with the number of RSSI measurements read. If only one record is read, this takes about 250 ms. Each additional record read generally adds 150 ms, with some deviation.
Figure 5.1: Each star represents a measurement point of the time it took to read a specific number of RSSI records. The line is the least squares fit to the measurement points. As expected, the time increases close to linearly with the number of records read.
The time it takes to establish a connection to the GATT server was found to be around 200 ms in general, and thus rather insignificant for how much data can be read. The same goes for disconnecting from the server, which was found to take only a couple of milliseconds.
5.2
Evaluation of the relationship between RSSI and
dis-tance
As part of evaluating the potential of using RSSI for user determination, RSSI mea-surements were collected at different distances in one outside environment free of obstacles, and one forest environment with trees and bush wood. The sensors were placed at an equal height, 90 cm above the ground, and they were placed so that the relative angle in between the sensors was as small as possible. Measurements were taken at different distances between 0.5 m and 15 m. 5 measurements were collected at each distance. The result for the obstacle free environment, together with the theoretical RSSI curve, is presented in Figure 5.2. The result for the wooded area, together with the theoretical RSSI curve, is seen in Figure 5.3. The theoretical curve
was calculated according to Equation 2.2, with A as the average of the RSSI mea-surements at 1 m in each environment. In both the obstacle free environment and the wooded environment, the measured RSSI values deviate from theory, but with the exception of the measurements at 12.5 m, the deviations are relatively small. It is however obvious from the results that determining the distance between the receiver and the transmitter with great accuracy is not possible using only raw RSSI values.
Figure 5.2: The red stars represent the mean of 5 RSSI values at different distances, and the bars the standard deviation. The measurements were collected in an obstacle free environment. The theoretical values correspond quite well with the measured values, with the exception of the measurements at 12.5 m.
For workplace security reasons, operators of Husqvarna machines are not permitted to work within a 10 meter radius of each other. Even if the measured RSSI values de-viate from theory, the RSSI at shorter distances were consistently significantly higher than at 10 meter and more. Therefore the results indicate that while the RSSI values may deviate too much from theory in order to be used to estimate a distance with great accuracy, it is still possible that the RSSI values are accurate enough to predict the most likely operator in a Fleet Service.
This was investigated further in an experiment where the operator tag was rotated in relation to the machine sensor. This experiment was only carried out at a distances 1 meter and 10 meters. The purpose was to investigate the interval in which RSSI values varied at these distances due to rotation only, and to compare the magnitude of the worst RSSI at 1 meter to the best RSSI at 10 meters. The operator tag was rotated by 45 degrees at the time and four measurements where collected for each direction, collecting 32 measurements in total at each distance. The result is found in Table 5.1. The mean RSSI’s at the distances are very close to the ones found in 5.2 and 5.3. There is some deviation from this mean, but not enough that any measurement taken at 1 meter could be confused with one at 10 meters.
Figure 5.3: The red stars represent the mean of 5 RSSI values at different distances, and the bars the standard deviation. The measurements were collected in a wooded environment. It is clear that an exact distance cannot be determined using the mea-sured RSSI values.
Table 5.1: The mean, minimum and maximum RSSI in different environments and distances. 32 measurements were collected in each environment at each distance. All RSSI values are in dBm.
Environment Distance [m] Mean RSSI Min RSSI Max RSSI
Obstacle free 1 -45.5313 -49 -42
Obstacle free 10 -64.5 -73 -61
Wooded 1 -45.22 -50 -43
Wooded 10 -70.5 -84 -64
As an extension to this experiment, an experiment was carried out in a more realis-tic scenario. The operator tag was placed in the front pocket of a test person and a machine sensor was placed on a dummy machine. In a real life setting, the ma-chine sensor would be mounted in proximity to the engine. The relative placement of the engine of a trimmer can be seen in Figure 5.4. This was imitated during the experiment.
RSSI measurements were then collected with the test person moving as if using the dummy machine as a trimmer. Two measurement series were carried out, one where RSSI measurements from the operator tag of the person holding the dummy machine were collected (Scenario I), and one where the machine collected measurements from another operator tag worn by a test person 10 meter away (Scenario II).
As seen in Figure 5.5 and 5.6 the RSSI varies considerably when the operators are moving. The RSSI in Figure 5.5 is often lower than for 1 m in previous experiments.
Figure 5.4: One of Husqvarna’s trimmer models. The machine sensor would be mounted near the engine in a real life scenario.
This effect is not as profound in the measurements recorded by the operator tag 10 meters away. The RSSI for Scenario I vary between -45 dBm and -61 dBm, while the RSSI for Scenario II vary between -61 dBm and -82 dBm. This implies that comparing single raw RSSI values to each other may possible lead to erroneously predictions of the operator of a certain machine.
Figure 5.5: RSSI measurements Scenario I in dBm. The RSSI varies between -45 dBm and -61 dBm.
To reduce the variability in RSSI the result of applying a moving average and a weighted moving average algorithm was investigated. The results for when 3 con-secutive values were taken into account can be found in Figure 5.7 for Scenario I and Figure 5.8 for Scenario II. The results are fairly similar for both algorithms, with
Figure 5.6: RSSI measurements Scenario II in dBm. The RSSI varies between -61 dBm and -82 dBm. Comparing to Figure 5.5, this implies that comparing raw RSSI values could lead to erroneous predictions of the operator of a certain machine.
slightly less variability for the moving average that is not weighted. The RSSI for Scenario I when the moving average algorithm has been applied vary between -56.5 dBm and -47.3 dBm. For Scenario II with the moving average applied the RSSI vary between -77 dBm and - 63.3 dBm. This indicates that RSSI, with some smoothing algorithm applied, could be sufficiently accurate to use in estimations of the most likely operator of a machine. Further extending the moving averages to be calculated over more than 3 consecutive values would increase the separation, but in a real sce-nario it would also increase the time it would take to detect that two operators have exchanged machines.
Figure 5.7: The calculated moving average and weighted moving average for the RSSI measurements from Scenario I. With a moving average algorithm applied, RSSI vary between -56.5 dBm and -47.3 dBm.
Figure 5.8: The calculated moving average and weighted moving average for the RSSI measurements from Scenario II. With a moving average algorithm applied, RSSI vary between -77 dBm and -63.3 dBm.
Chapter 6
Conclusions and Future work
In this chapter, conclusions and suggestions for future work are presented.
6.1
Conclusions
The goal of this thesis was to develop a demonstrator for a BLE-based fleet service intended for Husqvarna products, and to evaluate the potential of using RSSI for identifying the operator of certain machine at any time instance.
The system architecture of the demonstrator included 3 entities: operator tags to be worn by operators, machine sensors to be mounted on the machines, and an Android smartphone. The work included i.e. the development of a synchronization procedure, an Android application and design of the real time database structure.
The demonstrator works as specified. With all units running, RSSI measurements are automatically collected by the machine sensor, and ultimately stored in a online database.
Experiments carried out indicate that RSSI with some version of a moving average algorithm could be good enough to determine the operator a certain machine, given that operators are not permitted to work within a 10 meter radius of each other.
6.2
Future work and applications
The Fleet Service developed in this thesis has a lot of room for extension. With the infrastructure in place, the system could be extended to collect sensor data regarding i.e. vibrations. The machine sensor and operator tags could also be programmed to transmit only when moving, to reduce their power consumption.
When the system is deployed in a real life setting, Husqvarna should look closer into how data should be stored, processed and presented. Another back end service for
data storage than the one used in by the demonstrator should be looked into, both because it might be beneficial not to be reliant on a third party service and because a service where real time analysis of the data is possible would be beneficial. They could also look into means for identifying malfunctioning machines, and evaluate if data mining methods such as classification methods can be utilized to detect machines which are in risk of malfunctioning if they are not serviced.
Bibliography
[1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless sensor networks: a survey,” Computer networks, vol. 38, no. 4, pp. 393–422, 2002. [2] C.-Y. Chong and S. Kumar, “Sensor networks: evolution, opportunities, and
chal-lenges,” Proceedings of the IEEE, vol. 91, no. 8, pp. 1247–1256, 2003.
[3] I. E. Commission, “Internet of things: Wireless sensor networks.” http:// www.iec.ch/whitepaper/pdf/iecWP-internetofthings-LR-en.pdf, 2014. Ac-cessed: 2016-07-04.
[4] B. S. I. Group, “Specification of the bluetooth system, v4.2,” 2014.
[5] S. J. Halder, P. Giri, and W. Kim, “Advanced smoothing approach of rssi and lqi for indoor localization system,” International Journal of Distributed Sensor Net-works, vol. 2015, p. 32, 2015.
[6] T. Instruments, “Cc2650 simplelink™ multistandard wireless mcu,” 2015. Ac-cessed: 2016-07-05.
[7] StatCounter, “Top 8 Mobile Operating Systems on Jan 2016.” http://gs. statcounter.com/#mobile_os-ww-monthly-201601-201601-bar.
[8] Google, “Meet Android Studio.” http://developer.android.com/studio/ intro/index.html.
[9] Google, “Bluetooth Low Energy.” https://developer.android.com/guide/ topics/connectivity/bluetooth-le.html.
[10] S. Zhou and J. K. Pollard, “Position measurement using bluetooth,” IEEE Trans-actions on Consumer Electronics, vol. 52, no. 2, pp. 555–558, 2006.
[11] Q. Dong and W. Dargie, “Evaluation of the reliability of rssi for indoor localiza-tion,” in Wireless Communications in Unusual and Confined Areas (ICWCUCA), 2012 International Conference on, pp. 1–6, IEEE, 2012.
[12] S. Liu, Y. Jiang, and A. Striegel, “Face-to-face proximity estimationusing blue-tooth on smartphones,” IEEE Transactions on Mobile Computing, vol. 13, no. 4, pp. 811–823, 2014.
networks,” ACM SIGMOBILE Mobile Computing and Communications Review, vol. 11, no. 1, pp. 53–64, 2007.
[14] J. Sveˇcko, M. Malajner, and D. Gleich, “Distance estimation using rssi and parti-cle filter,” ISA transactions, vol. 55, pp. 275–285, 2015.
[15] L. Oliveira, H. Li, L. Almeida, and T. E. Abrudan, “Rssi-based relative localisation for mobile robots,” Ad Hoc Networks, vol. 13, pp. 321–335, 2014.
[16] X. Huang, M. Barralet, and D. Sharma, “Accuracy of location identification with antenna polarization on rssi,” in Proceedings of the International MultiConfer-ence of Engineers and Computer Scientists, vol. 1, Citeseer, 2009.
