Estimote Beacons not heard at the beacon interval that it is set to

Using an Android App that scans for the Estimote beacons, we are not getting the number of readings as the beacon interval we have set the beacon to.
For example, we set few beacons to transmit at 100ms, but when we collect the data from these beacons, some of them give reading at 100ms and some are only giving few readings – mostly at 2000ms frequency. But we are definite that we set the beacon interval to 100ms and synced it using the Estimote iOS App for all the beacons. We have about 200 beacons in our lab. We are not able to understand the reason behind this. Kindly assist!

Hi Meeralakshmi,

This behavior is to be expected. Advertising Interval describes how often beacons broadcast new data packets. But not all data packets will be delivered to the phone. It’s all about radio wave propagation, and waves can be absorbed, bounce of walls, or diffract. Long story short: you should always expect some data packets to be lost. Achieving 100% reception in real world scenario is not possible.

Cheers.

I understand that 100% reception is not possible. But if the beacon interval is set to 100ms, shouldn’t it transmit at somewhat similar frequency at least some point of time? Instead we always get a response at 2000ms certain beacons, while the others deployed at similar conditions behave normally.

We also observed that the beacon is giving cached data values (RSSI) from few second back – is this also an expected behavior?

Advertising interval, i.e., the frequency with which beacons broadcast is one thing.

How often the phone scans and delivers scanning results is another, and this is what you’re seeing here. You can influence that to a degree using the setForegroundScanPeriod method (you how long the phone is scanning, and how long it waits between scans), but since our SDK uses hardware-accelerated Bluetooth scanning on capable devices, ultimately it’s up to the Bluetooth chip itself how often it returns scanning results. (e.g., if no new beacons came in range, the Bluetooth chip might decide to delay returning scan results to conserve the phone’s battery and CPU cycles.)

Also, since you’re observing “cached” RSSIs, this means that your phone didn’t actually detect any change in the RSSI value and that’s why you’re getting “cached” values. Which means that making the scan periods more aggressive won’t help, because it looks like your hardware isn’t sensitive/responsive enough anyway. (What device is that? And what’s the Android version?)

EDIT: Just learned that we have an interesting change in ranging implementation coming in the next Android SDK release, which might improve ranging’s responsiveness. I recommend subscribing to our Android SDK repo and keeping an eye for that!

Thanks for the reply.

Our device is now set to scan continuously for about 10 minutes without any scan interval and duty cycle. This is because our individual experiments are running only for few seconds and we want the device to scan throughout.

We are using the LG Urbane Smartwatch to do the BLE scanning. The android version is 6.0.1. May be the hardware isn’t sensitive enough, like you said.

Hello. I have a question regarding the BLE low energy scanning, cached values that follows up on this topic.

I have the following setup:
Broadcast on stickers 5000ms when still // 2500ms when active.
Receiver scan period: 500ms, no sleep period.

To my knowledge BLE signals are transmitted for a duration of 1s? So this would be the transmitter broadcasts every 5000ms for a duration of 1s.

Now to be sure I sample fast enough, I have a set my receiver to not sleep, and to scan for packages in durations corresponding to the Nyquist frequency.

mBeaconManager.setForegroundScanPeriod(500, 0);
mBeaconManager.setBackgroundScanPeriod(500, 0);

With the current setup I expect to sometimes scan the same broadcast twice, however it seems that I get values at my receiver roughly twice every seconds, however often they are similar (cached probably). Can someone help me understand what is happening? I would expect double values everytime the beacon broadcasts (so roughly once every 5s), however I’m getting data at the receiver twice every 2s.

Is the SDK/BLE scanner using cached values for a set period? Meaning if I receive a package, and I keep scanning in a period after that, it will still used the last packages cached values for a certain interval even though I do not receive data?