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.

[参考译文] CC2652P7:器件没有收到断开事件。

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1463414/cc2652p7-the-device-does-not-receive-a-disconnect-event

器件型号:CC2652P7

工具与软件:

你好
我有两个器件、一个连接到另一个。 在某些情况下、我看到在从器件上建立了连接、但状态为0x3D 时立即断开了连接。 此状态与配对期间不正确的加密密钥相关。 但是、无论断开连接的原因是什么、发起连接的器件都不会接收到该断开事件、并认为存在该连接。 在启动器侧、连接会在稍后和超时条件下断开。
为什么我没有在主侧看到断开连接事件、而在盐水侧它是? 如何确认我正确接收到这些事件?

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

    您好、Nick。

    您能否指定您使用的 SDK 版本? 断开连接后中央设备是否挂起或停止响应?

    此致、

    1月

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

    你(们)好
    我正在编写我自己的应用、但使用的是 SDK 7.41
    不、设备看起来不是挂起的、但它们记录不同时间的连接中断以及不同的原因。 由于原因0x3D、一侧的外围器件断开连接。 中央设备会因为原因0x08 (超时)而将连接中断记录得较晚。 为什么它不能同时记录断点、也不能记录与外设相同的原因? 似乎中断消息无法到达它、但这只是一种猜测。

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

    您好、Nick。

    明白了。 感谢您发送编修。 根据您提供的信息、我认为您会发现中央器件由于某种原因未接收到终止事件、并且会继续运行、就像连接仍然有效一样。 在这种情况下、中心设备的预期行为是在从另一个器件接收到的最后一个数据包经过等于连接监控超时的一段时间之前、不要假设连接已断开。 如果需要、您可以增加或减少监控超时、具体取决于 您是想要更短的检测时间还是更稳健的连接。

    此致、

    1月

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

    你(们)好

    我明白了。 但是、是否有任何方法可以确定中央设备已接收/未接收到连接中断消息? 或保证它确实已到达收件人? 这类似于带有确认的写入操作。
    还是系统设计为使外围器件发送连接中断消息而不关心另一侧如何接收该消息?

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

    您好!

    我认为、如果中心设备在连接丢失后尝试写入/读取外设的特性、这可能会快速触发断开连接。 如果我没有误认为、在 BLE 中、外设在发送链路终止消息后不会等待确认。

    此致、

    1月