IELS: Indoor Equipment Localization System: Conclusion (Part 6/6 final) (IoT)


We conclude there is a gap between a few of the mentioned research papers  and the commercial products. Most  researches are missing the practical usage of iBeacons and focus primarily on specific problems. However, all commercial solutions does not offer  free-of-cost solutions. We think there is a place for Open Source standard software for indoor localizing System. We therefore aim to focus on practical usage of iBeacons based on Indoor Localization System and in short term share our  knowledge from  this thesis with  potential contributors. We would like to continue working on this project and improve it.  All this we aim  to release it at some point as an Open Source Indoor Localization System standard software and make it possible to use  the  system as crowdsensing. That means people who  has  smartphones with the proper application and thereby be able to collect the location of the smartphone and as well as trackable objects location information periodically. This  should be send to a centralized backend infrastructure based on  end-user behavior and requirement.

The work from Bulten [1], Radboud University in Holland has been a major inspiration for our  thesis. Bulten focuses on practical usage of the iBeacons and has already released source code based on JavaScript.

We think the combination of iBeacons’ price together with long  life battery and easy-to-deploy makes it a perfect choice to use for indoor localization purpose.

Another aspect for future research would be the improvement of the algorithm’s efficiency, and overall improvement of the system as mentioned in discussion.

Finally, it should be concluded that the  environment surrounding iBeacons and smartphone hardware type and model have  a major impact in the final quality of the results regardless the technique.

Extra stuff

IT University of CopenhagenExperitment in 5th floor in ITU IELS longterm concept   360 panorama from PitLabIELS infographic


[1]  Wouter Bulten.   Human slam simultaneous  localisation and configuration (slac) of indoor wireless sensor networks and their user, 2015.

[2]  Song  Chai,  Renbo An, and Zhengzhong Du.   An indoor positioning algorithm using bluetooth low energy RSSI.

[3]  Yu-Chung Cheng, Yatin Chawathe, Anthony LaMarca, and John  Krumm. Accu- racy characterization for metropolitan-scale wi-fi localization.

[4]  Ramsey Faragher and Robert Harle.  An analysis  of the accuracy of bluetooth low energy for indoor positioning applications. In Proceedings of the 27th Inter- national Technical Meeting of the Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa Florida, September 2014, pp. 2011-210., 2014.

[5]  Atul Gosai and Rushi Raval. Real time location based tracking using wifi signals.

[6]  Xiaofan Jiang, Chieh-Jan Mike Liang, Kaifei Chen, Ben Zhang, Jeff Hsu,  Jie Liu, Bin Cao,  and Feng  Zhao. Design and evaluation of a wireless magnetic-based proximity detection platform for indoor applications.

[7]  Philippe Bonne Jonathan Fürst, Kaifei Chen. Evaluating and improving blue- tooth low energy performance in the wild.

[8]  John  Krumm. Ubiquitous Computing Fundamentals. CRC Press, 2010.

[9]  Anthony LaMarca and Eyal de Lara.  Location systems: An introduction to the technology behind location awareness.  Synthesis Lectures  on Mobile and  Per- vasive  Computing, 3(1):1–122,  2008.

[10]  Jea-Gu   Lee,    Byung-Kwan  Kim,    Sung-Bong  Jang,    Seung-Ho  Yeon,   and Young Woong Ko. Accuracy enhancement of rssi-based distance estimation by applying gaussian filter. Indian Journal of Science and  Technology, 9(20), 2016.

[11]  Zhouchi Li, Yang Yang, and Kaveh  Pahlavan.  Using iBeacon for newborns lo- calization in hospitals. In 2016 10th  International Symposium on Medical In- formation and  Communication Technology (ISMICT).  IEEE, 2016.

[12]  Filip  Mazan and Alena  Kovarova.  A study of devising neural network based indoor localization using beacons: First results. In CISJ Vol19 No1 2015., 2015.

[13]  V. N. Padmanabhan P. Bahl.  Radar: An in-building rf-based user location and tracking system. In INFOCOM  2000. Nineteenth Annual Joint Conference of the IEEE Computer and  Communications Societies. Proceedings. IEEE, vol.  2, pp. 775-784., 2000.

[14]  Jeongyeup Paek, JeongGil Ko, and Hyungsik Shin.  A measurement study of BLE iBeacon and geometric adjustment scheme for indoor location-based mobile applications. Mobile Information Systems, 2016:1–13,  2016.

[15]  Piotr  Sapiezynski,  Arkadiusz Stopczynski,  Radu  Gatej,   and Sune Lehmann. Tracking human mobility using WiFi signals. Tracking Human Mobility Using WiFi Signals, 10(7):e0130824, 2015.

[16]  Takahiro Uchiya Ichi Takumi Shinsuke Kajioka,  Tomoya Mori and Hiroshi Mat- suo.  Experiment of indoor position presumption based on rssi of bluetooth le beacon. In IEEE 3rd Global  Conference on Consumer Electronics (GCCE) 2014, 7-10 Oct. 2014., 2014.

[17]  H. Jiang Z. Chen, Q. Zhu  and Y. C. Soh.  Indoor localization using smartphone sensors and ibeacons.  In IEEE 10th  Conference on Industrial Electronics and Applications (ICIEA), Auckland, 2015, pp. 1723-1728., 2015.

[18]  Faheem Zafari and Ioannis Papapanagiotou. Enhancing iBeacon based micro- location with particle filtering.

[19]  Luo Haiyong Zhu Jianyong, Chen Zili and Li Zhaohui. Rssi based bluetooth low energy indoor positioning.  In IEEE 2014 International Conference for Indoor Positioning and  Indoor Navigation (IPIN), 2014.

IELS: Indoor Equipment Localization System: Discussion (Part 5/6) (IoT)


When this project started, the idea was simple. The goal was to localize objects inside a building environment in an easy and affordable way.

This  idea  turned out to  be  a wide  research area, and lead  to  try different approaches as explained in this chapter.

We think adding walking steps, compass and gyros  sensor to predict moving direction would help creating extra  virtual position. This would add extra  position for our calculation process. We did few experiment in this direction but decided to leave this for future development.

In addition, concepts like fingerprinting and dead reckoning will add value to the system, both should be considered for future improvement.

We have  at  some point considered machine learning for clustering prediction. We think this can be an interesting area of research, for its own.

In our experiment the  user  hold the smartphone in his hand, but  how about collecting data while having the  smartphone in a pocket, at leg level or on a table etc. This could be interesting to clarify,  as it is our  ultimate goal to predict objects while having our smartphones in a pocket.

We thought about adding extra  smartphones in a fixed position that collects data permanently to improve stability of results.

Another interesting aspect could be to try the  same approach with  less iBeacons and try it with directional iBeacons to cover  specific regions. We have  tried to work with eight iBeacons, but we observed that our  software fails to return results.  An- other approach is to  try with  only  four  iBeacons at  each corner of the  room and predict region position estimation instead of x and y position.  We have  at the end chosen to focus on our existing setup with 14 iBeacons and decided to leave this for further research.

