
Lokaliseringsteknologier för en automatis-
erad tidrapporteringsapplikation.
Tillämpning av haversine formel, RSSI Distance Model och lämplighet för automa-
tion.

Examensarbete inom Data- och Informationsteknik

Erik Kieu

Dang Tuan Phong Nguyen

Institutionen för Data- och Informationsteknik

Chalmers Tekniska Högskola
Göteborgs Universitet
Göteborg, Sverige 2022

www.chalmers.se

www.chalmers.se


Examensarbete 2022

Lokaliseringsteknologier för en automatiserad tidrapporterings
applikation.

Tillämpning av Haversine formel, RSSI Distance Model och lämplighet för
automation.

Erik Kieu
Dang Tuan Phong Nguyen

Institutionen för Data- och Informationsteknik
Chalmers Tekniska Högskola

Göteborgs Universitet
Göteborg, Sverige 2022


Lokaliseringsteknologier för en automatiserad tidrapporterings applikation.
Tillämpning av Haversine formel, RSSI Distance Model och lämplighet för automation.
Erik Kieu
Dang Tuan Phong Nguyen

© Erik Kieu, 2022. © Dang Tuan Phong Nguyen, 2022.

Handledare: Jonas Almström Dureg̊ard, Institutionen för data- och information- steknik
Examinator: Lars Svensson, Institutionen för fysik
Företagshandledare: Dan Rozen, QBIS Business Systems

Examensarbete 2022
Institutionen för Data- och Informationsteknik
Chalmers Tekniska Högskola / Göteborgs Universitet
412 96 Göteborg
Telefon: 031-772 1000

Omslag: Skärmdump p̊a tillst̊anden in- och utstämplad i applikationen

Institutionen för Data- och Informationsteknik
Göteborg 2022

ii


Sammanfattning

Många företag hanterar idag tidrapporteringen manuellt vilket kan anses vara omodernt. QBIS är
ett tidrapporteringsföretag som vill hitta en innovativ lösning för att automatisera detta. Målet med
projektet är att tillsammans med QBIS skapa en mobilapplikation som hanterar olika uppgifter au-
tomatiskt med bland annat BLE, Wi-Fi och GPS. Syftet med rapporten är att avgöra vilken av dessa
tre teknologier är bäst och lämpligheten av automationsniv̊a för olika uppgifter.

Utifr̊an resultatet ans̊ags BLE fungera bäst vid korta distanser och GPS vid längre distanser. Automa-
tionen för tidrapporteringen anses vara översiktligt villkorligt automatiskt vilket ocks̊a är lämpligt för
mobilapplikationen.

Keywords: React-Native, BLE, Wi-Fi, GPS, Automation, Haversine, RSSI

iii


Abstract

Many companies today handle time reporting manually which can be considered outdated. The com-
pany QBIS which specializes in time reporting wants to find an inovative solution to automate this
chore. The goal of this project is to work together with QBIS inorder to create a mobileapplication
which can automate tasks related to time reporting with the technologies BLE, Wi-Fi, and GPS. The
purpose with this report is to determine which of these three technologies is the best and a suitable
level of automation to handle different tasks.

The results show that BLE is better at shorter distances and GPS is better at longer distances.
In general the automated tasks are considered to be conditionally automatic which is also suitable for
this application.

iv


Förord

Vi vill tacka till v̊aran handledare Jonas Dureg̊ard för hans hjälp och r̊adgivning under projektets
g̊ang. Samt v̊ara företagshandledare Dan Rozen som projektledare och Martin Augustsson för hans
expertis.

Erik Kieu & Dang Tuan Phong Nguyen, Göteborg, June 13, 2022

v


Ordlista

BLE Bluetooth Low Energy
GPS Global Positioning System
npm Node Package Manager
RSSI Received Signal Strength Indicator
dBm Decibel-milliwatts
MVP Minimum Viable Product

vi


Inneh̊allsförteckning

1 Inledning 1
1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Fr̊ageställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.5 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Teknisk bakgrund 2
2.1 Geografiska lokaliseringsteknologier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Mobilapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Metod 6
3.1 Testupplägg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Systemkonstruktion 8
4.1 Lokaliseringsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Automationslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Resultat 13
5.1 Uppmätningar p̊a Router, BLE och GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Jämförelse mellan BLE, GPS, Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Automatiserade handlingar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Diskussion 17
6.1 Metodkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 P̊alitligheten av positionering med BLE, Wi-Fi, GPS . . . . . . . . . . . . . . . . . . . . 17
6.3 Automation för handlingarna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Etik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Slutsats 19

Källor 20

A Källkod - Protokoll logik I

B Felmarginal för individuella resultat III

vii


1 Inledning

I denna sektion redogörs bakgrunden och syfte för rapporten. Här presenteras även
undersökningsomr̊adet och m̊alet med projektet.

1.1 Bakgrund

N̊agot som är problematiskt för m̊anga företag idag är hur tidrapportering hanteras där manuell
inmatning är en gemensam trend vilket kan vara tidskrävande och kr̊angligt. QBIS är ett av Sveriges
ledande företag inom tidrapportering och vill fortsätta förbättra hur rapporteringen hanteras i olika
företag genom att utveckla en mobilapplikation. Tanken med mobilapplikationen är att underlätta
tidrapportering genom att introducera automation för bland annat instämpling. Målgruppen som
QBIS riktar sig in p̊a är framförallt arbetsplatser med inomhusmiljöer.

1.2 Syfte

Syftet med projektet är att utreda noggrannheten av automatisk tidrapportering med hjälp av RSSI
och geografiska koordinater, samt undersöka lämpligheten av automationen.

1.3 Fr̊ageställning

Fr̊agor och undersökningar som kommer att behandlas är följande:

• Hur kommer rangordningen se ut för en optimal sökning av användarens position utifr̊an
teknologierna BLE, Wi-Fi och GPS?

• Vad är en lämplig grad av automation för mobilapplikationen utifr̊an uppgifterna:

– Inloggning

– Instämpling av arbetsplats

– G̊a p̊a rast

– Återuppta arbetspass

– Hantering av bytet mellan BLE, Wi-Fi och GPS

– Utstämpling av arbetsplats

1.4 Mål

