连接第二个 BLE 设备后 BLE 响应时间变慢

Posted 2023-02-19

【中文标题】连接第二个 BLE 设备后 BLE 响应时间变慢

【英文标题】：Slow BLE response times after second BLE device is connected

【发布时间】：2021-05-05 23:51:31

【问题描述】：

Screen grab from WireShark showing traffic when problem occurs

小问题 - 参考 WireShark 图像，是什么导致 Master 发送 LL_CHANNEL_MAP_IND 以及为什么需要这么长时间？

我们正在开发一个使用 TI WL18xx 作为蓝牙控制器的硬件/软件项目。该产品的主要功能之一是通过低功耗蓝牙连接与我们的传感器硬件进行通信。我们遇到了一个难以确定的问题，但感觉可能存在于 TI WL18xx 硬件/固件中。间歇性地，在连接第二个低功耗蓝牙设备后，写入和通知其中一个连接设备上的特性之一的响应时间会变得很长。

详情

主机产品设备在 TI AM4376x 处理器上运行我们自己的嵌入式 Linux 映像。内核是 4.14.79，我们的通信堆栈位于 Bluez5 之上。 wifi/蓝牙芯片是 Jorjin WG7831-BO，运行 TIInit_11.8.32.bts 固件版本 4.5。它基于 TI WL1831。我们连接的传感器设备是我们自己的，我们使用自定义命令协议，该协议使用两个特征来执行命令握手。这些设备在许多其他平台上运行良好，包括 Mac、Windows、Linux、Chrome 等。

导致问题的工作流程是这样的；

用户空间应用程序允许用户通过 BLE 发现并连接到我们的传感器设备，一次一个设备。 初始连接需要通过上述 BLE 特性进行一系列命令/响应类型的通信。 连接后，流量会显着减少，因为偶尔会有新测量的通知，以及偶尔由用户触发的命令/响应交换。 单个设备似乎总是稳定且高性能。 当用户连接到第二台设备时，初始连接会按预期进行。 但是，一旦第二个设备的连接过程完成，我们开始看到命令/响应响应时间在最初连接的设备上变长了数百倍。 第二设备通信以预期速度继续。 此问题仅在我们遵循此工作流程的大约 30% 的时间中出现在第一台设备上。

痕迹

这里是问题的一个简短的 sn-p，它是由一个跟踪日志形成的，它是我们的库调试和 btmon 跟踪的混合体。

直到第 4102 行，一切似乎都很好，我们在该行看到以下内容：

ACL 数据 TX：句柄 1025 标志 0x00 dlen 22 #1081 [hci0] 00:12:48.654867 ATT：写命令 (0x52) len 17 句柄：0x0014 数据：580fd8c71bff00204e000000000000

D2PIO_SDK：GMBLNGIBlobSource.cpp(1532)：Blob cmd 发送：1bh 到 GDX-FOR 07100117；长度 = 15;滚动计数器 = 216;时间戳 = 258104 毫秒。

HCI 事件：已完成数据包数 (0x13) plen 5 #1082 [hci0] 00:12:49.387892 句柄数：1 手柄：1025 计数：1

ACL 数据 RX：句柄 1025 标志 0x02 dlen 23 #1083 [hci0] 00:12:51.801225 ATT：处理值通知 (0x1b) len 18 句柄：0x0016 数据：9810272f1bd8ff00204e000000000000

D2PIO_SDK: GMBLNGIBlobSource.cpp(1745) : GetNextResponse(GDX-FOR 07100117) 在 3139=(261263-258124) 毫秒后返回 1bh cmd blob。

GetNextResponse() 为大多数 cmd 报告的经过时间应小于 30 毫秒。当我们打开并向设备 A 发送一堆 cmd 时，响应时间很短。 当我们打开并向设备B发送一堆cmd时响应时间仍然很短。但是在随后向设备A发送的第一个cmd上，响应时间超过3秒！

【参考方案1】：

请注意，蓝牙无线电一次只能做一件事。接收或发送。在一个单一的频率上。如果您有两个连接并且两个连接事件同时发生，则固件必须决定优先处理哪一个，跳过哪一个。也许固件不够智能，无法处理您的特定情况。尝试使用其他连接参数，看看是否有好转。您也可以尝试其他制造商的其他蓝牙加密狗。