How and when is onBeaconsDiscovered called

I would like to understand how exactly RangingListener.onBeaconsDiscovered is called. Let's say I am using the default settings of setForegroundScanPeriod:1 second scan time, 0 wait time. Which of the following would be true:

a) onBeaconsDiscovered is called once every second, at the end of the scan period
b) onBeaconsDiscovered is called multiple times per second, as the scan is taking place and as beacons are discovered

If it's (a), does it pass the list of all beacons that were there at the end of the scan or all beacons that it found during the scan? And if it's (b), what's the frequency with which the method will be called?

Thank you.

Hi Mike—it's (a) and it's all beacons found during the scan period.

Thanks Piotr.


your Android API reports only one RSSI value per beacon. So can I assume that you guys do some averaging when a beacon is heard multiple times during the scan and only report that averaged value as the beacon RSSI?

As an example, let’s say onBeaconsDiscovered() returns every 1 second (as configured by the scan period) and beacon advertising interval is 250 ms. In a perfect setting, the phone should receive 4 packets from the beacon. Will the API average the RSSI of the four packets and report that when you call getRssi( )? If so, is there a way to get a more responsive reading every time a packet is heard instead of a periodic callback? If periodic callback is the only method you support, can I at least get a list of RSSIs for a given beacon that accumulate during the scan (with their timestamps) instead of one RSSI?

Thank you.

Yes, we’re doing some avging/filtering of the RSSI. Sadly, there’s currently no API that would give you access to raw data from every single detected packet—other than you going directly to the Android Bluetooth API, and detecting the beacon advertisements yourself.

Can you share what you want to use the raw data for?

@heypiotr, we would like to use raw data to implement our own filtering/averaging scheme.
Is the averaging behavior also implemented in your iOS API?
I am willing to go the iOS route if we can get per packet RSSI using your API there.

Yes, our iOS SDK is doing a similar thing.

I guess the best advice I can give at this time is to use the raw Android Bluetooth API / iOS Core Bluetooth API to do the packet discovery yourself. Then you have the full flexibility to do whatever you want (:

[note that on iOS, you can’t actually access the iBeacon packets via Core Bluetooth, Apple filters that out; you can only use Core Location, which is doing its own filtering/avging]

Thank you for the information Piotr.