Power consumption is important to bring up,  this means a lot for end-users. We do not want to let our  app drain battery from  a user’s smartphone.  Therefore, it is ideally to collect data periodically. For instance, we collect data once only  when a user or the smartphone is stable and not in a movement. We recollect data again when a user or the smartphone change position status. First of all that would reduce noise, improve accuracy and improve battery operation time.

We thought in the long term, that if our app should cover  big buildings, we could easily combining iBeacon data and Wi-Fi data to cover  most of the building without necessarily deploying iBeacon all over the building.

It is true that our  algorithm is tested, works  and deliver the  results we present here in this  report, but  we would like to mention that, it has a place for further improvement. We will mention some of the improvements, that we observed with our algorithm. While we developed the algorithm we did not think of efficiency and running time. This might be possible to improve. The sorting process of iBeacons strongest signal does not guarantee that the strongest signal is the  nearest iBeacon. This  has  therefore reduced the overall accuracy results.  This is left for future improvement.

An interesting test would be with the use of real evaluation with real end-users in a real environment out of the IT-University. Especially the input from  the end-users and the business owners would be a valuable information to have.

It is our  ultimate goal to use  the  smartphone as a crowdsensing device, but nevertheless, this  will rise a new  question about privacy issues. For example: will end-users accept using their smartphones to collect his/her position in which we would be able to use it for localizing trackable objects? Is there a mechanism to use crowdsensing for prediction object location without keeping the data from  a smartphone? These questions need to be studied and clarified.

IELS: Indoor Equipment Localization System: Evaluation (Part 4/6) (IoT)


Evaluation is important and a key process in a project completion. This evaluation is to present the  results of our system, for locating the trackable object position and track its (movement) repositioning over  time using mobile smartphones as  data collectors.  The  usability of the system relies  on  the results collected from  mobile smartphone over  time, more collection from  more users means better results and improving of accuracy. Accuracy in this context means predicting the position of the mobile smartphone in testbed 4.1 (PitLAB) as good  as possible at each direction as demonstrate in this  picture 4.8. Hence this is an experimental use case,  the testbed (PitLAB) environment we use  does include everything from  people sitting around, obstacles and furniture’s etc.  as shown in panoramic image 4.2.

Note: The pictures might have  changed during the  project period, since the PitLAB was under construction during this study.

lab path tagged objectFigure 4.1: Testbed at PitLAB, the yellow  circles indicate three trackable objects. In this picture we  want to  demonstrate how  things look  in  PitLAB and some of the trackable object’s true positions. In our  experiment we use  only  one  trackable object.

4.1    Experimental Setup

The  setup of the  system, means having 14 iBeacons mounted with fixed positions of X and Y  axis (all distances are demonstrated in figure  4.4) in relatively equal distance distribution of each axis.  The height of the iBeacons from  the floor is around

2100-2300mm this is hence to room structure and furniture 4.2.

The  idea  is that the  user has  a smartphone with our  Mobile Client application running on it. The user lets the smartphone collects data form the surrounding iBeacons like the  RSSI-values and UUID/MAC address.  The system then uses  RSSI data to predict the position of the smartphone in the room.

pitlab panoramaFigure 4.2: PitLAB Panoramic view, a scale image version of this is in appendix chapter. If we zoom in the  image we can  see  the  nature of PitLAB. People, furniture in different heights, work-space and desks etc.

4.1.1    Trackable object

We use the same iBeacon type for our trackable object, the only different is our trackable  object does not  have  a fixed  position.  The  height of the  iBeacon is 1200mm mounted on an retried flag pole  4.3.

Trackable objectFigure 4.3: Trackable object (Pole)  tag with  iBeacon. We asked the  Facility Management department of the IT-University if they could provide a pole  for testing, and luckily they had some old flag poles which have  been used throughout the study.

pitlab overviewFigure 4.4: iBeacon fixed position in room. Here we show the  PitLAB room top  view and how 14 iBeacons with fixed positions are placed in the room

4.1.2    iBeacon specification

All our  iBeacons are  Estimote 4.5 brand. The two most important configuration of iBeacons is transmitting power (TxPower) and advertising period. TxPower is set to

-12dB and advertising is set to 967ms on all iBeacons.

ibeacons estimote

Figure 4.5: Estimote iBeacons

4.1.3    Smartphone

The smartphone is from  Google, model LG Nexus 5x. Regarding to recent research made by Fürst [7], the  IT-University, this smartphone  should be the best phone to receive iBeacon signals. It makes it a suitable choice for our project.

Nexus 5xFigure 4.6: Google Nexus 5X

4.2    Experiment

We mark the  floor  with four  positions, called true positions: A, B, C and D. At each true position we have four directions: 0, 90, 180 and 270 degrees, 0 is almost on Earth North direction, as demonstrated in picture 4.8.

We collect data from  all iBeacons (fixed  position iBeacons and trackable object iBeacon) from  each direction over  60 seconds of time. We hold the smartphone in our  hand, centered to the body front as demonstrated in the picture 4.8. We repeat this in four rounds.

For instance if the trackable object is placed on C, we collect data from  true position A Round 1 and true position B Round 2 from all directions. We continue to move the trackable object to D, and collect from true position B Round 1 and true position C Round 2 until trackable object has been through all true positions as shown in the experiment table 4.7.

experiment overviewFigure 4.7: This table presents rounds and the time sequence. Round 1 and Round 2 are parallel rounds, but  if we predict smartphone at A and predict smartphone at B, we predict trackable object at C. Later in this section eight different graphs will be presented (Graph1 to Graph8). These represent the results of the experiments.

testbed anglesFigure 4.8: A person holding smartphone testing RSSI receiving signals at Round 3 in true position B on angle 180° direction.

pitlab testbedFigure 4.9:  Testbed at PitLAB. We show here for instance Round 3, where the  user test smartphone at true position A and move to true position B to predict trackable object at true position C

4.3    Results and analysis

In experiments from  Round 1 and Round 2, we have totally 19 trackable objects estimation results and Round 3 and Round 4 from 23 trackable object estimation results. The  Red  mark belongs to true position C, Green belongs to true position D, Blue belongs to true position A and Orange belongs to true position B. For each colour cluster, we calculate a centroid of the collect data and represent this in bigger circle. We have  added a horizontal and vertical line in centre of our  graph in which each true position gets its own region respectively region AR, BR, CR and DR. The cross (+ sign)  in graph represent the true position of the trackable object as demonstrate in graph 4.10 and graph 4.11.

As it appears for Round 1 and 2, the position of Red centroid belongs to CR region, Green belong to DR, Blue belongs to AR, expect the last one  Orange which belongs to AR. However, Round 3 and 4, all colour belong to  their respective regions (we calculate our centroid by taking the average of x and y for each cluster).

Graph 1 4.10 shows the  result from  Round 1 and 2 and Graph 2 4.11 show the result of round 3 and 4.

