核心蓝牙广播检测时间

7

这个问题在十月份已经被讨论过了,链接。由于CoreBluetooth是相对较新的技术,自那时以来可能发生了一些变化,所以这是一个新问题。

我有一个每2秒广告的BLE设备。扫描是通过以下方式启动的:

[self.CM scanForPeripheralsWithServices:nil options:0]

这段代码通过中央管理器 (CentralManager) 的 didDiscoverPeripheral 回调函数返回一个结果,通常需要2到4秒的时间。

然而,约30%的情况下,扫描需要10到18秒的时间。附近设备的WiFi和蓝牙已被禁用以尽可能清除频谱干扰。扫描时间似乎与RSSI(接收信号强度指示)无关,在与iPAd3相邻时为-40dB,在另一房间约5米远时为-70dB。

[self.CM stopScan]; 

在 scanWithPeripherals 之前,需要调用这个函数,以减少长时间等待的发生。

没有建立连接,也没有请求任何特征或服务数据。广告数据就足够了。

有一个TI的演示应用程序非常有用。它可以提供类似的结果(实际上稍微差一些,因为它没有进行任何 stopScan 调用)。

CBCentralManagerScanOptionAllowDuplicatesKey 选项在这个 Stackoverflow 回答中提到,如果使用该选项反而会延长发现时间。

显然,下一步是使用一些更高级的 BT 嗅探器 / 广告生成工具来进一步表征这个 CoreBluetooth 响应。

这是另一个有用的 SO 问题,但对响应时间的解释不够详细。

2个回答

13

CoreBluetooth不会持续监听,它与蓝牙经典和Wifi共享硬件资源。

基本上你必须要"幸运"才能收到广告包。 "幸运"是指未同步的两个系统的两个滑动窗口必须相遇。 如果CoreBluetooth打开其BLE窗口的时间占总时间的10%,而您设置了广告间隔而不知道确切的时间,则将需要10倍的广告间隔时间。

一个建议是在前30秒内以较快的速度进行广告(例如20毫秒),您应该可以在第一个活动的CoreBluetooth窗口中发现它,然后降低到由Apple指定的间隔。 2.00秒不是一个好数字。

请参阅此处的指南: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

第18页

广告间隔 应仔细考虑蓝牙配件的广告间隔,因为它会影响发现时间和连接性能。对于电池供电的配件,还应考虑其电池资源。 为了被Apple产品发现,蓝牙配件应首先使用推荐的广告间隔20毫秒,持续至少30秒。如果未在最初的30秒内发现,则配件可以选择节省电力并增加其广告间隔。Apple建议使用以下较长的时间间隔之一以增加被Apple产品发现的机会:

645毫秒 768毫秒 961毫秒 1065毫秒 1294毫秒

因此,如果必须节省电池,请尝试使用1294毫秒。


谢谢 Henrik。这是 WWDC 2012 Advanced CoreBluetooth talk 的链接。 - Nick T
并附上到苹果蓝牙-dev邮件列表的链接。 - Nick T
iPad3使用Broadcom BC4330,该芯片使用共享天线进行蓝牙和Wifi连接。查找一些驱动程序信息(甚至是针对Android的)或BCM4330用户手册/应用说明将非常有用,以确定我们所见到的问题是否由底层硬件能力引起。 - Nick T
他们所说的“最初的30秒”是什么意思?如果我的配件一直开着,就没有“最初”的概念 - 任何进入范围并扫描配件的iOS设备都应该能够随时发现它。 - JustAMartin

0

虽然这是一个旧的帖子,但我在我的MacBook Pro(15英寸,2017)上看到了macOS High Sierra 10.13.3中相同的问题。该问题因外围设备而异,其中“Apple TV”往往会很快出现,可能是因为它有短的广告时间。有些外围设备需要很长时间才能显示出来,或者似乎根本没有显示出来。此外,如果广告速度太慢,则连接也可能很慢,因为连接是通过首先找到广告并在非常短的固定时间后响应它来进行的(在此期间外围设备正在侦听)。

我发现了一个解决这个问题的方法,那就是关闭Wi-Fi和Handoff。通过进入苹果-系统偏好设置-通用并取消选中“允许在此Mac和您的iCloud设备之间使用Handoff”,可以关闭Handoff。这不仅使扫描更快地显示广告数据包并且连接更快,还显示更高(较少负面)的RSSI,表示接收到更强的信号强度。

请注意,该问题在iOS上不会出现,可能是由于更好的蓝牙和Wi-Fi共存支持以及Handoff(Airdrop)和常规BLE使用之间的差异。该问题似乎只涉及扫描和连接期间BLE监听时间的比例。一旦建立连接,干扰就不会那么严重。部分原因是因为连接后会自动进行低级别BLE重试,并在连接间隔之间进行频率跳变。在扫描和建立连接期间(两者都依赖于看到广告包),应该按顺序监视3个BLE广告通道,但macOS的行为却不像这样。从技术上讲,广告通道不会与Wi-Fi通道重叠(请参见http://www.argenox.com/a-ble-advertising-primer/)。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接