Les temps de détection du scan CoreBluetooth ne sont pas fiables sous MacOS

Question

Lors de la recherche de publicités de fabricants BluetoothLE sur MacOS, les rappels de découverte sont beaucoup moins fréquents que sur iOS. Pour un émetteur qui fait de la publicité à 10 Hz, iOS reçoit près de 10 rappels de découverte par seconde. Sur MacOS, il est typique de voir 1-3 rappels par seconde, mais parfois il peut y avoir plusieurs secondes entre les rappels - quelques fois j'ai mesuré plus de 90 secondes entre les détections ! Vous trouverez ci-dessous un graphique montrant le nombre de secondes entre les découvertes au cours d'un test d'environ deux heures.

Pourquoi les temps de découverte sont-ils si imprévisibles sur MacOS par rapport à iOS ? Existe-t-il un moyen de rendre les callbacks plus fiables ?

J'ai enregistré ces données sous macOS Sierra 10.12.6 sur un MacBook Pro (Retina, 15 pouces, mi 2014) mais j'ai entendu des collègues se plaindre d'un manque de fiabilité similaire sur des MacBooks plus récents.

centralManager = CBCentralManager(delegate: self, 
                                  queue: DispatchQueue.global(qos: .default))
centralManager.scanForPeripherals(withServices: nil, 
                                  options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

...

func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
            let secsSinceDetection = Date().timeIntervalSince(self.lastDetectionTime)
            lastDetectionTime = Date()
            NSLog("LDT: \(secsSinceDetection))")
}

Answer 1

Je constate le même problème avec macOS High Sierra 10.13.3 sur un MacBook Pro (15 pouces, 2017). Même l'application Bluetooth Explorer d'Apple (qui fait partie de Hardware IO Tools) présente le même problème.

Certains périphériques sont plus affectés que d'autres. L'Apple TV semble toujours s'afficher très rapidement alors que d'autres périphériques sont plus lents ou ne s'affichent pas du tout.

Voir la réponse à la question connexe ici : Temps de détection de la publicité CoreBluetooth où apparemment CoreBluetooth n'est pas en écoute permanente et partage une antenne et des ressources avec le Wi-Fi et le Bluetooth ordinaire. Je pensais initialement que le fait de désactiver à la fois le Wi-Fi et le "Handoff" améliorait la capacité à voir les publicités et réduisait le temps de connexion. Le "Handoff" est désactivé dans Apple - Préférences Système - Général en décochant "Autoriser le Handoff entre ce Mac et vos appareils iCloud", mais cela peut ne pas être vrai.

Notez que le problème n'apparaît pas dans iOS, peut-être en raison d'une meilleure prise en charge de la coexistence BT et Wi-Fi et de la distinction entre le Handoff (Airdrop) et l'utilisation régulière de la BLE. Le problème ne semble concerner que la proportion du temps d'écoute BLE pendant la recherche et la connexion. Une fois la connexion établie, il ne semble pas y avoir autant d'interférences. Cela est dû en partie au fait qu'après une connexion, il y a des tentatives BLE automatiques de bas niveau et des sauts de fréquence entre les intervalles de connexion fixes. Au cours du balayage et de l'établissement d'une connexion (qui dépendent tous deux de la réception de paquets publicitaires), on parcourt séquentiellement les trois canaux publicitaires BLE à chaque intervalle de balayage. Techniquement, les canaux publicitaires ne se chevauchent pas avec le Wi-Fi (voir http://www.argenox.com/a-ble-advertising-primer/ ).

[Après des tests plus approfondis, il semble que le problème avec macOS ne soit pas tant dû aux interférences du Wi-Fi ou de Handoff, mais plutôt au fait que les paramètres scanWindow et scanInterval se comportent davantage comme le fonctionnement d'iOS en arrière-plan. Étant donné que pour certains périphériques, il faut parfois jusqu'à 1,5 minute pour être trouvé, un rapport 30/300 avec 1 seconde de publicité et jusqu'à 10 ms de décalage aléatoire (donc 5 ms comme décalage moyen) pourrait prendre (300-30)/5 = 54 intervalles (secondes) pour être détecté si le périphérique ne suit pas les directives d'intervalle de publicité d'Apple qui sont intentionnellement éloignées des multiples de 300 ms et avec un peu de malchance sur les décalages aléatoires pourrait être un peu plus long, ce qui est à peu près ce qui semble être vu. Malheureusement, je n'ai pas trouvé de moyen de forcer macOS à utiliser un rapport scanWindow/scanInterval plus élevé, similaire à celui du premier plan d'iOS.

[Si l'on suit le temps de 1022,5 ms annoncé par Apple dans le périphérique, même avec iOS en arrière-plan ou macOS avec scanWindow de 30 ms et scanInterval de 300 ms, le temps médian est d'environ 5 secondes, tandis que le maximum est d'environ 19 secondes, ce qui pourrait être un peu plus long avec une très mauvaise chance pour les décalages aléatoires de 0-10 ms.