您好！
我们看到、使用 Ellisys 时、在某些情况下、连接间隔将在没有 主器件或从器件请求的情况下更新、并且在我们的代码中没有请求这样做。
1. BLE4 stack 5.10.0.02 simple_peripheral (作为从设备)。 在没有请求的情况下更改连接间隔后、主器件可以使用标准请求将其改回。
2.我们也看到这是在 multi_role 作为主站的情况下,它会在几秒钟到几分钟后自行恢复到正常间隔。
在这方面是否存在已知问题？ 我们是否有/不应该做的事情会导致这种情况？
此致、
杰罗姆
感谢 Jan 的帮助。
在我们的2号产品中、multi_role 作为主设备、我们比较了 BLE 堆栈 1.40.0.45与5.30、 这里我不想加上数据来节省混乱、但在这些方面、5.30的性能主要是在1.40之上。
以下内容适用于#1 simple_peripheral (作为从设备)。
-这里的捕获显示了 BLE5编码的 PHY 连接,但我们看到了与传统 BLE4相同的错误行为。
-问题是突出显示的数据包,它切换到40ms 间隔,也可以在计时视图中看到。 (14：29：07.824 965 900)
- 品红色 数据包是相同的,据我们了解,这些"重复"的 BLE 堆栈,在这段时间内数据的变化不发送。 重复数据始终以40ms 间隔意外切换开始。 
在此、我们可以看到 ATT 读取成功并且数据正确、因此它不会"完全卡住"。 
最后、它会停止重复的重复数据并 继续发送正确的数据 
如果需要、我们可以通过私人渠道提供 BTT 文件。
此致、
杰罗姆
大家好、Jan、
以下内容仅涉及产品2、作为主站的多角色：
正如我们 在 下面的截图中看到的、 param 更新请求持续了450ms、但主器件意外继续使用1.35sec。 这是堆栈1.40。
在堆栈5.30 (无屏幕截图)中、我们也得到了错误的间隔、但最差的是它增加到2.3秒！ 我们的从设备 能够保持1.35秒的连接、但2.3秒的连接太困难了、因此我们永远无法升级 SDK 版本、我们被迫在该产品上继续使用栈1.40。
此致、
杰罗姆
大家好、Jan、
产品1
看来我们现在 完全了解发生了什么。
40ms 间隔确实来自主器件的合法请求，但该请求发生在更改前32秒。 这是我们在 Ellisys 拍摄中所表现出的原因之一。 看来、这是因为连接间隔是2000ms、"瞬间"在16个间隔内到期、造成了32秒的微秒延迟。 我们现在已删除这一请求。
是否有 API 可以更快速地更改"即时"以供将来参考？
复制的错误数据是由于我们的 逻辑中的某种奇怪、 当连接间隔太短时、它跳过了数据更新。
产品2 -我们将根据调查结果进行更深入的分析。
此致、
杰罗姆