Figure 4.10:  Round 1 and 2, (+) sign  represent true positions of trackable object, small dot  in graph represent trackable object estimation results over  time and the bigger circle  is a centroid product of the small dot cluster

Figure 4.11:  Round 3 and 4, (+) sign  represent true positions of trackable object, small dot  in graph represent trackable object estimation results over time and the bigger circle  is a centroid product of the small dot cluster

As explained in the beginning of this section, we predict a smartphone position at different angles in different true positions. For instance, we predict a smartphone at true position A and the same in true position B, then we use the results to calculate and predict the position of trackable object in C etc.

The  results from  the experiments are  presented in the  following eight different graphs. Each graph has two centroids of two predicted smartphone positions of four different directions with  cross (X) sign,  smartphones have  true positions with plus (+) sign,  small dots are generated by our  trilateration method from  combination of two predicted smartphone on different direction and a big circle  that represent the centroid of all small dots for trackable object.

Before  we start with  looking into the  eight graphs, we present a graph as an  example 4.12 and explain the signs:

+ sign: True  position
X sign:  Centroid of Smartphone predicted position
O sign:  Centroid of trackable object predicted position o sign:  Predicted positions of trackable object
A position top left
B position bottom left
C position bottom right
D position top right

Figure 4.12: Graph: This is a sample graph with explanation of different signs we use in the upcoming graphs.

Figure 4.13: Graph1: Collecting data from two true positions A(+) and B(+). A(X) and B(X) smartphone predicted position, B(X) is far away from  B(+), result of this predict position of trackable object centroid C(O) with true position of C(+)

Figure 4.14: Graph2: Collecting data from two true positions B(+) and C(+). B(X) and C(X) smartphone predicted position, result of this predicted position of trackable object centroid D(O) with true position of D(+)

Figure 4.15:  Graph3: Collecting data from  two true position C(+) and D(+).   C(X) and D(X) smartphone predicted position, C(X) is far away  from  C(+), result of this predicted position of trackable object centroid A(O) with true position of A(+)

Figure 4.16:  Graph4: Collecting data from  two true positions D(+) and A(+).  D(X) and A(X) smartphone predicted position, result of this  predicted position of trackable  object centroid A(O) with true position of B(+), Our algorithm was only able  to predict one  position

Figure 4.17:  Graph5: Collecting data from  two true positions A(+) and B(+).  A(X) and B(X) smartphone predicted position, B(X) is far a way from  B(+), result of this predicted position of trackable object centroid C(O) with true position of C(+)

Figure 4.18:  Graph6: Collecting data from  two true positions B(+) and C(+).  B(X) and C(X) smartphone predicted position, C(X) is far away  from  C(+), result of this predicted position of trackable object centroid D(O) with true position of D(+)

Figure 4.19: Graph7: Collecting data from two true positions C(+) and D(+). C(X) and D(X) smartphone predicted position, result of this  predicted position of trackable object centroid A(O) with true position of A(+)

Figure 4.20: Graph8: Collecting data from two true positions D(+) and A(+). D(X) and A(X) smartphone predicted position, result of this predicted position of trackable object centroid B(O) with true position of B(+)

Since  we have  an average error level of 2.04 meter 4.4 with standard deviation of 0.28 meter 4.4, so if we want to visualize trackable object position on a map it would be much better to present it in a more human friendly and readable way.

In our  map, we have  four  true positions. If we split  the room horizontally and vertically in half, this would give use four regions, where each true position belongs to its respective region as described earlier.

The  same convention is used as before AR, BR, CR and DR. AR stays  for A Region,  B Region, etc.  If we take the trackable object position result from  the  previous graphs, then we can present the trackable object position in its region and its movement over time. As we can see in the first graph the trackable object has moved over time from  C to D, D to A and A to B is its final move.

In the  first graph, we see trackable object move over time on the respective path, expect A to B. If we look back in Graph4 4.16, we can see we have only one dot, where we normally should have  at least more than one  dot  as shown in graph 4.21.  Our system has  failed  to calculate the  results of the  particular place. The reason for this can vary, but  one  reason might be that the  particular time there could be affecting heavily with noise.

If we take  the  next  graph, the  trackable object follows  the path as expected as shown in graph 4.22.

Depending on the room size and the  error level, we assume it is possible to split the room in more regions to get smoother results. That  said,  we conclude that continues data collecting from  more phones over time will improve accuracy of the prediction of position results.

Figure 4.21:  In this  graph we illustrate trackable object location in regions and its movement from  place to place over  time. This is a result of combination of Round 1 and 2. As we can  see the trackable object suppose to move to B region, since our system fails to calculate the results. This means trackable objects stop at A region

Figure 4.22:  In this  graph we illustrate trackable object location in regions and its movement from  place to place over time. This is a result of combination of Round 3 and 4.

4.4    Error level

We have  in chapter 2 under section RSSI measurement 2.2.2 talked about iBeacon and smartphone challenges and in same chapter talked about RSSI distance calculation 2.8 which shows the measuring errors over distance of our iBeacon. If we take all that into consideration and look at our results we discover an error margin in our results as well.

We have  made two  graphs to  illustrate the  error level  of our  system.  The  first graph demonstrates error level  of a smartphone.  We present the results of each Round and for each true position point in table. Then we calculate the hypotenuse of X and Y  to get the distance of the  error and present that in Cumulative distribution function (CDF) graph 4.24. We can  see that our overall results have  distribution of error at different levels but interesting enough that almost 75% of the results have error level below 1.5 meter with  average of 1.33 meter error and standard deviation of 0.13 meter.

However, in the Cumulative distribution function (CDF) graph 4.26, for trackable object, we can see the error average has raised to 2.04 meter with standard deviation of 0.28 meter. The interesting aspect of this graph is that 75% of the results are below 2 meter.

If we compare the error of trackable object to our  smartphone, we see the  trackable  object error level is higher than the one  from  smartphones. This is due t nature results, hence the trackable object get its position result from  smartphone positions which already have  error margin.

We calculate the hypotenuse with the following formula:d = error distance from  true position.

Figure 4.23:  Smartphone distance error of each axis x and y for each true position and for each round, with average value  of each round.

Figure 4.24: CDF graph for smartphone distance error of hypotenuse results from  x and y from  previous table for each round

Figure 4.25: Trackable object distance error of each axis x and y for each true position and for each combined rounds, with average value  of each round.

Figure 4.26: CDF graph for trackable object error of hypotenuse results from  x and y from  previous table for each combined rounds.

4.5    Conclusion of this chapter

We conclude that BLE signals in iBeacon is hard to control. Even Estimote (the company that produces iBeacon, which we use in our  experiment) mention the issue of precision on their website 1. It is around 20-30%.  This said,  we cannot control the behaviour of BLE nature. In addition, we have learned that we need to predict a high number of smartphone position before we can  predict our  trackable object. However,  by developing and improving algorithms, we will be  able  to get some useful results.

IELS: Indoor Equipment Localization System: Implementation (Part 3/6) (IoT)


3.1    Software architecture

