Eddystone wrong results

[hadiidbouk]

Does this Library has been tested with Eddystone beacons ?

I am getting wrong location when i choose Eddystone protocol to my Kontakt beacon.

For Kontakt there is different values of RSSI :

Tx Power            RSSI for ibeacon @ 1m             RSSI for Eddystone @ 0m

0 (-30dBm)                -115                           -74
1 (-20dBm)                -84                            -43
2 (-16dBm)                -81                            -40
3 (-12dBm)                -77                            -36
4 (-8dBm)                 -72                            -31
5 (-4dBm)                 -69                            -28
6 (0dBm)                  -65                            -24
7 (4dBm)                  -59                            -18

Why all the locations are so far when using Eddystone and when i use iBeacon everything works fine ?

[Steppschuh]

I would assume that this is a calibration related issue. The Beacon class has two fields for calibration, calibratedDistance and calibratedRssi.

calibratedDistance is 1 meter for iBeacon and 0 meters for Eddystone (as stated in the table you posted) by default. The calibratedRssi is advertised by the beacons and can be adjusted for calibration. Chances are that your beacons are not calibrated correctly.

It could also be possible that the actual distance calculation is flawed. You can find the implementation in BeaconDistanceCalculator.calculateDistance(...).

[hadiidbouk]

The problem here, that with Eddystone the calibratedRssi is never calculated.

You need to get it from the Eddystone advertising data, for UID, EID and URL, the calibratedRssi is at byte index 1 ( if your data is only the Eddystone Frame), or if you are detecting all the advertising data the calibratedRssi will be at index 9.

You should override the applyPropertiesFromAdvertisingPacket method like you did with IBeacon.

@Override
public void applyPropertiesFromAdvertisingPacket(P advertisingPacket) {
    super.applyPropertiesFromAdvertisingPacket(advertisingPacket);
}

However when you choose Eddystone rather than IBeacon the Multilateration RMS return a bigger value then the expected.

these values below should be changed when we use Eddystone

public static final int ROOT_MEAN_SQUARE_THRESHOLD_STRICT = 5;
public static final int ROOT_MEAN_SQUARE_THRESHOLD_MEDIUM = 10;
public static final int ROOT_MEAN_SQUARE_THRESHOLD_LIGHT = 25;

[Steppschuh]

Thanks for the detailed explanation! May I ask what values you are setting for the calibratedRssi? It should be the RSSI you measured for your beacons at 0m distance.

That value will be used in calculateDistance, plus the SIGNAL_LOSS_AT_ONE_METER . You can find the implementation here.

Either the SIGNAL_LOSS_AT_ONE_METER or the calibratedRssi seems to not be correct, otherwise the root mean square error thresholds of the multilateration would not need to be adjusted. The higher RMS indicates that the distance calculation is flawed.

[hadiidbouk]

The calibratedRssi (which it should be renamed measuredPower in my opinion) value is -36 since I am using the default Tx Power (3) from Kontakt io.

I have checked the distance calculation and the result seems fine (sure it depends on the RSSI).

The problem is the square error thresholds values should be changed for Eddystone.

[Steppschuh]

Changing the thresholds means accepting more errors in the equation system. That does not resolve the issue, it just hides it.

Multilateration doesn't depend on the beacon you use. It just accepts distances. The fact that it produces larger errors for your Eddystone beacons means that either the distance calculation or the beacons calibration is flawed.

Regarding the naming of calibratedRssi vs measuredPower: Different companies have different names for them (e.g. Kontakt.io Reference RSSI or Estimote Measured Power). I agree that measuredPower would also be a good fit, but for consistency we named all received signal power values RSSI.

[Steppschuh]

Regardless of the table that said -36 would be the correct value, please measure the RSSI at 0m with the device that you are testing on. It's probably different.

Different devices will receive advertising frames with very different signal strengths (because of their housing, placement of the BT radio antenna, ...). See RSSI Measurements for details. This is something we want to compensate for, I created issue #127 for that.

[hadiidbouk]

Yes, it's around -45, and on another device, it's -62 any reason why?

[Steppschuh]

As stated above (edited, you might have read it before the edit):

Different devices will receive advertising frames with very different signal strengths (because of their housing, placement of the BT radio antenna, ...). See RSSI Measurements for details. This is something we want to compensate for, I created issue #127 for that.

[hadiidbouk]

Different devices will receive advertising frames with very different signal strengths (because of their housing, placement of the BT radio antenna, ...)

So I am getting very different distances => very different root mean square => thresholds values are not accurate.

Some devices may never receive a new locations if a developer choose one of the 3 thresholds.

[Steppschuh]

I see your point. I just think that the issue we need to fix is the distance estimation, not the multilateration (and the RMS thresholds). Adjusting the thresholds is a "temporary" workaround.

[hadiidbouk]

I am totally agree on this, but please read the comment on the other issue #127