7

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.

Community
  • 1
  • 1
Nick T
  • 897
  • 8
  • 30

2 Answers2

13

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.

henrik
  • 1,312
  • 9
  • 9
  • Thanks Henrik. Here is a link to the WWDC 2012 [Advanced CoreBluetooth talk](http://www.pupuweb.com/blog/wwdc-2012-session-705-advanced-core-bluetooth-joakim-linde/). – Nick T Jan 01 '13 at 12:17
  • And a link to the Apple [bluetooth-dev mailing list](http://lists.apple.com/archives/bluetooth-dev/) – Nick T Jan 01 '13 at 12:17
  • iPad3 uses the Broadcom [BC4330](http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330) which uses a shared antenna for BT and Wifi. It would be useful to find some driver information (maybe even for Android) or a BCM4330 user manual / application note to see if what we are witnessing is caused by underlying hardware capability. – Nick T Jan 01 '13 at 20:30
  • What do they mean by "initial 30 seconds"? If my accessory is turned on all the time, there is no "initial" - it should be discoverable all the time by any iOS device that gets in range and scans for accessories. – JustAMartin Mar 01 '17 at 21:11
0

Though this is an old thread, I see the same problem in macOS High Sierra 10.13.3 on my MacBook Pro (15-inch, 2017). The problem varies by peripheral device where "Apple TV" tends to always show up quickly, perhaps because it has a short advertising time. Some peripherals take a long time to show up or do not seem to show up at all. Also, if advertising is too slow, then connecting also can be slow since connection occurs by first finding an advertisement and responding to it at a very short fixed time afterwards (the peripheral is listening during that time).

I found a workaround for this problem which is to turn off BOTH Wi-Fi and Handoff. One turns off Handoff by going into Apple - System Preferences - General and unchecking "Allow Handoff between this Mac and your iCloud devices". Not only does this make scans show up advertising packets more quickly and connections be faster, it also shows a higher (less negative) RSSI representing a stronger signal strength being received.

Note that the problem does not show up in iOS, possibly due to better BT and Wi-Fi co-existence support and between Handoff (Airdrop) and regular BLE usage. The issue appears to only be one of the proportion of BLE listening time during scan and connect. Once a connection is established, there does not appear to be as much interference. In part, this is due to the fact that after one connects there are automatic low-level BLE retries and frequency hopping between connection intervals. During scanning and establishing a connection (both of which rely on seeing advertising packets) one should be sequentially monitoring the 3 BLE advertising channels but macOS behaves as if it is not doing that. Technically, the advertising channels do not overlap with the Wi-Fi channels (see http://www.argenox.com/a-ble-advertising-primer/).

user4028
  • 164
  • 1
  • 3