The software architecture is based on three main components, Mobile Client, Data Server  and Admin Server  as shown in figure  3.1.

  1. Mobile Client is an Android application. Its main purpose is to collect iBeacon data such as RSSI-values and send it over to the data Server.
  2. Data Server is a Restful API (Application Programming Interface) that takes care  of the  data collected by Mobile Client application.  Data Server  is also responsible for business logic and calculation algorithm. Data Server  have  a UI, to show RSSI results of experiments.
  3. Admin Server is a Web Application with Restful  API offer an administrator UI help to manage the iBeacons and smartphones information.

The  idea  of separating Data Server  and Admin Server  relies  on  future thinking. Hence Data Server  purpose was  only  experimental and data analysis. We thought at some point the  Data Server  will end its job and the  logic of the algorithm will be implemented directly in the smartphones. That  way the  smartphone will take care of all logic and returns its x and y position directly to Admin Server.

ImplementationFigure 3.1: System Architecture. We show how  Mobile Client connect once at startup of the application to Admin Server to get a list of all allowed devices and iBeacons. When the Mobile Client is done with collecting of iBeacon data, it posts our  data to Data Server. When we start Data Server it connects to Admin Server to get a list of all allowed devices and iBeacon.

3.1.1    Mobile Client

The  main purpose of Mobile Client Android application  3.2 is to  collect iBeacon RSSI data.  When the  application starts up,  Wi-Fi,  Bluetooth and Location service turn on,  because it is required, otherwise it will alert the  user  3.3.  This  is required to update initial iBeacons (iBeacon fixed position, name of device etc.),  data from Admin Server, sending and receiving data over  Wi-Fi, receiving iBeacon data using Bluetooth. When a user  enters experiment name and start collecting process, it will check for six conditions before collecting iBeacon data as described here and shown in process flow 3.5:

  1. Data-structure: the application will connect to the Admin Server  to build a data structure of activated iBeacons with initial information such as fixed  X and Y position of iBeacons, names of iBeacon, name of trackable object iBeacon  and smartphones name if registered in system.
  2. Registered: it checks if a smartphone device is registered and is allowed by the Admin Server.
  3. Bluetooth: it checks if Bluetooth is receiving data from  iBeacons as expected.
  4. Connected: it checks for Restful  API connectivity.
  5. Collecting: smartphone starts collecting real-time data over 60 second.
  6. Send Data: when 60 seconds is over, it posts the collected data to Data Server.

Android Client
Figure 3.2: Preparing page.

Android Client ErrorFigure 3.3: Alert page

Figure 3.4: Mobile Client Android application. When the application is ready to collect  data for each experiment, the  Start-button appears automatically to the user. When the collecting time is over  it will automatically post the data and give a pipsound at the end. In case  one  of the communication service like Wi-Fi, Bluetooth or Location Server  is down, the user  gets alert.

Android app flowFigure 3.5: Mobile Client application process, shows how the application react while starting up until the user is ended with the experiment.

3.1.2    Data Server

Data Server is a Restful API. It receives iBeacons data from Mobile Client Application and store it on  real-time database from  RethinkDb 3.8 (an  Open Source real-time database). Data Server  stands for business logic and calculation algorithm. In addition, it offers  a UI 3.6 to show graph of RSSI-results 3.7 for analysis purpose. The server works  on a local machine in PitLAB.

data server uiFigure 3.6:  Data Server  UI. We built this  system to deliver the tools  we needed to make our  experiment process smoother. It delivered data to Excel or showed RSSI- values of given experiment

RSSI samplesFigure 3.7: RSSI samples. This is example of Data Server  UI that shows RSSI-values of given experiment

realtime rethink databaseFigure 3.8: Real-time Rethink Database administration UI. In our  development we used Rethink Database, it has  own  API that is compatible with programming language such as Java, C#, PHP and many other programming language. This  means it deliverers us a simple ReQL (RethinkDB Query Language) which we can  use  on different platforms

3.1.3    Admin Server

Admin  Server  is a cloud based Web  Application  which delivers an  administrator UI 3.9 to manage all devices and iBeacons allowed to interact with  the  system. In addition, it offers  all initial information about iBeacons, trackable object and Mobile Client.

administrator uiFigure 3.9: Administrator UI. This is Admin Server  UI which helped us adding new iBeacons or smartphones to our experiment.

3.2    Development challenges

In previous chapter under different smartphones challenge section, it is described how we had challenges with developing a Mobile Client.

We developed our  Mobile Client on  Google Nexus 5X smartphone with  single iBeacon and it collected iBeacon data as expected.  When we tested the same application on  the smartphone we  got  from  PitLAB (Motorola Moto E3) the we  got different results. First,  we thought our  software had issues and we tried to re-write and improved our code, but we ended up understanding that it was a hardware issue rather than software.

Throughout the project, we had minor network issues in PitLAB. Unfortunately, we were  not  able  to start our  server with the given  IP address. Luckily, the management of PitLAB offered us access to an internal Wi-Fi system that was reliable and stable.

3.3    Conclusion of this chapter

In this chapter it has  been explained how  our  software infrastructure was  implemented. At an early stage of development process of this project, the main idea  was simple: how to collect iBeacon data and process it? This idea  turned soon to require us to develop three main software solution: a Mobile Client, a Data Server and an Admin Server. All of them intercommunicating with each other. We have  learned that developing software for iBeacon for one smartphone does not necessarily means it works  for all smartphones.

IELS: Indoor Equipment Localization System: System Design (Part 2/6) (IoT)

System Design

In this chapter, we will explain the system design behind Indoor Equipment Localization System (IELS).

Before we go into the details of the system, the main goals of this project will be elaborated. The following questions are chosen in order to create a direction for the project:

  • Q: What is our goal?
    A: To localize object in room.
  • Q: What do we need in order to localize object?
    A: Some reference positions.
  • Q: How to get reference positions?
    A: Some localization techniques like Trilateration.
  • Q: What does Trilateration need?
    A: At least 2-3 Distances.
  • Q: How do we achieve distance?
    A: One way is to convert RSSI values to distance.
  • Q: How do we get the best values?
    A: by sorting strongest RSSI values.

These questions guided us to solve small problems that might be in a chain of a bigger problem. It helped as well to make some useful choices in our algorithm development.

In next section it is explained how our algorithm works and then take the elements that is involved in its development.

2.1. The Logic of the chosen Algorithm

The algorithm pseudo 1 is used for calculating the location of a smartphone that we use to calculate our trackable object location. Each step that has correlated processes and dependable methods will be explained later in this chapter.

In the infrastructure of the system, we use 14 iBeacons with fixed position and one iBeacon as trackable object as described in our evaluation experimental setup section. We use one mobile smartphone to collect our iBeacon data.

While we implemented our algorithm, we made regularly small tests, experiments and trail and fail, until we reached our solution. Conceptually one of the research papers gave us interesting knowledge about our Algorithm by Jea-Gu Lee who is mentioned in our Related Work-section. The main difference is that they use Double Gaussian Filter in their approach. In addition, some inspiration came from a previous work of Wouter Bulten.