Målet med projektet är att utveckla en MVP i form av en mobilapplikation för att besvara
fr̊ageställningarna. Applikationen ska ersätta manuell tidrapportering och istället använda sig av en
automatiserad lösning med hjälp av dem tekniska verktygen BLE, Wi-Fi och GPS.
Mobilapplikationen ska vara kompatibel med operativsystemen Android och iOS.

1.5 Avgränsningar

• Undersökningarna kommer inte utföras med mobiler av operativsystemet iOS.

• GPS testas inte till full utsträckning gentemot BLE och Wi-Fi.

1


2 Teknisk bakgrund

I denna sektion beskrivs den tekniska bakgrunden i tre delar som behandlar dem geografiska
lokaliseringsteknologierna, automationen och mobilapplikationen.

2.1 Geografiska lokaliseringsteknologier

Denna sektion beskriver de olika geografiska lokaliseringsteknologierna och ekvationer som använts
för att utreda fr̊ageställningen ”Hur kommer rangordningen se ut för en optimal sökning av
användarens position utifr̊an teknologierna BLE, Wi-Fi och GPS?”

BLE
BLE är en teknologi som kompletterar Classic Bluetooth radio som tillhandah̊aller tr̊adlös anslutning
mellan olika elektroniska enheter[1]. Till skillnad fr̊an Classic Bluetooth som är ensidig i
anlutningsmodellen eftersom data endast skickas till en användaren i taget. S̊a kan BLE utsända
information till flera användare samtidigt. Dessutom är energikonsumtionen lägre för BLE-enheter
jämfört med classic bluetooth. En stor anledning är överföringshastigheten som har sänkts för att
optimera energiförbrukningen[2].

Bluetooth beacon
BLE teknologin har utvidgas till större användningsomr̊aden inom positionering. Bluetooth beacon
är en enhet som kan annonsera data till andra enheter som har bluetooth aktiverade och befinner sig
inom räckvidd[3]. En bluetooth beacon har i genomsnitt en räckvidd upp till 100 meter och har en
p̊alitlig dataöverföring upp till 30 meter. Bluetooth beacon har som de flesta elektroniska h̊ardvaror
en MAC-adress för identifiering[4].

Wi-Fi
Wi-Fi teknologin är ett nätverks protokoll som ansluter tr̊adlöst kompatibla elektroniska-enheter till
ett nätverk. Wi-Fi fungerar i varierande frekvenser och har olika räckvidd beroende p̊a Wi-Fi
enhetens specifikationer. Wi-Fi är själva radiosignalen som skickas till en enhet vilket tolkar datan.
För anslutning skickas en radiosignal tillbaks med konfirmation om anslutningen[5].

Tr̊adlös router
Tr̊adlös router är h̊ardvara som är relativt vanlig i ett hush̊all. Användningsomr̊adet för tr̊adlösa
routrar är oftast för att koppla upp sig till sitt hush̊allsnätverk. En genomsnittlig räckvidd för en
router är 45 till 90 meter i inomhusmiljö[6][7].

GPS
GPS är ett satellitnavigeringssystem som används för positionering. Systemet använder tekniken
trilateration som med hjälp av flera satelliter kan bestämma en nogrann positionering.[8][9].

Avst̊ands uppskattning
Haversine-formeln är en ekvation som beräknar avst̊andet mellan tv̊a koordinater best̊aende av
latitud och longitud p̊a ett klot[10].

d = 2r sin−1

(√
sin 2

(
a1 − a2

2

)
+ cos (a2) cos (a1) sin 2

(
o1 − o2

2

))
(1)

där:

a1,2 är latitud koordinater för fr̊an och till

o1,2 är longitud koordinater för fr̊an och till

2


r är klotets radie (km)

d är avst̊andet mellan koordinaterna (km)

Genom att tillämpa formeln och med hjälp av grafteori har flera projekt även kunnat uppskatta den
kortaste vägen p̊a en kart-vy[10]. Grafteori används vanligen för att modellera relationer mellan
noder och kanter, där noderna och kanterna värderas beroende p̊a uppmätningen[11].

RSSI Distance Model är en metod för enheter som har egenskapen RSSI. Metoden används
framförallt för att uppskatta avst̊andet mellan tv̊a enheter, där signal styrkan relateras beroende p̊a
avst̊andet[12]. I en tidigare forskning[13] nämner skribenterna att formeln brister som indikator för
att uppskatta avst̊and. En viktig anledning till detta är just den instabila signalstyrkan.

RSSI = −10n log (d) +A (2)

d = 10(
A−RSSI

10n ) (3)

där:

A är den uppmätta signalstyrkan en meter mellan tv̊a enheter (dBm)

RSSI är den uppmätta signal styrkan mellan tv̊a enheter (dBm)

n är en konstant som varierar beroende p̊a hinder (fri yta uppskattas som 2)

d är avst̊andet mellan enheterna (m)

2.2 Automation

Många system är idag automatiserade och för att redogöra automationen kan en sammanställning av
automationsniv̊aer nyttjas som ett alternativ för en överblick av systemet. Exempelvis när man talar
om automation i självkörande bilar delas automationen in i olika niv̊aer fr̊an 0-5 som definierats
enligt The Society of Automotive Engineers[14]. Dessa niv̊aer sträcker sig fr̊an ingen automation
(niv̊a 0) till full automation (niv̊a 5). I tabell 2.1 presenteras en summerad beskrivning p̊a de olika
automationsniv̊aerna.

3


Automationsniv̊a Förklaring Subjekt för körande

Niv̊a 0 (Ingen automation) Föraren hanterar alla
operationer.

Förare

Niv̊a 1 (Förar assistans) Under särskilda
omständigheter kan systemet
delvis hantera handlingarna

bromsa, styra eller
acceleration.

Förare

Niv̊a 2 (Delvis Assistans) Under särskilda
omständigheter hanterar
systemet handlingarna

bromsa, styra och acceleration

Förare

Niv̊a 3 (Villkorlig automation) Under särskilda
omständigheter hanterar

systemet alla operationer och
föraren behöver endast ingripa

när system slutar fungera

Förare + System

Niv̊a 4 (Hög automation) Under särskilda
omständigheter hanterar
systemet alla operationer.

System

Niv̊a 5 (Full automation) Systemet hanterar alla
operationer villkorslöst.

