Radius Networks' ibeacon ranging fluctuation

Question

I'm fairly new to iBeacon but I have spent the day trying to get informations and a working Android application with iBeacon.

I have stumbled upon Android iBeacon Library samples and gave it a try. I used the latest aar file (0.7.3) and basically copy/paste their examples in a new project. I have created a beacon using an iPad with AirLocate (compiled from Apple's code from the Dev Center) and launch the code.

My problem is the range fluctuating all the time with no logic. For example, the phone (in this case a Nexus 5, original rom, no modification) placed half a meter away from the iPad gives me the following measures :

• 0.01m
• 0.03m
• 0.07m
• 0.48m
• 0.01m
• 0.02m

etc.

When I use another iPad with AirLocate on it, it gives a more stable and realistic measure. Excluding the beacon as the source of the problem.

I have made the test with a Nexus 7 2013 (Original rom, not modified) and I got the same issue. I have read the wifi can cause problem so I disabled it but it is still the same. I also have the same issue with Radius Networks application on the Play Store: iBeacon Locate

I was wondering if the anyone else have the problem with this library ? Is there something I can do to help fix this problem ? Do you know another library I can use which won't cause that kind of problem ?

Any help is appreciate. Thank you in advance.

Mckibben

Answer 1

A big part of the variation you see is Android is caused by a limitation in the way Android allows access signal strength measurements from Bluetooth LE. Unfortunately, there isn't much that can be done about this without changes to Android.

In both iOS CoreLocation and the Android iBeacon Library, the distance estimate is only an estimate, and fluctuations with noise on signal strength measurements cause the estimates to bounce around.

The algorithm in the Android iBeacon Library is not the same as in iOS CoreLocation, because the iOS CoreLocation implementation is closed source. The intention is that they behave in a similar way. The Android iBeacon Library is based on a 10 second running average of 80th percentile measurements (e.g. the top and bottom 10th percentile measurements are thrown away for the average.) You can see the details of the calculation here:

protected static double calculateAccuracy(int txPower, double rssi) {
  if (rssi == 0) {
    return -1.0; // if we cannot determine accuracy, return -1.
  }

  double ratio = rssi*1.0/txPower;
  if (ratio < 1.0) {
    return Math.pow(ratio,10);
  }
  else {
    double accuracy =  (0.89976)*Math.pow(ratio,7.7095) + 0.111;    
    return accuracy;
  }
}   

On Android, the Bluetooth LE Scan API only allows a single signal strength measurement per scan. On iOS, it is possible to get a different measurement for each advertisement broadcasted. By default, the Android iBeacon Library does one bluetooth scan every 1.1 seconds when it is in the foreground, therefore allowing one measurement every 1.1 seconds. So if you have an iBeacon that is transmitting 30 times per second (as iOS devices acting as iBeacons do), iOS will be able to get 300 samples in a 10 second period, and Android only 9. This explains why the estimate has higher noise on Android. And again, there is very little that can be done about it without operating system changes.

Depending on your use case, you may be able to reduce the noise in the distance estimate on Android by implementing a custom calculation that includes more samples over a longer period of time. This would only be appropriate if your use case does not need rapid updates in the estimate. If you are interested in this, you might open a feature request in the open source library.

Dumortierite

Thank you for your answer, this makes it a bit more clear about what is going on. Yet, when I go further with my devices (let's say 10m away), I've got very big variations from 1m to 20m measured. Is that normal ? Should I have such important variation ? – Mckibben

Sorry for double commenting this, I cannot edit my last comment. For your information here is a graph of the accuracy over time, I was standing still with my Nexus 5, 3 meters away from the ipad mini broadcasting as an ibeacon. imgur.com/dG7NYi2 – Mckibben

It is normal for variation to increase with distance. The graph does look like a little more variation than I typically see at 3m, but this could be caused by reflections in your test location or other factors. If you want to drill into this more, also plot the rssi alongside the distance from iBeacon.getRssi(). – Dumortierite

Great answer, thanks @davidgyoung. We'd seen this issue with both yours and Estimote's Android SDKs and assumed it must've been something to do with how Android surfaces the RSSI. Really good clarification. – Simplify

what should be the value of "sampleExpirationMilliseconds" if a user is moving say in a car?As I read in the docs,"20 secs may not be appropriate for cases where fast responses in distance estimates are expected." – Walk

Remember that the range of a BLE device is < 50 meters. If a vehicle is moving at 100 kilometers per hour (~27 meters per second), you will get at most 2 seconds worth of samples while the beacon is in range. A sampleExpirationMilliseconds of 2000 might work, but because it is based on so few samples for averaging, there will be lots of noise error on the distance estimate. – Dumortierite

ok.So will ARMA filter give me better results if the vehicle speed is 2-15kmph? – Walk

The time interval is more deterministic with the default filter, so I do not think the ARMA filter would give better results in this case. This is really a new question, so if you have follow-ups please open a new one instead of using comments. – Dumortierite

I have opened a new thread #31745869 – Walk