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

implementation

Implementation

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 2.2.2.1, 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.

Leave a Reply

Your email address will not be published. Required fields are marked *