System

Tabell 2.1: Automationsniv̊aerna för bilar

2.3 Mobilapplikation

Denna sektion beskriver de olika resurserna som använts för att utveckla en MVP i form av en
mobilapplikationen.

React Native
React Native är ett ramverk som används till att utveckla operativspecifika mobilapplikationer med
användargränssnitt för Android och iOS. Den är baserad p̊a Facebooks Javascript ramverk React.[15].

Node JS
Node JS är ett JavaScript-verktyg som används till att utveckla skalbara nätverks applikationer
genom att utg̊a fr̊an en event-driven och icke-blockerande modell[16].

npm
npm är en online-plattform där utvecklare kan dela och hämta ned paket best̊aende av kod som är
färdig för att användas i applikationer. Plattformen best̊ar av huvudsakligen tv̊a delar: en webbsida
för att hitta paket och ett kommandoradsverktyg som hanterar installationen av paketet[17].

Relevanta paket

4


Relevanta paket som används i mobilapplikationen är följande:

react-native-ble-plx : Detta paket till̊ater bland annat att applikationen f̊ar tillg̊ang till BLE-enheter
som upphittats av mobilen[18].

react-native-wifi-reborn: Detta paket till̊ater att applikationen f̊ar tillg̊ang till mobilens Wi-fi
information[19].

react-native-geolocation-service: Detta paket till̊ater att appliklationen f̊ar tillg̊ang till mobilens GPS
koordinater[20].

react-native-background-actions: Detta paket till̊ater att applikationen körs i bakgrunden[21].

react-native-async-storage: Detta paket möjliggör lokal lagring av information[22].

5


3 Metod

Denna sektion beskriver om vilka h̊ardvaror som nyttjades för projektet och hur testerna utfördes för
att besvara fr̊ageställningarna.

3.1 Testupplägg

Vid utföranden av testerna användes RadBeacon Dot som är en bluetooth beacon, Belkin Wireless
N300 Router som är en router, Samsung Galaxy S10 för att använda mobilapplikationen och One
Plus 5 för att jämföra uppmätningar av RadBeacon Dot. För observering och notering av
undersökningarna användes konsolen i programmeringsmiljön Visual Studio Code.

Max-distans utan hinder
Uppmätningar av RSSI undersöktes i en utomhusmiljö fr̊an en utg̊angspunkt där bluetooth-enheten
och routern placerades. D̊a ingen signal mellan enheterna och mobil-enheten kunde upptäcktas
mättes avst̊andet fysiskt fr̊an utg̊angspunkten och positionen p̊a mobil-enheten.

Max-distans med hinder
Uppmätningar av RSSI undersöktes i en inomhusmiljö fr̊an en utg̊angspunkt där bluetooth-enheten
och routern placerades. För att representera hinder nyttjades ett flertal rum med gipsväggar. Varje
hinder var dubbla gipsväggar som estimerades till 1cm i bredd och 13cm i mellanrum. Avst̊andet fr̊an
utg̊angspunkten mättes fysiskt d̊a ingen signal mellan enheterna och mobil-enheten kunde upptäckas.

Träffsäkerhet
Under testerna mättes fem olika stäckor fr̊an en utg̊angspunkt där bluetooth-enheten och routern
placerades. Mobilenheten placerades p̊a de fem avst̊anden för att f̊anga upp RSSI-signalerna för
respektive enhet och koordinaterna. Uppmätningarna observerades i flera iterationer för att f̊a
genomsnittliga värden som gynnade avst̊andsuppskattningen när Haversine och RSSI Distance Model
tillämpades.

3.2 Automation

För att undersöka automationen av applikationen anpassades teorin om automationsniv̊aerna enligt
The Society of Automotive Engineer till en mobilapplikation. Automationen av flera handlingar
observerades enligt den modifierade tabellen 3.1. Detta skedde i en kontrollerad miljö där
mobilapplikationen hade tillg̊ang till platstjänster och kunde bearbetas i förgrunden s̊aväl som i
bakgrunden.

6


Automations-niv̊a Förklaring Subjekt för applikations
användning

Niv̊a 0 (Ingen automation) Användaren hanterar alla
handlingar.

Användare

Niv̊a 1 (Användar assistans) Under särskilda
omständigheter kan systemet
delvis hantera handlingarna
med hjälp av användarens

inmatning.

Användare

Niv̊a 2 (Villkorlig automation) Under särskilda
omständigheter hanterar

systemet alla handlingar och
användaren behöver endast
ingripa när system slutar

fungera

Användare + System

Niv̊a 3 (Full automation) Systemet hanterar alla
handlingar villkorslöst.

System

Tabell 3.1: Automationsniv̊aerna för mobilapplikationen.

7


4 Systemkonstruktion

Denna sektion beskriver hur logiken för teknologierna BLE, Wi-Fi och GPS implementerades. För en
detaljerad källkod av teknologierna hänvisas till appendix A. Sektionen behandlar även
implementationen för de situationer som kan uppst̊a för användaren i mobilapplikationen.

4.1 Lokaliseringsprotokoll

Implementeringen p̊a de olika protokollen är konstruerad s̊a att varje protokoll itererar s̊a länge
mobilapplikationen är inom räckh̊all för respektive protokoll. Vid fallen d̊a mobilapplikationen inte är
inom räckh̊all avbryts iterationen för protokollet.

BLE-protokoll
För logiken bakom BLE-protokollet används BleManager fr̊an paketet react-native-ble-plx.
BleManager har som uppgift att söka BLE-enheter i närheten av mobil-enheten som är i bruk. De
uppgifter fr̊an BLE-enheten som nyttjas är RSSI-signalen och MAC-addressen för att upptäcka
matchande BLE-enhet.

I figur 4.1 används T som en tidsgräns p̊a protokollet, Arr är en lista best̊aende av giltiga
BLE-enheter för användaren och D är en lista best̊aende av sökta BLE-enheter. Ifall listorna har
åtminstone en matchande enhet (contains) innan T sätts X till true, vilket indikerar att
BLE-enheten är i närheten (resolve).

8


 BLE list: Arr[{deviceID}, ...]

 Timer: T

 Interval: I

 In proximity: X = false

 Index: N = 0 

 BLE scanner: S


True