In our approach, we collected all reachable iBeacons RSSI values over time and sort RSSI values in a descending order for each second. Then we take the three strongest RSSI values and convert those to the distance. Finally, by using trilateration mathematical equation we predict the estimate position of x- and y-coordinate of the mobile smartphone.

When we predict positions, we use the positions to calculate the position of our trackable object. A simplify example illustrate how our algorithm works to predict the estimated position of a trackable object in a room(see figure 2.1). When we collect more than one reference point like ’User A’ with a smartphone, we get estimate position A and estimate distance to trackable object (X1, Y1, d1). At some point, another user, ’User B’, with another smartphone get estimate position B and estimate distance to trackable object (X2, Y2, d2). This is the minimum information we need in order to calculate and predict the estimated position of a trackable object (X object, Y object). Our algorithm is used to predict an estimated position of a smartphone location over time and we use that information to calculate the estimate position of a trackable object.

Object localizationFigure 2.1: How to estimate a position of a trackable object from User A and User B.

In the previous section we explained the concept of our algorithm. In the following description we present the pseudo 1 code of the used algorithm.

Init Map Device Data Structure
Collect iBeacon RSSI
initTimeSeries {keep RSSI last value until updated}
kalman {Kalman filter RSSI for each iBeacon}
results {Moving Average of each kalman results}
bestRSSI {Sort results select best 3 RSSI each second}
(Note: Sort RSSI value descending order)

For each rssi set of $bestRSSI$ compute $DISTANCE(RSSI)$

If {at least 3 distance available}
    Return {$positionXY$($x_1$, $y_1$, $d_1$...$x_n$, $y_n$, $d_n$)} Else
    Return {no results}

    Compute RSSI to Distance
    Return $distance$

Procedure{positionXY}{$x_1$, $y_1$, $d_1$...$x_n$, $y_n$, $d_n$}
    Compute using Trilateration
    Return $x_{new}$, $y_{new}$

Initially, we initialize the data structure that contains all initial information aboutour fix iBeacon position, trackable object and mobile smartphone. The system then collects RSSI-values from all iBeacons (fix iBeacons and track-able object iBeacons). Our initTimeSeries will keep last RSSI-value until a new value is received. This isto guaranty that all iBeacons have values we can use for calculation.Afterwards, RSSI-values unfortunately includes noise (we will explain noise prob-lem later in this chapter), but with the use of a Kalman filter, it is possible to take theraw values and try to decrease the noise from the values and thereby predict newvalues. We take values from the Kalman filter and run it through moving averagefilter to smooth the RSSI-values.Finally, we sort RSSI-values and take the three strongest values for each second.

Now for each of these strong RSSI-values we use distance method to convert RSSI to distance. If there is at least three distances then we calculate location x and y.

2.2. Proximity distance estimation

As we mention in chapter 1, localization proximity is about having distance estimation between two objects, for instance smartphone receive iBeacon (RSSI-values)signal in dB (Decibel). This said, higher dB-values means stronger signal, which means shorter distanceto the sender-device. We allow us to transform this relation of dB-value to estimatedistance between sender- and receiver-device. There are a variety of methods forthis. In this thesis we mention three methods in section. There are various reason why distance estimation cannot be 100% accurate, suchas different types of obstacles as explained in paek paper page 7, section 4.7. The following section will introduce some distance estimation in more details.

2.2.1. Indoor Distance Estimation using RSSI signals

The nature of iBeacon RSSI-signals are unfortunately rather inaccurate, unstableand contains noise. Many factors play a role in fluctuation of RSSI-values; for in-stance, obstacles like: human movement, human body, type of wall, type of materi-als and other external noise factors etc.

In addition, each smartphone model and type has different BLE receiver, thatbehave differently from phone to phone.

Therefore, it is important to have a revision of measured RSSI-values for each en-vironment and each smartphone before using them as mentioned by Lee. Fromthis we can build a data model for each environment and smartphone type whichwe will describe in this section

Regarding materials type that influence RSSI-signal, a paper by paek mentionthis problem in page 7, section 4.7. They solve this by building a data model for it.

2.2.2. RSSI measurement

As describe earlier in our algorithm logic, we need to estimate distance to calculatethe estimated position. In our case distance comes from RSSI-signal strength. Wewant to measure and understand the relation between RSSI and distance. This said,it is important to validate this and put that in a model so we can use it in our algo-rithm.

For this experiment, we use Estimote iBeacon (in the yellow circle) as a sendersource and LG Nexus 5X smartphone (below the half yellow circle) as a receiver.

We mark the floor with read/white lines indicating real distances from 0 to 30 meteras shown in figure 2.2. This measurement take place in front of PitLAB, 5th floor atIT-University of Copenhagen.

We collect RSSI-values over 60 seconds as shown 2.3 and calculate the averagevalue of morning, noon and night. The reason we choose morning, noon and nightis because in previous tests we made, we can see different behaviour and results forRSSI-values in those parts of the day.

Room RSSI calibrationFigure 2.2: RSSI-value over distance measurement, in front of PitLAB

Room RSSI measuresFigure 2.3: RSSI-values of morning, noon and night. All real distances are in metersand all RSSI-values in dB

Finally, the data is plotted in a graph 2.3, and the relation between distance andRSSI-values becomes clear. The results of the graph clearly shows a logarithmic cor-relation between signal-value over different distances in meter.

It is important to mention that RSSI-values can easily be affected by environment,signal-sources from other devices like Wi-Fi page 7 and obstacles page 8, hu-man body, walls etc. Even thus we have the smartphone and the iBeacon place ina fixed position. The importance of measurement gives us an approximate estima-tion of that particular environment and smartphone we use. Furthermore, the erroraverage increases as the distance increases as demonstrated in graph.

Graph RSSI measuresFigure 2.4: RSSI-value logarithmic correlation to distance. X: real distance in meter,Y: measured RSSI-value Different smartphones challenge

From our tests and observation, we found that different smartphones have differentreading of RSSI-signal strength value and are not equal with latency. Latency in thiscontext is how many RSSI samples are received per second.

In addition, we observed also that smartphones behave differently in morningand evening time. For instance, the same smartphone with the same software cancollect up 3-4 samples per second in the evening hours and only one in the morn-ing or noon. The reason for this can be many, but one might be noise generatedfrom other sources such as Wi-Fi-usage in open hours. This said, it is unclear whatcaused this behaviour. Interesting enough while we worked with these challenges,a recently published paper from Fürst mentioned some of these challenges. Wehave added a minor supportive arm to some of the experiments in this paper asshown in figure 2.5. The measurement shows different results from different smart-phones as shown in the chart.

SmartphonesFigure 2.5: Smartphones comparison, collecting RSSI-values from same source. Ex-periments from the following paper

Graph RSSI distance boxplotFigure 2.6: RSSI variation between different smartphone models from paper

2.2.3. RSSI distance calculation

