嗨,对话框中,
我目前正在使用带有BlebereBone示例（外围设备）的da14583模块作为基本代码，并添加了一个自定义配置文件。有一个应用程序连接到583模块R/W特征，当它写入最后一个特征时，模块发送应用程序\u easy\u gap\u disconnect（应用程序\u connection\u idx），终止连接，我在上得到一个回调
用户_app_disconnect（struct gapc_disconnect_ind const*param），断开错误代码（param->reason）为0x16连接，由本地主机终止（根据BLE规范）。
在10到15次尝试中，出现了一种情况，即设备需要5-6秒才能到达断开回调，并且该实例的错误代码为0x2B保留（Ble规范）。
此带有0x2b错误代码的延迟断开连接给用户体验带来了不便。请帮助我们尽快解决此问题。
谢谢,
迪拉杰
设备:
你好，dhirajp15，
我不认为这是与58 x,这是最有可能的问题另一边(电话或应用程序),你确定你得到消息的次58 x发出断开(也许是断开发出的电话由于其他原因)?如果你从电话端而不是从58x收到这种断开原因，58x只会从对端设备报告断开原因，那么你有嗅探器日志来检查吗?还检查了ble_app_peripheral和barebone示例上的连续连接和断开，超过100个连续的后续连接和断开，断开原因总是由电话发出的0x16，由580表示。
谢谢你的对话
嗨MT_Dialog,
为了确认它始终是58X的，我试着用一个不同的58X模块连接，而不是用手机，还嗅了嗅数据。我附上了嗅探结果，请参考结果号。394 -396:
394，“75.449018000”，“从”，“主”，“lell”，“28”，“控制操作码：LL_TERMINATE_IND”
395,"75.470824000"、“大师”、“奴隶”,“LE会”,“26”、“空PDU”
396年,"81.776847000"，“奴隶”，“主人”，“奴隶”，“31”，“未知”
可以看到，断开连接需要6秒，并且“LL_TERMINATE_IND”是由58x外设发送的。
PFA,
谢谢,
迪拉杰
你好，dhirajp15，
如果您附加了嗅探器的实际文件，而不是您附加的excell表，这会有所帮助，我指的是嗅探器使用的实际.cfa和frm文件，以便能够跟踪设备之间的交互，以便尝试和复制，因为我们没有观察到该问题。
另外，关于您正在使用的设置，您的案例中的两个设备都是58x（外围设备和中央设备）？你可以用不同类型的中心设备（不同的电话和58x设备作为中心设备）来复制这个问题？
您为设备设置的监控超时时间是多少?如果设置的超时时间越长，设备断开连接的时间就会越长。
当你发送一个终止指示到对等设备,在某些情况下,包括设备意图打破连接时,将断开的设备预计ACK的对等设备断开与一个额外的包在一个特定的时间,即监督超时。如果对等体不ACK数据包，将有一个与监督超时延迟和不为预期的原因，尽管我不能确定从哪里0x2B将来，因为堆栈没有这种错误代码断开连接。在发送断开连接后检查gapc_cmp_evt_handler()，你应该能够得到一个GAPC_DISCONNECT消息，并检查消息的状态，我认为这将指示一个错误。
我可以假设，当问题发生时，可能有一个正在进行的过程尚未完成，例如和更新参数过程或安全过程（如果有安全实现），或者由于任何读写，您可以尝试的一些事情是不执行与设备的任何交互，但在一段特定的时间后连续发出断开。此外，一旦设备向中心发送了一些数据，您就可以连接和断开连接（我假设只有外围设备发送断开连接请求，对吗？）下一个连接立即建立？
谢谢你的对话
嗨MT_Dialog,
关于设置，我们正在使用两个设备:-一个是583外设，另一个是583中心模式的测试目的。583外设在正常情况下连接到一个应用程序。
583外设的监控超时设置为1秒。
所以我看到583中央模式监督超时是5秒，因为有一个延迟断开。当我把它改成1秒时，问题就解决了。
由此得出结论:采用了中心设备的连接参数，忽略了外围设备的连接参数。所以对于Android应用，我认为监督超时超过10秒，因此我面临延迟断开的问题。(参考链接https://blog.classycode.com/a-short-story-about-android-ble-connection-t...).
您能建议我如何使外围设备干净地处理断开连接以解决此问题吗？
断开连接总是由外围设备发出。每当中央设备在结束时完成读/写特性，外围设备就会发出app_easy_gap_disconnect（app_connection_idx）命令，并在用户app_disconnection（）时收到回调超过10秒后。一旦我们收到断开回调，下一个连接过程可能会启动，也可能不会启动，具体取决于按键。
同时附上带有完整数据包数据的sniifer日志以供参考。
谢谢,
当做
Dhiraj。
你好，dhirajp15，
关于连接参数，当连接第一次建立时，对连接有效的连接参数是中央的，之后外设能够发送一个参数更新请求，以便主服务器检查他是否愿意遵循这些参数。所以由主人决定是否遵循外设请求的连接参数，所以它将接受或拒绝参数。
关于这个问题,我不能理解的是,由于监督超时的数量是你正在观察interveniens断开命令和实际之间断开调为什么设备报告的错误代码是一个0 x2b(正如已经提到我无法复制它从我身边)。由于存在连接超时，错误代码应该是CO_ERROR_CON_TIMEOUT。如果出现超时，则意味着在您从外设发出断开连接命令之前，设备已经失去了连接。我一看wireshark嗅探器日志上,附加的两个文件,它们是快捷键,而不是实际的日志,从. txt和你连接我无法告诉,似乎有数据包丢失从日志。我也尝试过连接和断开连接后，相当多的读和写从中央没有0x2B发生，也没有超时原因。
谢谢你的对话
嗨MT_Dilaog,
从Wireshark发送实际的嗅探日志文件，很抱歉发送快捷方式。
PFA,
问候,
Dhiraj。
日志中你发送我不看到任何写或读从中央到外围设备,所有我能看到的是发现中央,另外我看到有两个LL_TERMINATE_IND,我不能够明白为什么发生,我认为这是一个重新传输，但似乎第一个终止消息被正确地发送到中央，因为中央响应正确的序列号，所以我不明白为什么有一个秒终止指示(也有一个错误的序列号)。不管怎样，既然你提到你正在使用手机和580设备运行基于ble_app_barebone例子的fw，你能复制ble_app_barebone fw的问题吗?如果是，请提供说明，以便我复制这方面。
谢谢你的对话
嗨MT_Dialog,
这个问题似乎已经解决了。
以正常裸骨为例进行测试，dint发现延迟断开情况。
与修改代码的断开错误码接收在那个时候是0x22而不是0x2b(我的坏:/)
0x22 LMP响应超时/LL响应超时大约在20秒后收到，这是由于连接到应用程序时的监督超时，当连接到583中央角色时，它在5秒后出现，因为我可以在583中央模块中配置监督超时。但在安卓手机上，它的预配置，甚至在发送参数更新请求后，它也不会改变。我想知道在什么情况下我们会得到监督超时？在10次尝试中，我至少有一次超时。每次外围设备发出断开连接请求时。
谢谢,
问候,
迪拉杰
你好，dhirajp15，
对于监督超时,android手机确实有这个值预配置,但是如果你发送一个更新参数请求通常android手机接受参数变化(offcourse取决于电话,也许是android版本,但据我所知大多数时候android接受更新)。无论如何,一般来说,一个监督超时发生在外围在你的情况中没有收到主,所以当外围开辟了其接收机无法得到主测深仪发射,所以它将从上次收到主开始计数,并将开始扩大其RX窗口为了能够“听”他,如果外围设备不能得到任何东西，并且监控超时，外围设备就会因为上述原因断开连接。这种情况也可能发生，如果由于某种原因外周被预先编程的BLE活动延迟。
谢谢你的对话