[参考译文] LAUNCHXL-CC26X2R1：在广播时、TI BLE Stack 会在广播间隔中增加随机延迟

admin

Other Parts Discussed in Thread: LAUNCHXL-CC26X2R1

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/921544/launchxl-cc26x2r1-while-advertising-ti-ble-stack-adds-up-a-random-delay-to-the-advertisement-interval

器件型号：LAUNCHXL-CC26X2R1

您好！

我有具有 CCS v9.1.0的 LAUNCHXL-CC26X2R1板、并且我将 simplelink_cc13x2_26x2_SDK_3_10_01_11 SDK 用于工程。

我正在处理 Simple Peripheral 应用、并修改了该项目、以便它可以支持5个传统广播数据集和1个扩展广播数据集。对于广播、我必须在每个广播间隔后更改广播集。因此，我将使用不同的广播间隔计时器，并使用 GapAdv_enable()和 GapAdv_disable()在广播数据集之间切换。因此、当接收 GAP_EVT_ADV_END 时、我们会禁用广播并切换到下一个广播集。计时器过期时，我们使用 GapAdv_enable()发送下一个广播数据集。
但是、当我将 GapAdv_enable（)发送到 BLE Stack 以开始广播时、每次随机延迟后都会收到 GAP_EVT_ADV_START_AFTER_ENABLE 事件。因此、我在中央侧以随机广播间隔而非预期广播间隔接收广播数据包。
在发送第一个广播数据包之前、我尝试通过计算 GapAdv_enable ()和 GAP_EVT_ADV_START_AFTER_ENABLE 之间的系统节拍(即在我们的项目1节拍= 10微秒)来观察 TI BLE 堆栈添加了多少延迟。以下是我的观察结果：

在我观察到的多个调试会话中、BLE 堆栈会在发送第一个广播数据包进行广播之前、为每个广播数据集添加0ms 至大约16ms。在接收广播数据集的同时、在中央侧观察到同样的情况。

您能解释一下 TI BLE 堆栈的这种行为吗？为什么添加延迟而不是直接发送广播的广播数据集？

此致、
四

5 年多前

0 admin 5 年多前

TI__Guru**** 2771175 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Shiv！

我会研究这个问题、并尽快返回给您！

此致、

1月

0 admin 5 年多前

TI__Guru**** 2771175 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Shiv！

发送广播时、蓝牙规范(请参阅蓝牙核心规范版本5.1 |第6卷、B 部分、§4.4.2.2.1) 规定广播事件之间的时间等于 advInterval + advDelay。您可以更改 advInterval 的值，但 advDelay 是由链路层生成的假随机值，无法修改。 advDelay 可以在 advInterval 延迟之上的广播事件之间添加0ms 至10ms 的额外延迟。这可能会导致您观察到的部分延迟。

另一种可能的延迟源可能是被调用的 GapAdv_enable()函数与硬件开始广播之间的固有延迟。我建议查看扫描和广播 SimpleLink Academy 实验。本实验讨论了在运行时更改参数广播参数、您可能会发现这些参数很有用。它还讨论了 advDelay。本实验还介绍了如何修改广播之间的延迟。我认为您遇到的延迟是正常的、并且在规格范围内。

此致、

1月

0 admin 5 年多前

TI__Guru**** 2771175 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

我对此仍有一些疑问。

[引用用户="Jan Iglesias Morales"]

[/报价]

因为我们将自己的计时器用于广播间隔。您所讨论的 advDelay 是在 GapAdv_enable ()和 GAP_EVT_ADV_START_AFTER_ENABLE 事件接收之间添加的。还是在我们开始广播时开始接收 GAP_EVT_ADV_START 事件时添加了它。

[引用 user="Jan Iglesias Morales"]另一种可能的延迟原因可能是被调用的 GapAdv_enable()函数与开始广播的硬件之间固有的延迟[/引用]

因为我已将广播间隔设置为319ms。当超时发生时，我们调用了 GapAdv_enable()来开始广播新的广播数据集。而且、我始终会在中央侧接收广播数据包、广播间隔介于319ms 至335ms 之间。因此、该延迟仅是因为您所讨论的固有延迟。还是添加了上面提到的 advDelay？

此致、
四

0 admin 5 年多前

TI__Guru**** 2771175 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Shiv！

advDelay 包含在通告事件开始的间隔时间内(请参阅蓝牙核心规范版本5.1 |第6卷、B 部分、§4.4.2.1图4.3)。在您接收到 GAP_EVT_ADV_START 之前、该延迟可能已经发生。调用 GapAdv_enable()时，您可能会看到由于我提到的固有延迟而出现额外的延迟。在您接收 GAP_EVT_ADV_START_AFTER_ENABLE 事件时本会发生的固有延迟。在中央系统上看到的延迟很可能是两者的组合。如果可能、我建议修改中心代码、以便能够处理这种延迟变化。

此致、

1月

Bluetooth®︎（参考译文帖）

Bluetooth®︎（参考译文帖）(Read Only)

[参考译文] LAUNCHXL-CC26X2R1：在广播时、TI BLE Stack 会在广播间隔中增加随机延迟