【问题标题】:CoreBluetooth advertising detection timeCoreBluetooth 广告检测时间
【发布时间】:2023-03-19 07:51:01
【问题描述】:

早在 10 月 here 就已讨论过此问题。这是一个新问题,因为 CoreBluetooth 相当新,从那时起可能已经发生了一些变化。

我有一个 BLE 设备每 2 秒做一次广告。使用以下命令启动扫描:

[self.CM scanForPeripheralsWithServices:nil options:0]

在 2 到 4 秒后最常返回(通过 centralManager didDiscoverPeripheral 回调)。 (CM 是我的 CentralManger)

但是,大约 30% 的时间,扫描需要 10 到 18 秒。 附近设备中的 WiFi 和 BT 已被禁用,以尽可能清除频谱。 扫描时间似乎与 RSSI 无关。靠近 iPAd3 时为 -40dB,在另一个房间约 5 米外时为 -70dB。

[self.CM stopScan]; 

在 scanWithPeripherals 之前调用,因为它减少了真正长时间等待的发生。

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

有一个有用的 TI demonstrator app。 这给出了类似的结果(实际上稍微差一点,因为它没有进行任何 stopScan 调用)

CBCentralManagerScanOptionAllowDuplicatesKey 选项,如 Stackoverflow answer 中所示,如果有任何东西似乎会延长发现时间。

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

这是另一个有用的SO question,但没有详细说明响应时间。

【问题讨论】:

    标签: iphone ios bluetooth core-bluetooth bluetooth-lowenergy


    【解决方案1】:

    CoreBluetooth 没有连续收听。它与蓝牙经典和 Wifi 共享硬件资源。

    基本上你必须“幸运”才能收到广告包。 “幸运”是因为 2 个不同步系统的 2 个滑动窗口必须相互碰撞。 如果 CoreBluetooth 在 10% 的时间内打开它的 BLE 窗口,并且您在不知道确切时间的情况下设置了广告间隔,那么它将/可能需要 10 倍的广告间隔。

    一个建议是在前 30 秒(比如 20 毫秒,您应该在第一个活动的 CoreBluetooth 窗口中发现它)宣传 >fast

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

    第 18 页

    广告间隔 蓝牙配件的广告间隔要慎重考虑,因为它会影响时间 发现和连接性能。对于电池供电的配件,它的电池资源也应该是 经过考虑的。 要被苹果产品发现,蓝牙配件首先要使用推荐广告 间隔 20 毫秒,持续至少 30 秒。如果在最初的 30 秒内未发现,附件可能 选择节省电池电量并增加其广告间隔。 Apple 建议使用以下方法之一 更长的时间间隔以增加被 Apple 产品发现的机会:

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

    如果您必须节省电池,请尝试 1294 毫秒。

    【讨论】:

    • 谢谢亨利克。这是 WWDC 2012 的链接Advanced CoreBluetooth talk
    • 还有苹果的链接bluetooth-dev mailing list
    • iPad3 使用 Broadcom BC4330,它为 BT 和 Wifi 使用共享天线。查找一些驱动程序信息(甚至可能适用于 Android)或 BCM4330 用户手册/应用说明以查看我们所看到的是否是由底层硬件功能引起的会很有用。
    • “初始 30 秒”是什么意思?如果我的配件一直处于打开状态,则没有“初始”——任何进入范围并扫描配件的 iOS 设备都应该始终可以发现它。
    【解决方案2】:

    虽然这是一个旧线程,但我在 MacBook Pro(15 英寸,2017 年)上的 macOS High Sierra 10.13.3 中看到了同样的问题。问题因外围设备而异,“Apple TV”往往总是很快出现,可能是因为它的广告时间很短。一些外围设备需要很长时间才能显示或似乎根本不显示。此外,如果广告太慢,则连接也可能很慢,因为连接是通过首先找到一个广告并在之后的很短的固定时间响应它(外围设备在此期间正在侦听)而发生的。

    我找到了解决此问题的方法,即同时关闭 Wi-Fi 和 Handoff。一个人通过进入 Apple - System Preferences - General 并取消选中“Allow Handoff between this Mac and your iCloud devices”来关闭 Handoff。这不仅使扫描显示广告数据包的速度更快,连接速度更快,而且还显示更高(负值较小)的 RSSI,表示接收到的信号强度更强。

    请注意,该问题不会出现在 iOS 中,这可能是由于更好的 BT 和 Wi-Fi 共存支持以及切换(空投)和常规 BLE 使用之间的关系。该问题似乎只是扫描和连接期间 BLE 侦听时间的比例之一。建立连接后,似乎没有那么多干扰。部分原因是,在一个连接之后,在连接间隔之间会有自动的低级 BLE 重试和跳频。在扫描和建立连接(两者都依赖于查看广告数据包)期间,应该依次监视 3 个 BLE 广告通道,但 macOS 的行为就好像它没有这样做一样。从技术上讲,广告渠道与 Wi-Fi 渠道不重叠(请参阅http://www.argenox.com/a-ble-advertising-primer/)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2014-03-20
      • 2017-01-30
      • 1970-01-01
      • 2017-02-20
      • 2018-04-29
      • 2023-03-10
      • 1970-01-01
      相关资源
      最近更新 更多