考虑这样一个场景，主从服务器协商管理器超时20秒。通过观察rwble.c中这些事件的顺序，如果检测到5秒的链路不活跃(在主管超时之前)，slave有代码显式断开连接:
/ *最后祝福活动。用于应用程序的同步BLE活动*/
typedef枚举
｛
BLE_EVT_SLP,
BLE_EVT_CSCNT,
BLE_EVT_RX,
BLE_EVT_TX,
BLE_EVT_FINETGTIM,
BLE_EVT_END,
} last_ble_evt;
链接在t=0时断开，使用调试器断点，我观察到从代码通过内核消息GAPC_DISCONNECT在t=5秒时正确地启动断开。
然而，我还通过调试器观察到的是，GAPC_DISCONNECT_IND(确认断开已完成)直到t=10左右才出现。通过数据包嗅探器，我还看到，直到t=10之后，广告才会恢复。即使在适当的时间执行了GAPC_DISCONNECT命令，实际的断开似乎也被延迟了。在我们的例子中，重要的是，如果上述条件发生，断开立即发生。
谢谢,
设备:
嗨JamesHiebert,
产生这种行为的最可能的原因是连接间隔。连接间隔的配置是什么?如果连接间隔太大，而你没有使用延迟，我建议你使用更小的连接间隔，增加延迟。请查看附件截图。当从服务器没有东西可发送时，连接间隔大约为2200ms (2000ms延迟+ 200ms conn间隔)。但是当从服务器有东西要发送时，在你的情况下是断开消息，设备将被唤醒，连接间隔大约是t 200ms。
谢谢,PM_Dialog
你好,对话框,
谢谢你的信息。在我们的场景中，CI非常短，为11.25ms，从延迟为0。
当主服务器不再向从服务器发送空闲数据包时，您是否尝试过在长时间的监控超时期间进行这个实验?
是否可能发生延迟，因为从服务器不能发送断开命令，因为主服务器和从服务器不再交换空闲?
嗨JamesHiebert,
不，我从来没有做过这个实验。你能再解释一下吗?你使用的是哪种配置?
谢谢,PM_Dialog
试试这个:
1.建立连接11.25ms CI和20s ST(主和从)。
2.从连接开始设置一个5秒(或更多)的计时器。
3.在计时器结束前，断开主天线
4.当定时器超时时，slave发送GAPC_DISCONNECT_CMD。
GAPC_DISCONNECTED_IND什么时候被从应用程序接收?
我们希望它立即发生，但似乎它被明显地延迟了。
嗨JamesHiebert,
当你发送GAPC_DISCONNECT_CMD命令时，响应是一个GAPC_DISCONNECT_IND事件，该事件在连接完成时触发，当操作完成时，你将得到一个GAPC_CMP_EVT事件。GAPC_DISCONNECT_IND事件将被发送到应用程序任务，以通知链接已经断开。接收此消息还意味着与链接相关的任务实例将被清除，并且在新连接建立之前，不能再使用相应的任务实例。您的意思是当您断开主设备和对端外围设备的连接时，您没有得到GAPC_DISCONNECT_IND吗?
谢谢,PM_Dialog
PM_Dialog,
我们确实得到了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,
很高兴你把问题解决了，谢谢你的提示。
谢谢,PM_Dialog