We built a data model for our RSSI-value over distance in meter, but have can wecalculate RSSI-values to distance? There are many ways to calculate the estimateddistance between iBeacon sender- and phone-receiver using the RSSI-values.

In our design we experiment with three different methods, and make a compari-son chart 2.7 between the results.

For the following methods the iBeacon txPower (txPower stays for BroadcastingPower or Transmission Power of iBeacon) was set to -12dB and advertising rate is setto 967ms:

1- Generic log distance. . . is a generic method that is known to be used inmeasuring distance based on RSSI-values. The method results depending oniBeacon transmission power and a free space factor value which is normally between 2 and 4, in this experiment we used -12dB txPower which is the de-fault value by Estimote and the free space factor was set lower than 2 hence toreduce error scale:generic log distance

txPower = transmiton power of iBeacon

RSSI = value of signal strength

Free Space Factor = a value between 2 and 4

2- Estimote. . . is mentioned in two research papers”An Analysis of the Accuracyof Bluetooth Low Energy for Indoor Positioning Application”and”A Mea-surement Study of BLE iBeacon and Geometric Adjustment Scheme for IndoorLocation-Based Mobile Applications”.The same method is used and supported by Estimote beacons. It issimilar to previous method but the factor is set to a fixed value two. The mathformula for this method is:Estimote

rssi1= RSSI is measured in 1 meter, in our case it was -68dB
The final result is multiplied by 1000 to get results in Millimeter.

3- AltBeacon. . . is based on AltBeacon library and is used in a paper”An IndoorPositioning Algorithm Using Bluetooth Low Energy RSSI” with followingmath formula:


The numbers 0.89976, 7.7095 and 0.111 are constant values set by the devel-oper of this method with out further explanation.The final result is divided by 1000 to get results in millimeter.

NOTE: All mentioned methods in our RSSI distance calculation section returnresults in millimeter unit.

We test all above mentioned methods in Excel and Java, the result of all methodsare presented in graph 2.7 shows conversion of RSSI to meter for each distance.

The results clearly shows from figure 2.7 and error figure 2.8 that Method 1 has least errors, and Method 3 has most errors in our LG Nexus 5x smartphone.

It is clear that RSSI do not increase linearly with distance, the error margin in-creases as the distance increases. That said, all this can change from place to place,depending on the noise and distortion on that particular environment, but the log-arithmic correlation would still hold on all environment.

Graph RSSI tometerFigure 2.7: RSSI over distance in meter comparison graph for different conversionmethods, X: Real distance in meter, Y: Measure distance in meter. The iBeacon tx-Power was set to -12dB with advertising rate is set to 967ms11

Graph RSSI errorFigure 2.8: RSSI over distance in meter comparison graph for error level of differentconversion methods, X: Real distance in meter, Y: error level in meter. The iBeacontxPower was set to -12dB with advertising rate is set to 967ms

2.3. Time Series Processing

’Time series’ refers to a sequence of observations following each other in time, where adjacent observations are correlated. The main reason for using time series processing in our project is because we observed form early experiments that our raw RSSI-values contain noise over time. We have analyzed raw RSSI-values, as shown in oneexample in graph 2.9.

It is therefore obvious to work with time series processing methods. As men-tioned earlier, for various reasons, there will always be “noise” and “distortion” inwhen receiving a iBeacon RSSI-signal, even if the receiver is not moving. This wouldrequire a way of cleaning and processing strategies for time-series data.

The book Ubiquitous Computing Fundamentals shows various methods forhelping smoothing RSSI-values by filtering out the noise and distortion from differ-ent fluctuations. Time series models can be simulated, estimated from data, andused to produce forecasts of future behaviour.

In this project, we know that we have something to do with time series process-ing but was not sure which one and how to use. We gathered some basic knowledgefrom different resources (like previous works, Ubiquitous Computing and online re-search). Then we did a lot of trial and error, all ended up with using two popular filtering techniques: The Mean filter (Moving Average) and the Kalman filter.

2.3.1 Moving Average

Moving Average (MA) filter is a trend-following (trend in this context means a pat-tern of gradual change in a condition, output, or process, or an average or generaltendency of a series of data points to move in a certain direction over time2) be-cause it is based on past RSSI-values in this case. There are different types of movingaverage, the most common used Moving Average for this purpose is Simple Mov-ing Average (SMA), which is the simple average of a security spread across a definednumber of time periods. The most common applications of Moving Average are toidentify the trend direction and to determine signal level.

In our design, we implement a moving average and demonstrate the differencebetween our RSSI-input (black trend) and Average (green trend) output in figure 2.9.

The moving average takesnnumbers of RSSI-values, defined as window size. The method returns the average of RSSI-value of the given window size.

Our moving average implementation is based on following formula inspired fromJohn Krumm book Ubiquitous Computing Fundamentals kalman We have set our n value (window size) to be 10, we can see clearly this methodreduce some of the noise from the original input. We have tried different windowsizes, if window the size become five we get more noise in output and if we increaseit to 20-25, this will cost calculation delay of processing. It was decided to work withnumber ten to reach a balance value for this purpose.

Graph RSSI filterFigure 2.9: RSSI filter comparison, X: Time in Second, Y: RSSI value in dB

2.3.2 Kalman

Kalman filters will not be described in details, since there is a lot of papers and on-line resources describing Kalman filter. Roughly, we use Kalman filters to reduce thelarge spikes of RSSI-values as shown in graph 2.9, while trying to retain distance in-formation. A (regular) Kalman Filter is used to filter incoming signal strength mea-surement. The true RSSI-value (without noise) is defined as the state we want toestimate. Our Kalman filter implementation is based on existing pseudo-code of aprevious master thesis done by Mr. Wouter Bulten.

A Kalman filter returns RSSI-values as a Integers and we can see from the figure 2.9 that a Kalman filter reduces some of the noise from the original RSSI input.

2.3.3. Combining methods

From both observation we can see both methods reduce an amount of the noise.In this project we wanted to try to combine moving averages and Kalman filter toreduce the noise from RSSI-values as shown in figure 2.9. What we did is passing thelast measured result of the Kalman filter to the moving average of ten window size.This has reduced the noise drastically.

At an early stage we put the values into a spread sheet and made some primitivecalculation. Then we implemented a simple version of Moving Average that helped a bit to remove some of the noise, but not all of it. Later in the development processafter trying with different other methods, we tried to implement an already existingpseudo-code of a Kalman filter inspired from the master thesis by Mr. Wouter Bul-ten. The method did indeed remove some of the noise as well. We thought: ifboth filters remove some noise, it could perhaps be an option to combine the fil-ters – and the quality of the results increased significantly. One of the reasons our graph has a straight line is because we use Integer values which cleans up some ofthe noises as well.Nevertheless, this comes with a cost: Mostly, it takes up to 10 seconds before thesystem is able to calculate values.

2.4. Localization algorithms

There is different ways and methods to use for localizing – all depending on the out-come and the requirement of the project. As mention in chapter 1 there are sixmethods for localization and we have already defined the methods.

