Testing: One, two, three

We show how install and configure Jura in a real environment.


This weekend we have met up in order to perform some experiments, and taking advantage of this meeting we are going to show you how to install Jura.

First of all, we want to highlight the purpose of our meeting. The main goal is to discuss a tool that we want to develop in order to improve the experience with Jura. If you are not interested in it you can skip it and go to the next section.

Our proposal focuses on indoor positioning using BLE beacons. If you do not know how this is done you can review a previous post or even better this Degree’s Thesis. Usually, each beacon is located at a given point and they are scanned by devices that are in motion. As we explain here, we use the opposite scheme in order to be able to trust the scannings.


A common problem in indoor positioning using beacons is the noise (interferences in the environment, collisions in waves, surfaces with different reflection indexes, …). You can review the previous Degree’s Thesis for more information about that.

At the beginning of the challenge, we carried out several tests until we achieved a maximum error of two meters when positioning. This is enough for us because it allows knowing the rough position of each beacon. In a nursing home we could know the room in which each resident is located. If it is a medium-size room, we could also know the area in which area the resident is located.

How can we say that we are positioning with an error smaller than two meters? Because we did the following:

  1. We recorded datasets by placing a beacon at a given point. This evolved into Graba’s recording service.
  2. The scannings of the datasets were sent to the positioning service. This evolved into Graba’s player service.
  3. We computed the positioning error as the arithmetic means of the Euclidean distance between the real position and the one calculated by the service.

We think that it would be great to generalize this functionality because doing that anyone can test different scanners’ locations in order to fine-tune his/her installation and obtain better results. Today we have recorded some datasets using Graba. We will use them in order to test the tool that we want to develop.

Deployment of Kura

We have used the following hardware:

  • 3 x Raspberry Pi 3 Model B.
  • 1 x Raspberry Pi 2 Model B.
  • 1 x Up Squared.
  • 1 x Kindle fire.


The installation was configured as follows:

  • Four scanners of iBeacons (the four Rasps using Faro).
  • One Up Squared as a MQTT broker and Graba’s service.
  • One Kindle fire as an iBeacon.


First of all, it was necessary to install Kura (‘Raspbian (Model 2 or 3, No Net)’ for UP Squared), but not the official version, a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out that this is a failure of Kura or an incompatibility with our system we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy :).

After installing Kura we activated the MQTT broker in the Up Squared and later we connected all MQTT clients (Up Squared included) to the broker. This took a few minutes.

Deployment of Jura

First of all, we installed Faro in the four Raspberries, configuring them as iBeacon’s scanners.


From now on, Faro will publish any iBeacon that it detects, using MQTT.


As we explained in Faro’s post, in order to avoid the saturation of the MQTT broker, it sends messages periodically but including a chunk of all the detections obtained in the payload’s body. By doing this it is possible to get all transactions in return for a small delay, which is totally fine for our purpose.

At this point, the iBeacon’s scanners are ready. Let’s prepare Graba. In this case, we only install it in the Up Squared. As we indicated in Graba’s post, we have developed a React’s website in order to manage Graba’s services, so the creation of the iBeacon’s locations datasets is a very simple task.

Prior to showing an example of the process, it is necessary to indicate that the dataset only records the detections. Before creating the dataset it is necessary to manually measure the points where the scanners and the beacons are located. We know that it is a boring task, but there is no other option… Why do you think we are all together today? 🙂

On the positive side, creating a dataset using Graba’s web is as simple as this:


Deployment of Ubica

Although it is not necessary to use Ubica to create the datasets, we would like to show you how a Jura’s installation is defined using Ubica in order to give you a big picture of Jura.

As we said before, we have met in one of our homes, so be welcomed.


We made a plan of the room measuring tape in hand (for those worried about the details, it’s just for tests!) .


Next step, let’s install and configure Ubica in Up Squared.

Once we have installed it, we must define the installation. For this, it is necessary to indicate the points of the plan (in millimetres) and the locations of the scanners (also in millimetres). You can use ‘hcitool dev’ to get the bluetooth address of each device if you do not know it.

Where do we place the scanners? For our tests, there were located close to the power sockets. Ideally, they would be equally distributed around the room, close to the ceiling, away from possible sources of noise, …

This is our installation.


This is our plan (scanners’ locations are approximate).


And this is our configuration for Ubica’s installation service (scanners’ locations are accurate).


After that, the installation is ready (it’s simple, right?) and we finish this post. We will publish the results of the tests soon.

To conclude, we would like to tell you that, if you want to use Jura but this seems hard and unfriendly, you might be happy knowing the following. We have some experience developing Eclipse RCP and RAP applications and when the challenge began we started developing a RAP application to define plans, see positions, etc.

A picture is worth a thousand words.


Unfortunately, we have had to prioritise other parts, so we do not know if we will finish it someday or not. Who knows? Maybe for the Open IoT Challenge 5.0 😉

3 comments on “Testing: One, two, three”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s