Stale ranges in onBeaconsDiscovered

BLE Beacons
1

It seems that onBeaconsDiscovered returns stale ranges in the period between when a beacon physically goes out of range, but before the 30 second limit which the Estimote SDK enforces before onExitedRegion is called.

e.g Here’s a trace printing Utils.computeAccuracy. Half way through I turn over the beacon to disable it, but onBeaconsDiscovered continues to be called with stale data until the timeout has elapsed. (You can see the value freeze at 0.044655883777718224)


12-16 15:53:46.549: Range to beacon: 2.1656211825380707
12-16 15:53:48.284: Range to beacon: 1.4231323591700062
12-16 15:53:50.334: Range to beacon: 1.4231323591700062
12-16 15:53:52.287: Range to beacon: 0.2918833943147302
12-16 15:53:56.464: Range to beacon: 0.08566693304992186
12-16 15:53:58.354: Range to beacon: 0.044655883777718224
12-16 15:54:00.257: Range to beacon: 0.044655883777718224
12-16 15:54:02.507: Range to beacon: 0.044655883777718224
12-16 15:54:04.474: Range to beacon: 0.044655883777718224
12-16 15:54:05.574: Range to beacon: 0.044655883777718224
12-16 15:54:06.588: Range to beacon: 0.044655883777718224
12-16 15:54:09.605: Range to beacon: 0.044655883777718224

My question is, is there any way to exclude these stale values? If there is no real data I’d prefer if onBeaconsDiscovered wasn’t called, or that I had some way to tell that the data was fake / stale.

2

This is actually by design. It often happens that a beacon is temporarily not seen (due to environmental factors, and also, Bluetooth packets just sometimes get lost), and we didn’t want to leave out gaps in the ranging result, triggering any false alarms. In such case, we serve “cached,” “last-seen” data.

I understand however that sometimes, it’d be beneficial to disable this “cache.” We’ll see if we can add a configuration option for that.