So far we have used proximity relation to RSSI over distance estimation. Now wewill use Trilateration in our algorithm hence we have a lot of distance andxandypositions. Hyperbolic lateration is more related to time of flight (TOF) techniquewhich is used in GPS-localization and Triangulation is typically used for high an-tenna tower. Fingerprinting and Dead reckoning might be relevant to our projectbut is left for the discussion-chapter.

Trilateration 2.10 is a mathematical equation that computesxandyposition ofa smartphone in our case, by calculating at least three distances to fixed positions ofxandy. Trilateration is able to calculate the position by using two distances insteadof three, but that will increase the error level which leads to reduction of accuracy.

TrilaterationFigure 2.10: Illustrate how trilateration works

In our Algorithm, we use a Java-library called Lemmingapex trilateration. Wewanted to be sure that this library works correct. We injected different tests withthree positions and three distances and we got an expected results.

In addition, we have also chosen to implement a lightweight and static (static inthis context means sensitive for estimate distances) trilateration method for com-parison purpose, and we implemented a basic trilateration formula from The Uni-versity of Georgia3. The university provide a detailed explanation and sample excelfile with math formula. We have used the same test data from previous method andwe got close to identical results. Hence Lemmingapex has been used by some de-velopers and has better features then our basic implementation. It might take morethan three reference points and are more dynamic (dynamic in this context meansthe method is suited for handling estimated distances), we have therefore chosen tocontinue using the Lemmingapex-library in our implementation.

2.5. Conclusion of this chapter

In this chapter we presented different methods: distance estimation based on RSSI-values, moving average, Kalman filter and trilateration. All of them to calculate smartphone positions. The progress of this process relies heavily on previous work and achievements from other papers, inspiration from Ubiquitous Computing Fundamentals by Krumm, reverse engineering thinking and most importantly: trail and error. We conclude here that RSSI-values have logarithmic relation to distance as well as errors margin rise as the distance increases – and how RSSI is able to change values from surrounding environment and external factors. Finally, different smartphones type and models gives different results.

IELS: Indoor Equipment Localization System: Introduction (Part 1/6) (IoT)


It is no longer secret that I have been working on IELS in my Master Thesis ended September 2017. It was joy, fun and hard as well. Some of you guys asked me if I can share what I have been working with and write some thing about it.

I have chose to make a wrap up version of my Master Thesis chapters in 6 parts and post it here on my blog. This post will be the first part of 6 coming parts in future.

The concept of IELS
The concept of IELS

1.1 Context

Today smartphones and other Internet connected devices are increasingly penetrating our everyday lives. The global smartphone shipment forecast graph illustrates this trend estimates from BI Intelligence 1.1 [1].

The emergence of these devices is associated with the rise of various short-range communication technologies such as Near Field Communications (NFC), RadioFrequency Identification (RFID), Bluetooth, BLE, Bluetooth beacon or iBeacon [2] These technologies empower pervasive interactions between humans and their devices. Early work often focused on localizing users down to less than one meter accuracy, but now we are moving towards localizing objects. This will support the development of novel applications, which solve problems of our everyday living, improve quality of our lives and boost business results which will be elaborated further later in this chapter.

Global Smartphone Shipments Forecast
Figure 1.1: Global Smartphone Shipments Forecast

More specifically: companies, hospitals, universities and larger organizations are challenged to keep track of assets inside buildings. Indoor object localization/tracking can improve many processes in non-residential buildings:

  • In hospitals this is important to help doctors to get the correct equipment when required, while being able to trace its past locations in the hospital as shown in example 1.2.
  • Another practical example from the IT-University of Copenhagen, the staff of Facility Management has no active location information of all mobile whiteboards/screens in a building. The only way to find out is to walk to the expected locations of the whiteboards (physical objects) and have an on-site visual sight of the whiteboards. Furthermore, localization of objects can significantly reduce the time spent by employees to search for objects inside a building as shown in example 1.3.

Both examples illustrate process optimization. Processes can be optimized based on the knowledge of the usage history of a given equipment: where have the equipment been previously, for how long time the equipment has been visited, how much time was spend on moving from one location to another.

Example 1: Localizing equipment’s and assets in a hospital.
Figure 1.2: Example 1: Localizing equipment’s and assets in a hospital.
Example 2: Localizing mobile whiteboard or mobile screen in a building
Figure 1.3: Example 2: Localizing mobile whiteboard or mobile screen in a building

In the following section it the used concepts of this project will be introduced:
localization, Bluetooth and iBeacon, Object tracking.

1.2 Background and related work

There has been a considerable amount of research within the area of iBeacon based localization systems tailored for use inside buildings. In this project we choose to investigate a selection of both the research side and the commercial side.

1.2.1 Related work: Commercial

Commercially, iBeacons are produced in a variety of companies.

Estimote is one of iBeacon players that produces and sells iBeacons (the same iBeacons we use in our experiments). This company claim to have developed a new type of iBeacons that use time of flight (TOF) technology which helps generating maps for localization system for users.
Information about another new iBeacon product – in which users are able to tag to objects – is only available in a YouTube video [3] and [4]. This illustrates the idea, but there was no paper or technical information available on their approach, which leaves the assumption with poor evidence. Furthermore, this service of Estimote is not free of charge, as it requires a monthly subscription with Estimote. This might not be an attractive model for some firms.

Another company called [5] promises interesting tracking products using iBeacon but does not provide detailed technical information. However, this might be an interesting product, since they promises to build a Real-Time Location system at 1/5th the cost of competing positioning technologies like active RadioFrequency Identification (RFID) or Wi-Fi.

Note: All related work can be found in the bibliography associated with localization and tracking of items, as well as their applications in asset management.

1.2.2 Localization

Localization is an important part of ubiquitous computing, it has been an active research topic for the past decade. To be able to determine a user location, open doors for unlimited ubiquitous computing applications that offer service for specific location and context and added value to the service provided. Lot of work and research has been made using different approach and technologies like Wi-Fi, Radio-Frequency Identification (RFID) and Ultrasonic (Active bat, p.305).

Ubiquitous Computing Fundamentals Book categorizes approaches to determining location with briefly descriptions of each method:

  1. Proximity is a simple location technique, to indicate closeness of a device to a reference point.
  2. Trilateration Mathematical equation to calculate location based on at least three position reference points.
  3. Hyperbolic Lateration Mathematical equation to calculate location based difference between the signal arrival times from at least three reference points.
  4. Triangulation Mathematical equation to calculate location based on angle of arrival of signals traveling from a device to a reference point.
  5. Fingerprinting A method to save Received signal strength indication (RSSI) values from different sources in a database, and when other devices read the same information from the database, they are able to return an estimate position based on previous records.
  6. Dead Reckoning Mathematical equation to predict a vector, based on previous direction and speed data.

Note: method like trilateration would work with two reference points, but it will affect accuracy.

These approaches are used in different technologies; for instance: Global Positioning System (GPS), mobile phone localization and radio communication localization. Each technology has various usage in different contexts: GPS is used for navigating car drivers in traffic – and it is possible to localize a person calling the emergency service.