False
D.contains(Arr[N].deviceID)

N = N + 1

Exit

Start T
deviceList: D = S.scan()

T >= I

AND


N < Arr.length

False

TimeLeft = I - T

X = true


Resolve({X, TimeLeft})
Resolve({X})

True

Figur 4.1: Flödesschema för BLE-protokoll.

Wi-Fi protokoll
Wi-Fi protokollet använder WifiManager fr̊an paketet react-native-wifi-reborn. WifiManager
hanterar mobilens Wi-Fi konfigurationer och förser mobilapplikationen med namnet samt RSSI för
Wi-Fi enheten som mobil-enheten är ansluten till.

Figur 4.2 illustruerar flödesschemat p̊a Wi-Fi protokollet där P är den anslutna Wi-Fi enheten och
Arr en lista p̊a giltiga Wi-Fi enheterna för användaren. Ifall Arr inneh̊aller namnet p̊a Wi-Fi
enheten (contains) P innan tidsgränsen T har utg̊att s̊a tilldelas X till true, vilket indikerar att
Wi-Fi enheten är i närheten (resolve).

9


 Wifi list: Arr[{deviceID}, ...]

 Timer: T

 Interval: I

 User wifi: P
 In proximity: X = false

True

False

Arr.contains(P)

AND

T < I

Exit

Start T

TimeLeft = I - T

X = true


Resolve({X, TimeLeft})

Resolve({X})

Figur 4.2: Flödesschema för Wi-Fi protokoll.

GPS-protokoll
Geolocation fr̊an paketet react-native-geolocation-service används för att uppskatta koordinaterna för
mobil-enheten som är i bruk.

I Figur 4.3 används Haversine med användarens koordinater P och koordinater för varje GPS-objekt
Arr[N] i GPS-listan Arr. Varje GPS-objekt har även ett max-avst̊and som användaren f̊ar vara ifr̊an.
Ifall avst̊andet mellan användaren och åtminstone ett utav GPS-koordinaterna i Arr[N] är mindre än
max-avst̊andet samt tidsgränsen T inte har utg̊att, d̊a kommer X tilldelas till true, vilket indikerar
att mobilapplikationen är i närheten (resolve).

10


 GPS list: Arr[{maxDistance, position}, ...]

 Timer: T

 Interval: I

 User position: P

 In proximity: X = false

 Index: N = 0

True

FalseHaversine(P,
Arr[N].position) <

Arr[N].maxDistance

N = N + 1

Exit

Start T

T >= I

False

TimeLeft = I - T

X = true


Resolve({X, TimeLeft})
Resolve({X})

True

Figur 4.3: Flödesschema för GPS protokoll.

4.2 Automationslogik

Inloggningssystemet fungerar genom att manuellt mata in användarnamnet samt lösenordet för en
användare. Användaren har även möjlighet att h̊alla sig inloggad och spara användarinformationen
med session, som sparas lokalt i användarens mobil med paketet react-native-async-storage.

När användaren navigerar i mobilapplikationen till huvudsidan aktiveras instämplingsprocessen. Ifall
n̊agot av protokollen lyckas lokalisera åtminstone en av enheterna som är giltiga för användaren
initieras en bakgrundsuppgift för instämpling. Bakgrundsuppgiften implementerades med paketet
react-native-background-actions. Användaren har även möjlighet att stämpla in manuellt ifall
protokollen misslyckas med lokaliseringen.

Antalet protokoll som ska köras i bakgrundsuppgiften bestäms ifall det finns giltiga enheter eller
koordinater för användaren och tilldelas som första, andra och tredje protokoll. Varje protokoll körs
inom ett intervall och repeteras ifall användaren fortfarande befinner sig inom räckh̊all. När första
protokollet misslyckas överg̊ar mobilapplikationen till nästa protokoll.

När det sista protokollet misslyckas stämplas användaren slutligen ut oberoende av ifall
mobilapplikationen är i förgrunden eller bakgrunden. Under hela bakgrundsuppgiften har
användaren även möjlighet att avbryta instämplingen med en utstämplingsknapp.

11


Under instämplingen kan användaren p̊abörja sin rast genom att använda rastknappen och ställa in
en tidsgräns för rasten. Efter att tidsgränsen har utg̊att återupptar användaren sitt arbetspass.

12


5 Resultat

I denna del introduceras resultat p̊a testerna och dess genomsnittliga värden p̊a de olika protokollen
som har tillämpats samt automationsniv̊aerna för varje handling i mobilapplikationen.

5.1 Uppmätningar p̊a Router, BLE och GPS

De uppmätta RSSI för BLE och Wi-Fi protokollen presenteras i figur 5.1, och 5.2. I Tabell 5.1, 5.2
och 5.3 presenteras den genomsnittliga RSSI eller GPS koordinater över 24 samplingar för respektive
protokoll.

0 10 20 30 40 50 60 70 80 90 100 110 120

−40
−45
−50
−55
−60
−65
−70
−75
−80
−85
−90

Sekunder

d
B
m

1m avst̊and
3m avst̊and
5m avst̊and
10m avst̊and
20m avst̊and

Figur 5.1: RSSI-uppmätningar för BLE-beacon.

1m fr̊an
utg̊angspunkt

3m fr̊an
utg̊angspunkt

5m fr̊an
utg̊angspunkt

10m fr̊an
utg̊angspunkt

20m fr̊an
utg̊angspunkt

-53.625 -62.375 -69.125 -77.292 -81.542

Tabell 5.1: Genomsnittlig RSSI för BLE-beacon.

13


0 10 20 30 40 50 60 70 80 90 100 110 120

−30

−35

−40

−45

−50

−55

−60

−65

−70

−75

Sekunder

d
B
m

1m avst̊and
3m avst̊and
5m avst̊and
10m avst̊and
20m avst̊and

Figur 5.2: RSSI-uppmätningar för Wi-Fi router.

1m fr̊an
utg̊angspunkt

3m fr̊an
utg̊angspunkt

5m fr̊an
utg̊angspunkt

10m fr̊an
utg̊angspunkt

20m fr̊an
utg̊angspunkt

-37.625 -49.417 -55.917 -59.875 -66.792

Tabell 5.2: Genomsnittlig RSSI för Wi-Fi router.

Latitud Longitud

