[参考译文] Linux：CC2564C、监听模式期间耳机断开连接

您好！

是的、它们是相同的。

我在听筒中启动语音后发现耳机进入监听模式、不到2分钟后、它就失去了连接。

此致

高洪

通过 CC2564B 器件和成功的连接、您是否仍然看到耳机进入监听模式？

您好！

是的、当手持终端使用 CC2564B 进行语音操作时、耳机也会进入监听模式。

除了在耳机进入 CC2564C 监听模式后耳机失去连接外、CC2564B 和 CC2564C 的所有功能都相同。

CC2564B 耳机保持监听模式、没有变化。

此致

高洪

您好！

手机恰好与蓝牙手机和 各种耳机配对、例如平板长型、平板 B825 和 Sennheiser MB Pro2。

当我们将链路支持超时设置为4S 时、发现更容易出现此类问题、如果我们将其更改为10秒、则不太可能出现此类问题。

此致

高洪

您好！

您对此主题是否有任何看法？

我们发现、只要有2个 BT 设备作为 一个手持终端(HSP/HFP)和一个耳机(HSP)配对、一个设备 就会处于语音状态、 另一个设备就会出现断开连接问题。

我们发现断开连接的设备在断开连接之前进入监听模式。

请尝试帮助我们找到原因、谢谢。

此致

高洪

高您好、

[引用用户="Hong GAO"]

我们发现、只要有2个 BT 设备作为 一个手持终端(HSP/HFP)和一个耳机(HSP)配对、一个设备 就会处于语音状态、 另一个设备就会出现断开连接问题。

我们发现断开连接的设备在断开连接之前进入监听模式。

[/报价]

这似乎是某种带宽/时间问题、因为当 LSTO 设置为4秒而不是10秒时断开连接会频繁发生。 我建议在主机端执行以下操作、以检查问题是否仍然存在。

1.通过更改链接策略禁用本地设备上的监听模式。

2.主机堆栈似乎使用 HCI_Change_Connection_Packet_Type 将 ACL 连接数据包类型限制为所有 BR 数据包。 跳过此步骤、因为它对蓝牙链路的可用带宽设置了额外的限制。

3.根据蓝牙规范，默认 LSTO 为20秒。 从可降低 LSTO 的主机跳过 HCI_Write_Link_Supervision_Timeout 命令。 这应显著减少由于连接超时而导致的断开连接。

您好！

禁用监听模式可以解决问题、但我们不希望这样做、因为它会消耗器件的电池。

延长监控超时时间可以减少丢失的连接、但无法完全解决问题。

我们需要完全解决此问题、但我们在日志中找不到 HCI_Change_Connection_Packet_Type、您是否能澄清堆栈何时执行此操作？堆栈设置为数据包类型的限制是什么？

非常感谢。

此致

高洪

您好！

感谢您的参与、我们将尝试使用阻止来发送 HCI_Change_Connection_Package_Type 消息。

但我还有另一个问题、因为我们没有 CC2564B 的此类连接丢失问题、我们还有 CC2564B 的 HCI_Change_Connection_Packet_Type。

唯一的区别是 TI 芯片类型。 这是否意味着 CC2564C 有更多限制？

此致

高洪

洪

[引用用户="Hong GAO"]

但我还有另一个问题、因为 我们没有 CC2564B 的此类连接丢失问题、我们还有 CC2564B 的 HCI_Change_Connection_Packet_Type。

唯一的区别是 TI 芯片类型。 这是否意味着 CC2564C 有更多限制？

[/报价]

我不会期望与 CC2564C 不同的行为。 如果您可以在完全相同的用例场景中提供 CC2564B 和 CC2564C 的 FW 日志、我可以并排查看这两个日志。

此致、

Vihang

您好！

我们已经完成 了禁用发送 HCI_Change_Connection_Packet_Type 的测试、但问题仍然存在。

收集 CC2564B 和 CC2564C 案例的日志、BT 手持终端和耳机均已配对。

对于 CC2564C 案例、耳机在语音听筒重新连接和语音转接到耳机(电话行为)期间断开连接、在一段时间后、听筒断开连接并重新连接、因此耳机和听筒分别发生2次断开连接。

对于 CC2564B、未发生断开连接、手机保持语音。

请帮助检查并找到原因。 谢谢。

此致

高洪

e2e.ti.com/.../3240.fw-log.rar