改变连接参数后连接事件计数器的奇怪行为

⚠️
大家好. .谢谢你来到论坛。令人兴奋的消息!我们现在正在转移到新的论坛平台,它将提供更好的功能,包含在主对话网站中。所有岗位和账户都已迁移。我们现在只接受新论坛的流量-请在上面发布任何新帖子//www.wsdof.com/support.我们将在未来几天修复bug /优化搜索和标记。
10个帖子/ 0个新
最后发表
VargaAdam
离线
最后看到:5天21小时前
加入:2019-12-31 16:19
改变连接参数后连接事件计数器的奇怪行为

你好,

我通过以下步骤重现这个问题

—中央连接时间间隔最小/最大设置为50

-中央连接6、7或8外围设备

-连接到外围设备后,中央设置连接间隔min/max为每个连接25

-连接参数得到更新和完成没有错误的中央和外围

发生了什么:

Cconnection事件计数器(由ad_ble_get_lld_stats()和cmac_info_table_ptr->ble_conn_evt_counter提供)在中心端行为错误(在我看来),因为对于某些连接,事件计数器的行为与预期一致(计数器增加的速率是两倍),但对于某些连接,该速率保持与设置50相对应。这只发生在中心端,所有外围计数器都根据新的连接间隔(25)增加。通常在8个连接中,总是第1、6、7和8个连接计数器被损坏。这直到6个连接才会发生。根据各方的api,连接参数更新成功。我不确定连接间隔本身是否更新了,但即使更新了,conn. event计数器也应该保持中央和外围设备的同步。

我使用SDK 10.0.8.105和DA14695作为中心和外围设备。

你能不能检查一下,或者解释一下我哪里做错了?

问候,

设备:
PM_Dialog
离线
最后看到:1天2小时前
工作人员
加入:2018-02-08 11:03
嗨VargaAdam,

嗨VargaAdam,

让我查一下,然后再回复你。

谢谢,PM_Dialog

PM_Dialog
离线
最后看到:1天2小时前
工作人员
加入:2018-02-08 11:03
嗨VargaAdam,

嗨VargaAdam,

是否有可能提供BLE嗅探器捕获,以便我们可以了解什么是发生在空中?请说明多外设功能是否如预期的那样工作?你检查过传送的数据包的顺序了吗?你能看到正确的顺序吗?如果你能提供额外的投入和解释你的问题,这将非常有助于了解问题是什么。

谢谢,PM_Dialog

VargaAdam
离线
最后看到:5天21小时前
加入:2019-12-31 16:19
你好,

你好,

我没有嗅探器,也没有检查消息时间。问题是相对于外围端,中心端上的事件计数器变得不同步。

一个例子:

我用8个外设连接50最小/最大连接时间间隔。

所以连接间隔计数器在中央和外围同步,这意味着。在1秒内,它们增加了16倍(正确地对应于62.5毫秒时间间隔)。

然后在中央端调用ble_gap_conn_param_update()25最小/最大(0从,300监督)为所有连接索引。我得到相应的连接参数更新和连接参数更新完成的事件显示成功。在外围,一切都显示出udpate的发生。

然后,如果我检查连接间隔计数器,我看到在中央,它在1秒内增加32(对应于31.25Ms间隔)为第2,第3,第4和第5连接,但只增加16次数为第1、6、7、8个连接指数。所有外围显示32事件计数器的时间增加。

因此,我看到连接间隔计数器变得不同步。如果我没记错的话,只有5个以上的连接才会发生。

问候,

PM_Dialog
离线
最后看到:1天2小时前
工作人员
加入:2018-02-08 11:03
嗨VargaAdam,

嗨VargaAdam,

捕获一个嗅探器将非常有帮助,这样我们就可以更好地理解这个问题。不过,非常感谢你的解释。

如果我理解正确的话,一旦中央向所有连接的外设发送连接参数更新,就会发生这种去同步,因此连接间隔从50ms更改为25ms。虽然连接间隔是50ms(更新之前),但连接间隔计数按预期工作。