0m fr̊an utg̊angspunkt 57.7061534751 11.9386697511

3m fr̊an utg̊angspunkt 57.7061553667 11.9386145833

5m fr̊an utg̊angspunkt 57.7061629167 11.9386056125

10m fr̊an utg̊angspunkt 57.7062042083 11.9385361962

20m fr̊an utg̊angspunkt 57.7063625917 11.9385756625

Tabell 5.3: Genomsnittliga GPS koordinater.

14


5.2 Jämförelse mellan BLE, GPS, Wi-Fi

Rangordningen för varje undersökning är baserad p̊a färgkodningen där orange är första plats, röd är
andra plats och gr̊a p̊a tredje plats. I Tabell 5.4 presenteras de maximala räckvidden med och utan
hinder för Wi-Fi, BLE och GPS. I Tabell 5.5 presenteras resultaten efter Haversine och RSSI
Distance Model tillämpningarna. Även fel marginalerna i procent för de olika avst̊anden och
protokollen, se appendix B över felmarginal för individuella resultat.

Wi-Fi router BLE-beacon GPS

Max-avst̊and utan
hinder (utomhus)

49.9m 42.3m Ingen gräns1

Max-avst̊and med
gipshinder (6 dubbel

gipsväggar)

30.5m 26m Ingen gräns1

Tabell 5.4: Max-avst̊and med och utan hinder.

Wi-Fi router BLE-beacon GPS

Uppskattad avst̊and
(3m)

3.89m (+29.7%) 2.74m (-8.7%) 3.28m (+9.3%)

Uppskattad avst̊and
(5m)

8.22m (+64.4%) 5.96m (+19.2%) 3.95m (-21.0%)

Uppskattad avst̊and
(10m)

12.96m (+29.6%) 15.25m (+52.5%) 9.74m (-2.6%)

Uppskattad avst̊and
(20m)

28.72m (+43.6%) 24.87m (+24.4%) 23.92m (+19.6%)

Tabell 5.5: Genomsnittliga avst̊andsberäkningar

1Ingen räckviddsgräns vid bra GPS-signaler fr̊an GPS-satelliter.

15


5.3 Automatiserade handlingar

I denna sektion presenteras det uppn̊adda resultatet av automationen i form av text och tabell.

Inloggning
Användaren har möjlighet till att h̊alla sig inloggad efter första interaktionen.

Instämpling av arbetsplats
Åtminstone ett av protokollen behöver vara tillgänglig samtidigt som användaren är inom omr̊adet
för automatisk instämpling. Annars krävs manuell inmatning fr̊an användaren.

G̊a p̊a rast
Användaren har möjlighet att g̊a p̊a rast vid manuell inmatning.

Återuppta arbetspass
Användaren återupptar sitt arbetspass fr̊an automations-uppgiften ”G̊a p̊a rast” efter en tidsgräns.
Användaren har även möjlighet att återuppta arbetet med en manuell inmatning.

Hantering av bytet mellan BLE, Wi-Fi och GPS
Bytet av teknologierna sker automatiskt enligt prioriteringen d̊a ett protokoll misslyckas.

Utstämpling
Användaren stämplas ut automatiskt ifall det sista prioriterade protokollet misslyckas med att f̊anga
upp användarens position. Användaren har även möjlighet till att stämpla ut med en manuell
inmatning.

Handling Automationsniv̊a

Inloggning 2

Instämpling av arbetsplats 2

G̊a p̊a rast 0

Återuppta arbetspass 3

Hantering av bytet mellan BLE, Wi-Fi och GPS 3

Utstämpling av arbetsplats 3

Tabell 5.6: En samling av handlingar som testas utifr̊an automationsniv̊a.

16


6 Diskussion

I denna sektion diskuteras fr̊ageställningarna med hjälp av resultaten och komplikationer som
uppstod i detta projekt.

6.1 Metodkritik

Undersökningarna utreddes framförallt med fysiska Android-enheter och det vore lämpligt att även
undersöka med iOS-enheter för att jämföra resultatet.

För en optimal undersökning p̊a max-avst̊andet med och utan hinder vore att det lämpligt att
utförandet av testerna sker i samma miljö. Anledning är att denna utredning utfördes inomhus för
max-avst̊and med hinder och max-avst̊and utan hinder utomhus p̊a grund av lokalbrist.

Överlag används React Native paketen fr̊an npm för att underlätta utveckling, för att inte behöva
återskapa inneh̊allet av paketen. Däremot blir mobilapplikationen beroende av paketen och det kan
förekomma komplikationer om de inte underh̊alls för framtida mobil-enheter.

I tidigare forskning nämns det att RSSI är ett d̊aligt sätt att mäta avst̊and d̊a reflektion, spridning
och fysiska egenskaper har en stor p̊averkan. Det innebär att p̊alitligheten av avst̊andsberäkningarna
är bristande.

6.2 P̊alitligheten av positionering med BLE, Wi-Fi, GPS

För positionering av GPS ans̊ags endast träffsäkerheten vid olika avst̊and vara av intresse.
Anledningen till det är att GPS positionering kan ske globalt och avst̊andet har inga restriktioner för
v̊ara undersökningar. Därmed fastställdes resultatet för GPS i tabell 5.4 till ”Ingen gräns”.

En stor faktor som p̊averkar utredningen p̊a max-avst̊andet av BLE-protokollet är intervallet mellan
sökningar. För att hitta en BLE-enhet har BLE-protokollet en tidsgräns innan det g̊ar över till ett
annat protokoll. Detta kan ge komplikationer vid korta intervaller eftersom sökningen av en enhet
kräver längre tid ju större avst̊andet är mellan BLE- och mobil-enheten. Därmed p̊averkas även
avst̊andsmätningen i resultatet.

Observationerna fr̊an tabell 5.4 visar att signalerna blir lägre med hinder. Därav vid användning av
RSSI Distance Model m̊aste konstanten n fr̊an formlerna (3) och (2) justeras för att överensstämmas
med det faktiska avst̊andet och RSSI-signalen.

