[参考译文] CC2640：链路建立状态0x3A

谢谢 Christin。

我们处于高级生产阶段、因此不会立即迁移到堆栈2.2.1
USB 软件狗(由我们的自定义 PC 应用程序使用)在其上使用 HostTest 项目和 TI HCI 协议、从而发挥中心作用。
我们将记录应用程序发送和接收的所有命令和事件、并使用 HCI 协议。 如果两个外围设备中的一个由于0x08原因突然终止连接、则此问题很常见(主管超时、我正在尝试理解原因！！)。 在我们的软件狗进行新扫描并尝试重新连接后不久：在这种情况下、需要多次尝试、因为首次尝试时、已建立链接返回状态0x3A。

这是栈2.1.0的已知问题吗？

此外、在中央器件和外设器件之间的连接和通信中、栈2.1.0和2.2.1是否交叉兼容？
我正在考虑从 USB 软件狗上的 HostTest 项目开始逐步升级。 因此、具有2.2.1的 HostTest (中央)将与外设2.1.0正常工作？

提前感谢您的支持。

此致

卢卡

您好！

如果您可以提供监听器日志、我们可以更轻松地了解发生监听超时的原因。

我到目前为止还没有听说过这个问题。

是的、BLE 堆栈2.2.1向后兼容 BLE 堆栈2.1。

尊敬的 Christin：

我正在对问题进行更深入的分析、我将尽快向您提供更多详细信息或日志。

让我简要介绍一下我们的环境。
我们的系统可以与连接到软件狗的一个或两个外围设备配合使用。 外围设备是一个虚拟绘图和指向设备。
当系统与1个器件一起工作时、我们可以设置这些连接参数以连接到所连接的器件、从而最大程度地降低功耗：

连接间隔：100ms
从器件延迟：0
监控器超时：2000ms

当系统使用2个设备时、我们需要使用更短的连接间隔、以便为操作员提供平滑的视觉反馈、因此我们设置：

连接间隔：10ms
从器件延迟：10.
监控器超时：2000ms

因此、当使用两个器件进行操作时、我们设置连接间隔= 100ms、同时在连接0个器件的情况下扫描、同时连接第一个器件和扫描第二个器件。 两个器件都连接后、我们立即切换到10ms (向两个已连接的器件发送命令 GAP_UpdateLinkParamReq)、以确保提供所需的快速视觉反馈。 如果其中一个器件断开连接(已放电或超出范围或任何其他原因)、则使用 GAP_UpdateLinkParamReq 复位 conn。 保持连接的器件的间隔为100ms、以便能够定期扫描并在第二个器件再次可用时查找该器件。 等等。

这种行为确保操作员可以使用一个或两个设备(根据应用程序的要求)、而无需担心连接管理、并且运行良好。

但在某些情况下、这是我最初发布帖子的主要原因、在链接终止且原因为0x08 (我必须理解原因)后、第一次重新连接尝试失败、因为已建立链接返回状态0x3A。 这会导致客户操作人员的工作延迟和中断。

现在、我要进行一些基准测试。 我将在明天向您提供任何详细信息。

感谢您的观看。

此致、

卢卡

尊敬的 Christin：

我发现、由于0x08原因导致断开连接的原因是器件突然随机复位、我正在调查原因。

我现在的问题是：导致链路建立状态0x3A 的连接尝试与主(HostTest)控制器或从(设备)控制器有关、它们是否处于忙状态？ 哪一个？

感谢您的支持。

此致

卢卡