This issue has been discussed back in October here. This is a new question as CoreBluetooth is fairly new and some changes might have occurred since then.
I have a BLE device advertising every 2 seconds. Scanning is initiated using:
[self.CM scanForPeripheralsWithServices:nil options:0]
Which returns most often (via the centralManager didDiscoverPeripheral callback) around 2s to 4s later. (CM is my CentralManger)
However, about 30% of the time, the scan takes 10 to 18 seconds.
WiFi and BT in nearby devices has been disabled to clear the spectrum as much as possible.
The time to scan seems unrelated to RSSI. Which is -40dB when next to the iPAd3, -70dB when about 5 metres away in another room.
[self.CM stopScan];
is called before the scanWithPeripherals as it reduces the occurrence of really long waits.
No connection is being made. No characteristic or services data is being requested. Advertising data is sufficient.
There is a useful TI demonstrator app.
This gives similar results (actually slightly worse as it doesn’t make any stopScan calls)
The CBCentralManagerScanOptionAllowDuplicatesKey option as seen in this Stackoverflow answer if anything seems to lengthen discovery times.
Obviously, the next step is to use some more advanced BT sniffer / advert generation tools to further characterise this CoreBluetooth response.
This is another useful SO question, but does not elaborate enough on response times.
The CoreBluetooth isn’t listening continuously. It is sharing HW resources with bluetooth classic and Wifi.
Basically you must be “Lucky” to receive the advertisement package.
“Lucky” as in that the 2 sliding windows of the 2 unsynchronised systems must hit each other.
If CoreBluetooth opens it’s BLE window 10% of the time and you have set the advertisement interval without knowledge about the exact timing then it will/can take 10 times the advertisement interval.
One recommendation is to advertise >fast< for the first 30 seconds (say 20ms and you should discover it in the first active CoreBluetooth window) and then slow down to intervals specified by Apple. 2,00 seconds is NOT a good number.
See guideline here:
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Page 18
Advertising Interval
The advertising interval of the Bluetooth accessory should be carefully considered, because it affects the time
to discovery and connect performance. For a battery-powered accessory, its battery resources should also be
considered.
To be discovered by the Apple product, the Bluetooth accessory should first use the recommended advertising
interval of 20 ms for at least 30 seconds. If it is not discovered within the initial 30 seconds, the accessory may
choose to save battery power and increase its advertising interval. Apple recommends using one of the following
longer intervals to increase chances of discovery by the Apple product:
645 ms
768 ms
961 ms
1065 ms
1294 ms
So try 1294 ms if you must save battery.