Utifr̊an resultatet i tabell 5.5 fluktuerar felmarginalen drastiskt över de olika protokoll avst̊anden,
framförallt Wi-Fi routern och BLE-beacon. Detta kan bero p̊a att RSSI värdena som returneras är
strikt heltal. Ifall beräkningen fr̊an resultatet i tabell 5.1 hade beräknats med tre decimaler där A är
-53.625 och RSSI är -62.375. S̊a hade det genomsnittliga avst̊andet varit 2.738419634 istället för 4.
Allts̊a hade ett RSSI värde i decimaltal resulterat i ett mer exakt värde. Utöver detta kan
signalstyrkan även bero p̊a h̊ardvarans kvalité.

6.3 Automation för handlingarna

Mobilapplikationen är ett fleranvändarsystem och kräver identifiering av användaren för att särskilja
sig ifr̊an andra användare, allts̊a krävs åtminstone en första interaktion för inloggningen. Följaktligen
anses automationsniv̊an 2 vara lämplig.

För instämpling bestämdes och ans̊ags automationsniv̊an 2 vara lämplig. I scenariot d̊a

17


mobilapplikationen är i bakgrunden m̊aste användaren starta ig̊ang mobilapplikationen för att
initiera instämplingsprocessen. Om handlingen hade varit helt automatiserat, skulle det ge
komplikationer för scenariot om användaren är inom omr̊adet och inte är schemalagd att vara
instämplad under den tiden.

För uppgiften ”G̊a p̊a rast” uppn̊addes automationsniv̊an 0, men det vore lämpligt att f̊a den
uppmot automationsniv̊a 3. Anledningen till att lämpligheten är uppmot 3 är för att reducera
interaktionen med mobilapplikationen s̊a fort användaren ska g̊a p̊a rast. En lösning som
diskuterades var att kunna hantera schemalagda tider för användaren och inkludera rasttiden s̊a
mobilapplikationen hamnar i rastläge.

För b̊ada uppgifterna ”Återuppta arbetspass” och ”Hantering av bytet mellan BLE, Wi-Fi och GPS”
uppn̊addes automationsniv̊an 3, vilket anses vara lämpligt. Eftersom det minimerar interaktionen
med mobilapplikationen och ytterligare hantering anses inte vara nödvändigt.

Automationsniv̊an för uppgiften ”Utstämpling av arbetsplats” uppn̊addes till automationsniv̊a 3
vilket ocks̊a ans̊ags vara lämpligast. Ett scenario som kan ge komplikationer med tidrapporteringen
är ifall användaren fortfarande befinner sig inom omr̊adet trots att arbetspasset är över. Även i detta
fall diskuterades en lösning där mobilapplikationen hanterar schemalagda tider för användaren som
inkluderar utstämpling efter en viss tid.

6.4 Etik

Enligt dataskyddsförordningen[23] m̊aste hanteringen av persondata upph̊allas. Vid inloggning
hämtar mobilapplikationen persondata s̊asom förnamn och efternamn hos användaren fr̊an QBIS
webbtjänster. Persondatan används bara när användaren är inloggad i mobilapplikationen och
raderas sedan vid utloggning.

En annan viktig aspekt att ha i åtanke är övervakningsaspekten av mobilapplikationen där
användarens platsdata uppenbaras. Detta bör ocks̊a ha dataskyddsförordningen[24] i åtanke hur
platsdatan används. Platsdatan för applikationen används i kombination med protokollen och
bestämmer ifall användaren är inom omr̊adet för att vara instämplad. Själva platsdatan sparas inte
utan bara ankomst- och avg̊angstid. För användning av mobilapplikationen uppmanas användaren
att till̊ata platstjänster.

18


7 Slutsats

Enligt resultatet är bluetooth protokollet bäst vid distanser upp till 5m för träffsäkerheten. Däremot
vid distanser över 5m konstaterades GPS protokollet som mest lämplig. I jämförelse mellan Wi-Fi
och bluetooth anses Wi-Fi som ett bättre alternativ när det gäller max-avst̊and däremot försämras
träffsäkerheten. Sammanfattningsvis bör protokollen följa prioriteringen GPS, bluetooth och sedan
Wi-Fi. Däremot begränsas p̊alitligheten till resultatet p̊a grund av att RSSI är ett d̊aligt sätt att
uppskatta avst̊and. Därmed bör framtida undersökningar med liknande m̊al ha uppsikt över denna
metod.

Utav automationsuppgifterna som mättes ans̊ags fem av sex vara lämpliga enligt resultatet där
uppgiften ”G̊a p̊a rast” bör vara p̊a automationsniv̊a 3 istället för 0. Handlingarna i
mobilapplikationen anses därför vara översiktligt villkorlig automatisk (automationsniv̊a 2).

19


Källor

[1] Bluetooth. “Bluetooth tecnology overview.” (2022), [Online]. Available: https://www.bluetooth.
com/learn-about-bluetooth/tech-overview/ (visited on 02/14/2022).

[2] R. Heydon, Bluetooth Low Energy, The Developer’s Handbook. New Jersey NJ, USA: Pearson
Education, 2013.

[3] J. Lindh, “Bluetooth low energy beacons,” Texas TX, USA, Tech. Rep., 2016.

[4] Mapsted. “What you must know about bluetooth beacons before purchasing.” (2022), [Online].
Available: https://mapsted.com/blog/what-you-must-know-about-bluetooth-beacons-
before-purchasing (visited on 02/05/2022).

[5] Cisco. “What is wi-fi.” (2022), [Online]. Available: https : / / www . cisco . com / c / en / us /
products/wireless/what-is-wifi.html (visited on 02/14/2022).

[6] Verizon. “What is wi-fi.” (2022), [Online]. Available: https : / / www . verizon . com / info /

definitions/wifi/ (visited on 02/14/2022).

[7] S. Dhawan, “Analogy of promising wireless technologies on different frequencies: Bluetooth, wifi,
and wimax,” in The 2nd International Conference on Wireless Broadband and Ultra Wideband
Communications (AusWireless 2007), 2007, pp. 14–14.

[8] Geotab. “What is gps?” (2020), [Online]. Available: https://www.geotab.com/blog/what-is-
gps/ (visited on 03/07/2022).

[9] B. T. Fang, “Trilateration and extension to global positioning system navigation,” J. Guidance,
vol. 9, no. 6, p. 715, 2012.

