Hello community. I did set up 3 beacons in one room (10m x 22m). What I would like to do now is show to the user if he/she is within ~3 to 4 meters from a certain beacon. I first tried to implement this myself, then I saw the proximity template and tried that one too. They both give me fluctuating results. The beacons do not get recognized all the time and the ‘in range beacon’ changes while the phone is laying still. The beacons are configured with the following settings: adv. interval 256 ms, TxPower; -20dbm (~3.5m). The beacons are about 6 meters apart from each other. The receiver is setup to scan every 500ms seconds for beacons. I have two questions. First of all, why do sometimes none of the beacons get recognized, while the receiving end scans every 500ms and the adv interval is 250ms? Secondly, why do not all beacons that are nearby show up in the same scan? Now I need to track old measurements and add some kind of delay interval determine to which of the beacons, the user is closer.
You need to keep packet loss in mind: the further away from the beacon you are, the more packets get lost.
Sound is a good analogy: the further away you are from the sound source, the bigger the distortion and the fainter the sound. At some point, the sound just fades away completely, and that’s what you could consider the “maximum range” of that sound source.
Same with beacons: range is not some magical number where, if you move slightly closer to the beacon, you suddenly start detecting all the packets, and if you move slightly away, you stop detecting them. Instead, the change is gradual—first you start dropping 50% of the packets, then 75%, and then at some point the packet loss is so big that it’s considered “the maximum range”.
So, even if you set your beacons to 250 ms, you will very rarely consistently detect every single packet. Your receiving device’s sensitivity also plays a huge role here—especially with Android devices, some are much less sensitive than others.
You could try further decreasing the adv interval, and increase the scanning window, to more consistently detect all of the beacons in range. Or, go the “track old measurements” route as you mentioned.
Thank you for the given explanation. Is there an approximate distance versus packet loss ratio? Even if I hold my phone about one meter from a certain beacon, I do not get consistent packages.
This very much depends on (a) the quality/sensitivity of the receiver, and (b) the amount of interference in your environment. In a relatively “quiet” environment and with an iPhone, at 1 m, we would expect packet loss closer to zero. If you have many other BLE devices nearby, or WiFi access points set to channels that collide with BLE channels, then there will be many collisions and the packet loss will grow.
Thank you for this information. I will try to test and create a few graphs to indicate the packet loss in a more “quiet” environment and in a very “noisy” office which I am testing in. The environment I am testing in consists out of many laptops (with bluetooth) / tv’s with bluetooth / wifi coverage and the mentioned 6 beacons. Would it be possible that this increases the package loss so much that I only receive a package every 3 - 10 seconds or is this gap way to big and do I need to look at other reasons why I do not receive many packages?
I did quite some tests these last days. It seemed that the only receiving a few packages every 3 seconds was caused by another library (AltBeacon) that I was using. Now I am using the estimote sdk and it seems to be better. I am able to measure beacons with a rate of 500ms using the estimote sdk. However, every 30 seconds (not a constant number), the packages stop coming in for about 10 seconds, then they start coming in again. Could it be that there is some kind of throttle in the Android SDK? The light blue line shows one of these examples where the packages just drop to 0 around 65. The horizontal axis shows the time from the start of the measurement, the vertical axis shows the distance estimated by the device.
This is the code that I am using.
> beaconManager.setRangingListener(new BeaconManager.RangingListener() {
@Override
public void onBeaconsDiscovered(Region region, final List<Beacon> rangedBeacons) {
if(rangedBeacons.size() > 0) {
Calendar c = Calendar.getInstance();
String time = iso8601Format.format(c.getTime());
for (Beacon b : rangedBeacons) {
sendDistanceToServer(b, time, getProximityName(Utils.computeAccuracy(b)));
}
}
}
});
beaconManager.connect(new BeaconManager.ServiceReadyCallback() {
@Override
public void onServiceReady() {
beaconManager.setForegroundScanPeriod(500l, 0l);
beaconManager.startRanging(ALL_ESTIMOTE_BEACONS_REGION);
}
});
Hmm, we’re definitely not doing any throttling. Maybe your device’s Bluetooth stack overflows or something, and needs to reboot itself? If you try less aggressive scan periods, do you also experience this drop, or is the experience more stable then?
@heypiotr Thank you for your answer (again). I tried to set the scanning period to 1s but with the same result. Although I have to admit that I am testing with a different device now.
Next to the interval of incoming packages, the beacons are also not recognized all the time. Sometimes they just do not show up on my scanner, even though I am next to them. Could it be that this is a receiver problem? When I range with multiple Android phones, the beacon shows up on 1 of them and not on the other two. Is this also something that you have noticed? I am trying to rule out all of the variables .
You can post what exact devices you’re using, then I’ll be able to tell if we know how responsive they are (: From our experience, Android devices sport tremendous differences in how reliable/responsive they are to beacons.
