Android Beacon Library - Long Search Time - ibeacon

Question

Update: I would still want advice as the start up time is still slow but reduced to about 10 seconds compared to 2 minutes.
As far as I understand, the default beacon search time is around once every 1.1 second for this library. However, despite setting my beacon broadcast frequency to 10Hz (I-Beacon) and 'didDetermineStateForRegion' reporting a detection of beacons coming into range, it takes about 1 minute for 'didEnter/ExitRegion' and the 'range notifier' to give me an alert that a beacon is in range / give me a list of beacons that are in range. After it starts giving me alerts of beacons entering into range, the response is great, at less than 0.5 seconds for a beacon that is turned on/off.
What are the possible reasons and solutions for the issue? I am trying to create an I-Beacon Attendance App. Many thanks.
*I also tried advices given from other posts like turning off Wifi to minimise interference.
Clement

Answer 1

The time it takes to detect a beacon in the background is largely derermined by how the phone scans in low power mode, combined with the beacon transmitter's advertising rate.
Android devices generally put BLE scans into low power mode when the screen is off. The Android Beacon Library does so explicitly when using BackgroundPowerSaver and the OS enforces this anyway on newer Android versions.
Low power mode means the BLE chip is commanded to use a duty cycle when scans are on. On open source Android, this is set to a 5120 ms interval with only 512 ms window of active scanning -- a 10% duty cycle. This saves battery by about 90% vs constant scanning, but it delays detections.
private static final int SCAN_MODE_LOW_POWER_WINDOW_MS = 512;
private static final int SCAN_MODE_LOW_POWER_INTERVAL_MS = 5120;
private static final int SCAN_MODE_BALANCED_WINDOW_MS = 1024;
private static final int SCAN_MODE_BALANCED_INTERVAL_MS = 4096;
private static final int SCAN_MODE_LOW_LATENCY_WINDOW_MS = 4096;
private static final int SCAN_MODE_LOW_LATENCY_INTERVAL_MS = 4096;
See here at AOSP
This is where the transmitter's advertising rate cones in. If the transmitter is advertising at 10Hz, there should be about 10 packets per second to detect. These are spaced randomly but on average one every 100ms. So you might usually be able to detect 4 packets during the 450 ms active scan window. In practice, you almost never detect that many as some are lost due to noise and collisions in radio space. At close range, and 80 percent receive rate is typical. At further ranges, the receive rate goes down further.
If a packet is detected in one scan interval under this scenario, the OS will get a callback on just under 5 seconds. If for some reason no packet is detected in the first scan window but is in the second, the callback will come in just over 9 seconds.
Improving this time means changing the scan interval to be smaller. On Android, you can only do this by changing the scan mode to high power as the window size is fixed by the OS. This usually means having the screen on.
The numbers above are for open source Android (e.g. Pixel phones). Some manufacturers (secretly) customize these settings. My testing suggests most Samsung devices with Android 6+ set the scan interval to 10 seconds with an unknown active scan duration. This means Samsung devices will give you about the results you describe even under the best conditions. Other manufacturers may vary. Getting the value for your manufacturer is impossible without the source code -- the only alternative is experimentation like you are doing.
Finally, do not confuse the Android Beacon Library's scanPeriod and betweenScanPeriod with the scan window/interval described above. While both have similar goals and effects, the OS scan window is not configurable and enforced at a much lower level, usually by the Bluetooth chip itself on newer devices.