[10] N. R.Chopde and M. K. Nichat, “Trilateration and extension to global positioning system nav-
igation,” International Journal of Innovative Research in Computer and Communication Engi-
neering, vol. 1, no. 2, pp. 298–302, 2013.

[11] K. Eriksson and H. Gavel, “Grafer,” in Diskret matematik och diskreta modeller, 2:6, Lund, SE:
Studentlitteratur AB, 2018.

[12] G. Li, E. Geng, Z. Ye, Y. Xu, J. Lin, and Y. Pang, “Indoor positioning algorithm based on the
improved rssi distance model,” Sensors, vol. 18, no. 2820, pp. 1–6, 2018.

[13] K. Benkic, M. Malajner, P. Planinsic, and Z. Cucej, “Using rssi value for distance estimation in
wireless sensor networks based on zigbee,” in 2008 15th International Conference on Systems,
Signals and Image Processing, 2008, pp. 303–306.

[14] S. Yoo and S. Managi, “To fully automate or not? investigating demands and willingness to pay
for autonomous vehicles based on automation levels,” IATSS Research, vol. 45, no. 4, pp. 459–
468, 2021.

[15] Geotab. “React native learn once write anywhere.” (2020), [Online]. Available: https://reactnative.
dev/ (visited on 03/08/2022).

[16] OpenJS. “About node.js.” (2022), [Online]. Available: https://nodejs.org/en/about/ (visited
on 02/14/2022).

[17] npm. “About npm.” (2022), [Online]. Available: https://www.npmjs.com/about (visited on
02/14/2022).

[18] P. Lenart and et al. “React native ble plx.” (2022), [Online]. Available: https://dotintent.
github.io/react-native-ble-plx/ (visited on 02/14/2022).

[19] J. S. D. Cubides and et al. “React-native-wifi-reborn.” (2022), [Online]. Available: https://
github.com/JuanSeBestia/react-native-wifi-reborn (visited on 02/14/2022).

[20] I. Rifat and et al. “React-native-geolocation-service.” (2022), [Online]. Available: https://
github.com/Agontuk/react-native-geolocation-service (visited on 02/14/2022).

20

https://www.bluetooth.com/learn-about-bluetooth/tech-overview/
https://www.bluetooth.com/learn-about-bluetooth/tech-overview/
https://mapsted.com/blog/what-you-must-know-about-bluetooth-beacons-before-purchasing
https://mapsted.com/blog/what-you-must-know-about-bluetooth-beacons-before-purchasing
https://www.cisco.com/c/en/us/products/wireless/what-is-wifi.html
https://www.cisco.com/c/en/us/products/wireless/what-is-wifi.html
https://www.verizon.com/info/definitions/wifi/
https://www.verizon.com/info/definitions/wifi/
https://www.geotab.com/blog/what-is-gps/
https://www.geotab.com/blog/what-is-gps/
https://reactnative.dev/
https://reactnative.dev/
https://nodejs.org/en/about/
https://www.npmjs.com/about
https://dotintent.github.io/react-native-ble-plx/
https://dotintent.github.io/react-native-ble-plx/
https://github.com/JuanSeBestia/react-native-wifi-reborn
https://github.com/JuanSeBestia/react-native-wifi-reborn
https://github.com/Agontuk/react-native-geolocation-service
https://github.com/Agontuk/react-native-geolocation-service


[21] R. martin and et al. “React native background service.” (2022), [Online]. Available: https:
//github.com/Rapsssito/react-native-background-actions (visited on 02/14/2022).

[22] K. Borowy and et al. “React native async storage.” (2022), [Online]. Available: https://github.
com/react-native-async-storage/async-storagen (visited on 02/14/2022).

[23] Integritetsskyddsmyndigheten. “Personuppgifter.” (2021), [Online]. Available: https://mapsted.
com/blog/what-you-must-know-about-bluetooth-beacons-before-purchasing (visited on
05/10/2022).

[24] ——, “Ställ in hur din mobil använder platsdata.” (2021), [Online]. Available: https://www.
imy.se/privatperson/dataskydd/informationssakerhet/stall- in- hur- din- mobil-

anvander-platsdata/ (visited on 05/10/2022).

21

https://github.com/Rapsssito/react-native-background-actions
https://github.com/Rapsssito/react-native-background-actions
https://github.com/react-native-async-storage/async-storagen
https://github.com/react-native-async-storage/async-storagen
https://mapsted.com/blog/what-you-must-know-about-bluetooth-beacons-before-purchasing
https://mapsted.com/blog/what-you-must-know-about-bluetooth-beacons-before-purchasing
https://www.imy.se/privatperson/dataskydd/informationssakerhet/stall-in-hur-din-mobil-anvander-platsdata/
https://www.imy.se/privatperson/dataskydd/informationssakerhet/stall-in-hur-din-mobil-anvander-platsdata/
https://www.imy.se/privatperson/dataskydd/informationssakerhet/stall-in-hur-din-mobil-anvander-platsdata/


A Källkod - Protokoll logik

export const isConnectedToCompanyBLE = async (BLEList) => {

return new Promise((resolve, reject) => {

var start = moment().utc(true)

protocolIntervalTimer = setTimeout(async () => {

bleManager.stopDeviceScan();

resolve({ isConnected: false })

}, actionInterval)

bleManager.startDeviceScan(null, null, (error, device) => {

bleManager.state().then((res) => {

if (res == 'PoweredOn') {

if (error) {

bleManager.stopDeviceScan();

console.log(error)

resolve({ isConnected: false })

}

var isFound = BLEList.find((res) => res.id == device.id)

if (isFound) {

var end = moment().utc(true)

var timeLeft = actionInterval - end.diff(start)

console.log(`Found company device:${device.id}`);

isConnected = true;

bleManager.stopDeviceScan();

resolve({

isConnected: true,

location: isFound.location,

timeLeft: timeLeft})

}

}

else {

resolve({ isConnected: false })

}

})

});

})

}

export const isConnectedToCompanyWifi = async (WifiList) => {

return new Promise((resolve, reject) => {

var start = moment().utc(true)

protocolIntervalTimer = setTimeout(() => {

resolve({ isConnected: false });

}, actionInterval)

WifiManager.getCurrentWifiSSID().then(async (ssid) => {

var isFound = WifiList.find((res) => res.id === ssid);

if (isFound) {

var end = moment().utc(true)

var timeLeft = actionInterval - end.diff(start)

console.log(`Connected to company Wifi${ssid}`)

resolve({

isConnected: true,

I


location: isFound.location,

timeLeft: timeLeft });

}

resolve({ isConnected: false });

},

(error) => {

resolve({ isConnected: false });

}

);

})

}

