考虑一个场景，主控器和从属设备协商监控器超时20秒。如果通过观察rwble.c中这些事件的顺序检测到5秒的链路不活动（在管理器超时之前），则从机具有明确断开连接的代码
/*最后一个BLE事件。用于应用程序与BLE活动同步*/
类型定义枚举
{
BLE_EVT_SLP，
BLE_EVT_CSCNT，
BLE_EVT_RX，
BLE_EVT_TX，
好的，好的，
BLE_EVT_END，
}最后一次evt；
链接在t=0时断开，使用调试器断点，我观察到从代码通过内核消息GAPC_disconnect在t=5秒后正确启动断开连接。
然而，我在调试器中观察到的是，确认断开连接完成的GAPC_DISCONNECT_IND直到t=10左右才会出现。通过数据包嗅探器，我还看到广告直到t=10之后才会恢复。看起来，即使在t=10时命令GAPC_断开连接，实际断开连接也会延迟适当的时间。在我们的情况下，如果出现上述情况，必须立即断开连接。
谢谢
设备：
嗨JamesHiebert，
具有此行为的最可能原因是由于连接间隔。您是连接间隔的配置吗？如果连接间隔太大，并且您不使用延迟，我会建议您具有较小的连接间隔并增加延迟。请检查附带的截图。当从站没有发送连接间隔时，在2200ms（2000ms延迟+ 200ms CONN间隔）周围。但是当从站有东西要发送时，在您的断开消息中，设备将唤醒，连接间隔将在T 200ms周围。
谢谢，下午好
你好，对话，
感谢您提供的信息。在我们的场景中，CI非常短，为11.25ms，从机延迟为0。
当主设备不再向从设备发送空闲数据包时，您是否在长时间的监控超时期间尝试过该实验？
延迟是否可能是因为从机无法传输断开连接命令，因为主机和从机不再交换空闲？
嗨JamesHiebert，
没有，我从未尝试过这个实验。你能再澄清一点吗？您正在使用哪些配置？
谢谢，下午好
试试这个：
1.与11.25ms CI和20s ST（主和从）建立连接。
2.从连接开始，设置5（或更多）秒的计时器。
3.在计时器结束之前，断开天线与主机的连接
4.定时器到期时，从机发送GAPC_DISCONNECT_CMD。
从应用程序何时接收到GAPC\u断开\u IND？
我们希望这种情况立即发生，但它似乎被大大推迟了。
嗨JamesHiebert，
当您发送GAPC_DISCONNECT_CMD命令时，响应为GAPC_DISCONNECT_IND事件，该事件在连接完成和操作完成时触发，您将获得GAPC_CMP_EVT事件。GAPC_DISCONNECT_IND事件将发送到应用程序任务，以通知链接已断开。收到此消息还意味着与链接相关的任务实例已清理，并且在建立新连接之前，无法再使用相应的任务实例。您的意思是，当您断开主机与对等外围设备的连接时，您不会获得GAPC_disconnect_IND？
谢谢，下午好
下午对话，
我们确实收到了GAPC_DISCONNECT_IND，但不是立即收到。在指示到达之前，似乎需要几秒钟的时间。这几乎就像系统试图通过无线方式将断开指示发送回主机，但由于没有接收到主机的帧，所以在放弃和断开之前会延迟一点？
对话
我与您的一位工程经理进行了通信，他建议发送以下信息而不是GAPC_DISCONNECT，从而解决了延迟问题。
ke_msg_send_basic（LLC_LE_LINK_SUP_TO，ke_BUILD_ID（TASK_LLC，gapc_get_conhdl（conn_idx）），TASK_NONE）；
对话
我与您的一位工程经理进行了通信，他建议发送以下信息而不是GAPC_DISCONNECT，从而解决了延迟问题。
ke_msg_send_basic（LLC_LE_LINK_SUP_TO，ke_BUILD_ID（TASK_LLC，gapc_get_conhdl（conn_idx）），TASK_NONE）；
嗨JamesHiebert，
很高兴你解决了问题，谢谢你的提示。
谢谢，下午好