[参考译文] CC2564C：在连接完成后停止广播

我使用 http://processors.wiki.ti.com/index.php/CC256x_Logger_User_Guide 上的说明记录了日志

它实际上可能与 https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/615843/2268180类似。

从日志中、我怀疑显式启用广播和禁用由连接触发的平均值之间存在竞争条件、但日志中也可见、这是报告的连接和断开事件之间的一种比较方法。

我一直在使用 TI Linux 3.14内核和 BlueZ 4.101、但现在我怀疑这与 BT 堆栈相关。

器件初始化(A)从开始

21589   2   11：50：11.557

广播(B+C)的设置和启用 开始于  

21941   2   11：51：05.853

远程连接环路(D)从开始
22077   6   11：51：06.708

Bastian、

附加的 BT 固件日志(test1.lgr)没有完整的捕获。 如上面链接的用户指南中所述、请确保捕获来自记录器的 BT Logger 1和 HCI/LMP 查看器1端口的完整日志。

连接建立后立即终止。 建立新连接后、预计广播将停止。 但是、在了解22327处断开连接的原因时、未完成捕获功能没有多大用处。

此致、

Vihang

您好、Vihang、

很抱歉。 我用正确的设置重新记录了日志、并验证了捕获的条件与之前的条件非常相似(只是花费了更长的时间)。

此致、

Bastian

e2e.ti.com/.../bttest2.zip

Bastian、

很抱歉、我们花了一段时间来分析日志。 请参阅下面我的评论。

从日志中：

• #237715和#237717 -扫描响应数据和广播数据 设置为 NULL (数据长度为0x00)。 不确定是否所有扫描器都能看到数据设置为空的广播包。  
• #237719 -最大和最小广播间隔设置为100ms (0x00a0)。
• #237721 -主机通过发送 HCI_LE_Write_Advertise_Enable 命令来启用广播。 但是、主机每隔100ms 发送一次此命令。

这种重复是不必要的、在这种情况下会产生反作用。 通常、如果广播已经启用、控制器会拒绝这些重复的 HCI_LE_Write_Advertise_Enable 命令(例如日志中的#237754)。 但是、这些重复的命令可能会导致某些竞争条件、从而导致您观察到的不可靠行为。  

请告诉我们您的具体用例是什么。 您是否有意尝试在实施中发送重复的 HCI_LE_Write_Adverted_Enable 命令？ 如果是、为什么？

此致、

Vihang

Vihang、

感谢您了解这一点。 我将尝试回答您的问题。

||请告诉我们您的具体用例是什么

我们的高级用例是拥有一个基于 Linux 的 BLE 外设、该外设可通过 Android 或 iPhone (一次只能连接一个)进行连接

我尝试生成一个最小设置来重现一种情况、在极少数情况下、BLE 广播在 BLE 断开后不会启用。

原始故障发生在现场的客户设置中、但仅发生几次。 当时使用智能手机进行的 BLE 扫描表明、广播实际上并不是在空中进行的。

我的同事通过不断连接、传输一些数据和断开连接、可以在实验室设置中重现这种情况、每天大约发生一次。 HCI 日志记录(在 CPU 上)指示启用广播的命令实际上已发送到 BT 模块并获得正响应。

为了更好地分析并最终向您报告、我尝试创建了一个设置、以便更轻松、更快地重现。 我创建了第一个帖子中描述的设置、并记录了来自 BT 模块的调试日志。

||您是否有意尝试在实现中发送重复的 HCI_LE_Write_Adverted_Enable 命令？ 如果是、为什么？

如上所述-为了重现此情况、当 BT 模块实际响应它启用广播、但在空中没有发生任何情况。 我的假设是、这是在客户所在的地方和我的同事的设置中实际发生的事情、但频率会降低。 在生产中、在 BLE 断开连接后仅发送 HCI_LE_Write_Advertise_Enable 命令三次(启用、禁用、启用、这是冗余的、但我直到那时才知道实际发生了这种情况)。

||#237715和#237717 -扫描响应数据和广播数据 设置为 NULL (数据长度为0x00)。 不确定是否所有扫描器都能看到数据设置为空的广播包。

我已经验证了这一点。 广播最初由扫描器看到、直到它们停止。 我只是关心广告中的 MAC 地址。

因此、我应该做的是找到一种方法来阻止这种情况发生在我们的客户身上。

因此、我将为您提供一种方法、让您自己重现这种行为、并尝试说服您、这种问题在现实中也会发生、而不仅仅是在人工实验室条件下。

最后、我想获得一些帮助、以找到一种快速(实施)的方法来可靠地解决这一问题。 我已经有了一些想法：

• 在 BLE 断开连接后，仅*一次*启用 BLE 广播
• 在经过特定延迟(例如0.5s)后断开 BLE 连接后，仅*一次*启用 BLE 广播
• 每次断开 BLE 连接后执行硬件复位并重新加载整个蓝牙堆栈和固件。 (需要几秒钟时间)
•  每次断开 BLE 连接后、执行 HCI 复位并重新初始化 BT 堆栈
• 如果不存在 BLE 连接、则定期发送到上述其中一个
• 通过查找报告模块状态的 HCI 命令响应中的模式、尝试获得未传输广播的指示
• 尝试扫描自己的广播(物理上不可能、或被 BT 固件/BT 规范过滤掉)

此致、

Bastian

您好、Bastian、

感谢您添加有关日志的说明。

[引用用户="Bastian Schmitz"]

因此、我应该做的是找到一种方法来阻止这种情况发生在我们的客户身上。

因此、我将为您提供一种方法、让您自己重现这种行为、并尝试说服您、这种问题在现实中也会发生、而不仅仅是在人工实验室条件下。

[/报价]

我同意这样的目标：我们 必须能够在本地重现此问题、以便进一步调试。 但是、我对当前的测试方法有疑问。 如果在没有不必要 的 HCI_LE_Write_adverted_Enable 命令的情况下确实在字段中发生了该问题、则在不改变控制器使用情况的情况下重现此场景更有意义(即不断向控制器发出不必要 的 HCI_LE_Write_adverted_Enable 命令)。

关于此设置的另一个建议：如果有效的广播数据(对于大于0的广播长度和非空广播数据)、是否可以在当前最小设置中重现相同的条件？

[引用用户="Bastian Schmitz"]

我已经有了一些想法：

• 在 BLE 断开连接后，仅*一次*启用 BLE 广播
• 在经过特定延迟(例如0.5s)后断开 BLE 连接后，仅*一次*启用 BLE 广播
• 每次断开 BLE 连接后执行硬件复位并重新加载整个蓝牙堆栈和固件。 (需要几秒钟时间)
•  每次断开 BLE 连接后、执行 HCI 复位并重新初始化 BT 堆栈
• 如果不存在 BLE 连接、则定期发送到上述其中一个

[/报价]

这些似乎都是伟大的想法。 您还可以添加到可能的权变措施中、一种方法是使用 HCI_VS_LE_Enable (0xFD5B)命令仅禁用 BLE、并下载 BLE 附加组件(initscripts-TIInit_6.12.26_BLE_add-on.bts)以启用 BLE。 除了 HCI_Reset 之外、当以这种方式启用和禁用 LE 而不是完全重新初始化时、此选项还可以为您节省一些复位时间。

此致、

Vihang