export const inProximityToCompanyGPS = async (GPSList) => {

return new Promise((resolve, reject) => {

var start = moment().utc(true)

protocolIntervalTimer = setTimeout(() => {

resolve({ isConnected: false });

}, actionInterval)

Geolocation.getCurrentPosition(

(position) => {

var currentLatPosition = position.coords.latitude;

var currentLongPosition = position.coords.longitude;

console.log(`Lat: ${currentLatPosition} Long: ${currentLongPosition}`)

GPSList.forEach((companyLocation) => {

var companyLatPosition = companyLocation.Lat;

var compantLongPosition = companyLocation.Long;

var maxDistance = companyLocation.distance;

var distance = haversineToMeter(currentLatPosition,

currentLongPosition,

companyLatPosition,

compantLongPosition);

console.log(`distance:${distance} maxDistance:${maxDistance}`);

if (distance < maxDistance) {

var end = moment().utc(true)

var timeLeft = actionInterval - end.diff(start)

resolve({

isConnected: true,

location: companyLocation.location,

timeLeft: timeLeft});

}

})

resolve({ isConnected: false });

}, (error) => {

reject(false);

}, { enableHighAccuracy: true, timeout: 15000, maximumAge: 10000 }

);

})

}

II


B Felmarginal för individuella resultat

Figurerna visar felmarginaler där noll är utg̊angspunkten fr̊an de olika avst̊anden. En punkt ovanför
utg̊angspunkten innebär en överskattning av avst̊andet medan en punkt under utg̊angspunkten innebär
en underskattning av avst̊andet.

0 10 20 30 40 50 60 70 80 90 100 110 120
−3

−2

−1

0

1

2

3

4

5

6

7

8

Sekunder

M
et
er

Figur B.1: Felmarginal efter avst̊andsberäkning för BLE-beacon fr̊an 3 meters avst̊and.

0 10 20 30 40 50 60 70 80 90 100 110 120
−2

−1

0

1

2

3

4

5

6

7

8

9

10

Sekunder

M
et
er

Figur B.2: Felmarginal efter avst̊andsberäkning för BLE-beacon fr̊an 5 meters avst̊and.

III


0 10 20 30 40 50 60 70 80 90 100 110 120
−2

0

2

4

6

8

10

12

14

16

18

20

22

24

Sekunder

M
et
er

Figur B.3: Felmarginal efter avst̊andsberäkning för BLE-beacon fr̊an 10 meters avst̊and.

0 10 20 30 40 50 60 70 80 90 100 110 120
−10

−5

0

5

10

15

20

25

30

35

40

45

50

55

Sekunder

M
et
er

Figur B.4: Felmarginal efter avst̊andsberäkning för BLE-beacon fr̊an 20 meters avst̊and.

IV


0 10 20 30 40 50 60 70 80 90 100 110 120
−1

0

1

2

3

4

5

6

7

8

Sekunder

M
et
er

Figur B.5: Felmarginal efter avst̊andsberäkning för Wi-Fi router fr̊an 3 meters avst̊and.

V


0 10 20 30 40 50 60 70 80 90 100 110 120
−1

0

1

2

3

4

5

6

7

8

9

10

11

Sekunder

M
et
er

Figur B.6: Felmarginal efter avst̊andsberäkning för Wi-Fi router fr̊an 5 meters avst̊and.

0 10 20 30 40 50 60 70 80 90 100 110 120
−6

−4

−2

0

2

4

6

8

10

12

14

16

18

20

Sekunder

M
et
er

Figur B.7: Felmarginal efter avst̊andsberäkning för Wi-Fi router fr̊an 10 meters avst̊and.

VI


0 10 20 30 40 50 60 70 80 90 100 110 120
−2

0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

Sekunder

M
et
er

Figur B.8: Felmarginal efter avst̊andsberäkning för Wi-Fi router fr̊an 20 meters avst̊and.

VII


0 10 20 30 40 50 60 70 80 90 100 110 120
−2

−1

0

1

2

3

4

5

Sekunder

M
et
er

Figur B.9: Felmarginal efter avst̊andsberäkning för GPS fr̊an 3 meters avst̊and.

0 10 20 30 40 50 60 70 80 90 100 110 120
−4

−3

−2

−1

0

1

2

3

4

Sekunder

M
et
er

Figur B.10: Felmarginal efter avst̊andsberäkning för GPS fr̊an 5 meters avst̊and.

VIII


0 10 20 30 40 50 60 70 80 90 100 110 120
−7

−6

−5

−4

−3

−2

−1

0

1

2

3

4

5

6

7

8

Sekunder

M
et
er

Figur B.11: Felmarginal efter avst̊andsberäkning för GPS fr̊an 10 meters avst̊and.

0 10 20 30 40 50 60 70 80 90 100 110 120
−7

−6

−5

−4

−3

−2

−1
0

1

2

3

4

5

6

7

8

9

Sekunder

M
et
er

Figur B.12: Felmarginal efter avst̊andsberäkning för GPS fr̊an 20 meters avst̊and.

IX


Institutionen för Data- och Informationsteknik

Chalmers Tekniska Hogskola

Göteborg, Sverige

www.chalmers.se

www.chalmers.se

	Inledning
	Bakgrund
	Syfte
	Frågeställning
	Mål
	Avgränsningar

	Teknisk bakgrund
	Geografiska lokaliseringsteknologier
	Automation
	Mobilapplikation

	Metod
	Testupplägg
	Automation

	Systemkonstruktion
	Lokaliseringsprotokoll
	Automationslogik

	Resultat
	Uppmätningar på Router, BLE och GPS
	Jämförelse mellan BLE, GPS, Wi-Fi
	Automatiserade handlingar

	Diskussion
	Metodkritik
	Pålitligheten av positionering med BLE, Wi-Fi, GPS
	Automation för handlingarna
	Etik

	Slutsats
	Källor
	Källkod - Protokoll logik
	Felmarginal för individuella resultat