This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC2640:由于监督超时、中心角色在17分钟后始终断开连接

Guru**** 2546020 points
Other Parts Discussed in Thread: CC2640

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/576927/cc2640-central-role-consistently-dropping-connections-after-17-minutes-due-to-supervision-time-out

器件型号:CC2640

你好

如果其他人可能已经经历过类似的事情、或者如果可能的想法有助于解决此问题、我想分享以下情景。

我们将堆栈版本2.02.00.31与 CC2640芯片组一起在定制电路板上使用、其中包含多角色文件作为项目模板。 我们使用 OOB 数据启用了配对和加密、并成功地将另一个器件作为中央设备连接到充当外设角色。 当我们的器件以中心角色连接时、我们禁用了广播、因此我们一次只能建立一个连接。

建立连接并进行身份验证后、我们将使用2000ms 的连接间隔和7000ms 的监测超时以及从器件延迟0来执行连接参数更新。 然后、我们测量连接的持续时间、并持续观察到、在17.5分钟后(平均值)、连接始终由于监控超时错误而中断。

它会引起我们的注意、该17分钟值有多一致。 我们已经在同一距离(中央设备和外围设备之间3英尺)内测量了数十个与未受干扰设备的重复连接。

然后、我们使用不同的硬件和芯片组作为中心、对外设器件与其他产品进行了连接测试、我们没有这个问题。 我们已获得稳定的连接超过3小时(连续多次迭代)、并且链路保持稳定。 这使我们能够使用 CC2640芯片组将条件隔离到我们的器件、

您是否对如何在我们以 CC2640为中心的产品中改善连接有一些建议/意见/想法? 它看起来就像是我们遇到了某种同步问题。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    这通常指向一个硬件问题、您是否检查了慢时钟的频率? 您是否看到了相同的17分钟、连接间隔更短?

    祝你一切顺利
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Zahid、

    我们以100ms 而不是2000ms 的间隔连接进行了测试、并在大约相同的时间(17分钟)内观察到断开连接的相同行为。  

    我们仍然必须检查慢时钟的频率以确保一致性。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Ricardo、

    您看到的内容可能与此相关:
    e2e.ti.com/.../574277

    我向您发送了一个包含修补说明的 PM
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Christin:

    我们正在按照提供的说明迁移到 BLE 2.2.1堆栈版本以供后续实施补丁(也感谢 Zahid 的答复)。 一旦我们完成测试、我将使用结果更新此主题。

    感谢您的支持。

    此致

    Ricardo Bello

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    2017年3月2日更新

    昨天、我们完成了 BLE Stack 2.2.1版的迁移、并确认补丁文档中提到的问题仍然存在。

    然后、我们按照补丁文档的要求、在对每个输出文件进行完全清理(删除)并从头开始重新构建堆栈和应用项目之后、继续将补丁文件应用到 BLE Stack 2.2.1文件上、 在不再观察到17.5分钟后、我们已确认断开连接问题。 我们已经测量了连接的持续时间超过40分钟。

    我们仍在进行一些测试、以检查在修补程序之后、如果单元不受干扰、连接将持续多长时间、但到目前为止、这是应用此修补程序后行为的明显变化。 我们还在检查是否存在意外的副作用、但到目前为止、我们的 BLE 4.2功能(配对、OOB 数据检查、加密)正在按预期工作。

    2017年3月3日更新

    我们进行了一个夜间测试、我们的器件连接了14.5小时、直到我们手动执行断开连接。


    感谢您提供的支持。

    Ricardo Bello