如何解决连接第二个 BLE 设备后 BLE 响应时间变慢
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% 的时间会在第一台设备上出现此问题。
痕迹
以下是由我们的库调试和 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 数据接收：处理 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 的经过时间应
解决方法
请注意，蓝牙无线电一次只能做一件事。接收或传输。在一个单一频率上。如果您有两个连接并且两个连接事件同时发生，则固件必须决定优先考虑哪一个，跳过哪一个。也许固件不够智能，无法处理您的特定情况。尝试使用其他连接参数，看看是否会变得更好。您也可以尝试使用其他制造商的蓝牙适配器。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