是中央向所有连接的外设发送连接参数更新请求而它们无法接收它,还是它们接收到它但失败了?ble_gap_conn_param_update() API返回BLE错误代码(ble_error_t),因此您可以检查中心请求25ms连接间隔时的状态。API返回所有外设的状态是什么?如果它们都接受它并且没有失败,每个外设的状态应该是BLE_STATUS_OK (= 0x00)。除非,请说明什么是BLE错误码。

中央应该为更新的连接间隔之间的所有8个外设连接提供服务。由于非常短的连接间隔(25毫秒),8个连接可能不适合,因此,中央不能与所有的连接“交谈”。

另外,不建议最小连接时间间隔和最大连接时间间隔使用相同的值。如果两者有相同的值,这意味着BLE设备应该只在一个特定的时间在空中。建议在最小和最大连接间隔之间至少有10ms的间隔,以便设备有重试的可能性。

我强烈建议执行以下测试:

测试1

在更新参数请求后,使用100ms的初始连接间隔(而不是50ms)和50ms的新连接间隔(而不是25ms)。结果如何?你能复制这种行为吗?

如果你能在最小值和最大值之间至少有10ms的间隔,那就太好了。

ble_gap_conn_param_update()重新运行的每个外设的BLE错误代码是什么?

测试2

初始连接间隔为50ms,新连接间隔为25ms,但只有一个外设连接。你能告诉我结果吗?

总之,我们怀疑25ms对于中央服务器来说太短了,无法服务于8个外设连接。

谢谢,PM_Dialog

VargaAdam
离线
最后看到:5天21小时前
加入:2019-12-31 16:19
你好,

你好,

  • 明确一下,连接间隔是5025,对应于62.5毫秒31.25毫秒间隔(而不是你写的50ms和25ms)
  • 我已经说过,所有api函数返回OK,连接参数更新事件在双方都是OK的。
  • “是中央向所有连接的外设发送连接参数更新请求却无法接收,还是接收到但失败?”不,我说过外设更新连接间隔,问题在中央,尽管中央启动了参数更新。
  • “中央应该在更新的连接间隔之间服务所有8个外设连接。由于连接间隔非常短(25毫秒),可能不适合8个连接,因此,中央无法与所有连接“交谈”。这不是很具体。目前我没有中央设备和外设之间的任何数据传输。这与带宽无关,正如我所说的,外围设备会更新它们的连接间隔,这样它们就能得到消息。
  • “另外,不建议在最小和最大连接间隔中使用相同的值。如果两者有相同的值,这意味着BLE设备应该只在一个特定的时间在空中。建议在最小和最大连接间隔之间至少有10ms的间隔,以便设备有重试的可能性。”我认为这份声明与你的发布说明中已知的限制105.08:控制器堆栈不会改变应用程序为LL_CONNECTION_PARAM_REQ提供的最小和最大连接间隔。这可能导致多连接期间的调度冲突。解决方法:将应用程序到触发器控制器的最小和最大连接间隔设置为相同的值,以选择在多连接场景中调度冲突最小的值。
  • “总之,我们怀疑25ms对于中央服务器来说太短了,无法提供8个外围连接。”正如我所说,它不是25ms,但32.5ms,有一个规则,我可以设置的值,因为API提供的更新参数OK ?

问候,

VargaAdam
离线
最后看到:5天21小时前
加入:2019-12-31 16:19

PM_Dialog
离线
最后看到:1天2小时前
工作人员
加入:2018-02-08 11:03
嗨VargaAdam,

嗨VargaAdam,

很抱歉耽搁了。我正在检查,所以我会尽快给你回复。谢谢你的提醒。

谢谢,PM_Dialog

PM_Dialog
离线
最后看到:1天2小时前
工作人员
加入:2018-02-08 11:03
嗨VargaAdam,

嗨VargaAdam,

我会在内部询问团队关于note 105.08的情况。谢谢您对连接间隔的说明。是否有可能使用更大的连接间隔运行所建议的TEST 1 ?我们想检查是否该行为可以复制与一个更大的连接间隔。

谢谢,PM_Dialog

VargaAdam
离线
最后看到:5天21小时前
加入:2019-12-31 16:19
现在我做不到,

目前我还做不到,但希望到下周或下周初我能有机会。