Back in 1978 when Global Positioning System was launched for first time, the main goal of GPS systems was for outdoor localization.

Early mobile phones came without GPS receivers and the only way to locate phones, was to use cell tower to triangulate the device location with an inaccurate result. In the past decade GPS receiver technology has been integrated in smartphones. This make it possible to get accurate location of the device when the GPS is in use. Both sources of localization technology, GPS or cell tower served us for decades with acceptable accuracy, but these are unfortunately not suitable for indoor locations. This lead us to think: what about localizing phone devices or objects inside a building? From this question emerged the concept of Indoor Localization System (ILS) or Indoor Positioning System (IPS).

1.2.3 Indoor Localization

As mentioned before, GPS-signal does not go through construction materials and therefore GPS can not help localizing devices inside a building. For instance in an airport, a passenger can find his way to a departure gate, if the passenger knows his current location. A major amount of research regarding ILS/IPS have been conducted since 1992. For instance, Active Badge (p.304) till Radar 2000 using Radio Frequency (RF) or RSSI of Wi-Fi to localize devices inside a building.

1.2.4 Bluetooth and BLE

Bluetooth® is a successful wireless technology standard for exchanging data over short distances (using short-wavelength Ultra high frequency (UHF) radio waves in the Industrial, Scientific and Medical Band (ISM) band from 2.4 to 2.485 GHz ). Bluetooth is useful to many applications, but it is power consuming. Therefore it has lead to introduce BLE which is the low power version of Bluetooth that was built for the Internet of Things (IoT) [6].

The power-efficiency of Bluetooth with low energy functionality makes it perfect for devices that run for long period on power source, such as coin cell batteries or energy-harvesting devices. Native support for Bluetooth-technology on every major operating system enables development for a broad range of connected devices – from home appliances and security systems to fitness monitors and proximity sensors. Apple introduced iBeacon back in 2013. This was a little device based on the BLE protocol. The main purpose is to advertise short compact messages like Service Set IDentifier (SSID) and extra information like major value, minor value, etc. In some of modern iBeacons (like the Estimote we use in our experiment) collect environment information such temperatures and accelerometer. With iBeacons it became possible for researchers and commercial companies to go in different direction with ideas, for example shinsuke and zhu use RSSI to calculate proximity distances to iBeacon, Mazan use Neural Networks and more recently, we see companies like Estimote [7], [8], Senion [9], Infsoft and other players promise indoor localization solutions with the use of iBeacons besides RFID technology. Furthermore, by combining iBeacons data with other sensor network data, it improves accuracy as described in Chen paper. Finally, by combining different type of sensors, we create an Indoor Position System (IPS).

If we take RFID for instance, RFID tags need a reader on every point where the position has to be determined. Since readers are relatively expensive, it is not possible to mount them across the whole building. Thus, it is only possible to determine the position at a few points.

iBeacons work with BLE, it means all modern smartphones are capable of receiving its signal, unlike RFID. This said, using RFID on all equipment’s and building area will end up being an expensive affair. We have made comparison chart 1.1 between RFID and iBeacons. In addition, challenges like costs, size and power consumption of tracker tag is highly considered in any object tracking solution.

RFID vs iBeacon
Table 1.1: RFID vs iBeacons comparison chart

1.3 The Problem

As mentioned in the previous section, RFID requires the proper infrastructure and deployment. Nowadays, almost everybody have a smartphone, that has a high number of built-in sensors (like accelerometer, gyroscope, compass, pressure, light etc.) and communication technologies (like Wi-Fi, Bluetooth, BLE, NFC, g3/g4 network, sms etc).

All modern smartphones has built-in BLE. As shown in RFID versus iBeacons comparison chart 1.1 BLE does not require infrastructure. This can be used on existing smartphones [10] with the proper application as localization system. The driver behind the use of iBeacon technology for the purpose of tracking objects in indoor environment lies in the long battery life (up to five years), the affordable price (around 10$) and how easy it is to deploy.

With a high amount of smartphones and cheap iBeacons, we raise the following questions:

  1. Can we use iBeacons for assets localization while relying on smartphones inside a building?
  2. What is the pros and cons of using iBeacons for asset tracking?

We will introduce and validate an approach to localizing assets and its historical overview of the past locations in an indoor environment.

1.4 Approach

In our context 1.1 we presented the idea of location systems in indoor environment using the Radio-frequency identification (RSSI) value from the iBeacons, which is a method already deployed for indoor localization by Zhu. In our approach, we want to find out how this is achievable, by designing and building an Indoor Equipment Localization System (IELS), a system that use iBeacons to localizing mobile objects in real indoor environment. We will evaluate it experimentally as use case in our testbed (PitLAB, 5th floor at IT University of Copenhagen).

1.5 Contribution

The main contribution of the project lies in the design, implementation and evaluation of a methodology for locating objects and tracking its moving history in an indoor environment. Throughout the years, an significant amount of research in the development of Indoor Localization System has been conducted. In these finding, we have found interesting approaches, but also product with no further technical details. This said, the rapid increase of the mobile market will leave a major opportunity for future

To continue…

[2] In this Thesis, we use iBeacon as name convention.
[10] smartphone with BLE technology

GuideBelt Project (IoT)


We see every day new technologies coming out to market but a few of those technologies are focused for people with special needs.

We have just finalized a research project called GuideBelt. It is simply a Bluetooth-based indoor navigation system for the visually impaired.bluetooth based indoor navigation system for the visually impaired

The GuideBelt, which is the product of this research, is such a solution that takes advantage of cheap Bluetooth beacons attached to places/objects of interest within an indoor space.

The implementation of the GuideBelt that has been the focus of this work is an early prototype, which uses phones to simulate the Bluetooth receivers (coupled with a vibration module). This was to allow us to focus on development of the algorithm rather than electronics. Therefore, the direction of this research is towards the implementation of the system with the actual technology necessary meaning with assembled electronic components (including Bluetooth modules and vibrators).

We have also wrote a research paper of our experiment that contains important details of the project.

We have made a little image site to present some images of the development:

We have also produced a video of the experiment:

Research and Development

  • Abdulrashid Mohammed
  • Maytham Fahmi
  • Tanase Comboeanu

Feedback for development
Thomas Pederson, Shahram Jalaliniya, Alexandre Alapetite

Technical support
Sebastian Büttrich

Birgit Christensen and all participants

Augmented Reality for doctors (IoT)

Hospital Journal

A project that enables doctors to see patience hospital journal virtually through augment reality, at the same time it is possible to navigate thought the journal with hand gesture.

Code only accessible for group members:

Read paper PDF: Hospital journal


Context Awareness Project (IoT)

Context awareness

In this paper we describe the concept, development and reflection for Pervasive Computing course (Spring 2015) at IT University of Copenhagen
where we built a context-aware mobile phone utilizing an iBeacon infrastructure.

Code available for group members

PDF download: ITU Contextphone platform