[参考译文] CC1352R：更新 BLE 扫描响应数据可防止发送 BLE 信标

尊敬的 Peter：

首先、非常感谢您为我们提供了一个可重现的示例。 这对我们有很大帮助。 我不知道它现在的行为是这样的。

正如您可能在通用访问配置文件(GAP)文档中阅读并提到的、您确实可以以受控方式"盲目"更新扫描响应数据：

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_20_00_29/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gap-cc13xx_cc26xx.html#directly-manipulating-a-buffer-while-advertising-is-enabled

通过修改您在第436行提供的示例：

status = GapAdv_setEventMask(advHandle1,
                                     GAP_ADV_EVT_MASK_START_AFTER_ENABLE |
                                     GAP_ADV_EVT_MASK_END_AFTER_DISABLE |
                                     GAP_ADV_EVT_MASK_SET_TERMINATED |
                                     GAP_ADV_EVT_MASK_END);

和第501行：

if (event == GAP_EVT_ADV_END)
{
  scanResData1[27]++;
}

我可以更新扫描响应数据并查看两个信标。

以下方式是否适合您？

此致、

Arthur

亚瑟

感谢您的快速响应！  

您建议的解决方法听起来可行、但并不 理想。
如果我理解正确、GAP_EVT_ADV_END 事件在 发送信标后发生。 如果 我等待更新扫描响应直到每次广播之后、则扫描响应数据至少为一个广播间隔旧(在本例中为1秒)。 如果能够在新传感器数据可用时更新扫描响应、而没有1秒延迟、情况会更好。

我假设我可以使用 GAP_EVT_ADV_END 事件来启动计时器、该计时器会在下一个广播间隔之前触发扫描响应的更新、但这似乎不必要地复杂。 每次从外部传感器接收新数据时、我宁愿更新扫描响应。

我想知道您是否能够找到此问题的根本原因。 在平均时间内、我将使用您建议的解决方法、或减少其中一个信标上的广播间隔。

感谢您的帮助！
Peter

尊敬的 Peter：

我们当然会寻找根本原因、并与您分享、因为我们对此感兴趣！

此致、

Arthur

亚瑟

是否有根本原因调查的更新？ 我渴望找到最佳解决方案。

谢谢！
Peter

尊敬的 Peter：

我们仍在寻找这种行为，我与其他人进行了核对，但没有人看到这种行为。 请多多包涵。

此致、

Arthur

尊敬的 Peter：

根据我的理解、当 BLE 堆栈的开始时间可能与另一个堆栈发生冲突时、它似乎正在丢弃命令。

我稍微修改了您的权变措施。 通过允许第二个广播时间在配置中宽松、如下所示：

然后、我们告诉堆栈、可以等待一位进行下一个广播。 现在、当观察数据包时、我们看到两个广播都以1秒的间隔发送、因为重新激活后立即发送广播。

Scan_RSP 数据也会更新。

请告诉我、这是否适合您。

此致、

Arthur

亚瑟

感谢您的回答。 您建议的方法似乎有效、但仍然不理想。

在这种配置下、我观察到、只要有效负载持续更新、信标间隔就仅为1秒。 如果有效载荷未更新(例如、没有可用的新传感器数据)、则间隔时间会降至500ms。 功耗在我们的应用中至关重要、因此无论  负载是否需要更新、我们都希望保持一致的广播间隔。

此外、您能否确认更改最大间隔是否有任何影响？ gap_advertiser.h 指出 GAP_ADV_PARAM_PRIMARY_INTERVE_MAX"将被忽略、因为 GAP_ADV_PARAM_PRIMARY_INTERVE_MIN 始终处于使用状态"： https://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/doxygen/ble/html/group___gap_adv___params.html#ggaa58afceb7db92df94b51adb77393744aa27bc46d1fbcc99ce9ed00d9b6ec47dca

感谢你的帮助！
Peter

尊敬的 Peter：

这意味着我们尚未找到根本原因。 我们必须不断寻找。

但是、我可以确认您是关于 GAP_ADV_PARAM_PRIMARY_INTERVE_MAX 的。 它实际上没有任何效果。

此致、

Arthur

尊敬的 Peter：

我们方面似乎也记录了此问题、一旦找到数据、我将共享更多信息。

此致、

Arthur

感谢您的更新！ 我期待收到更多信息。

Peter

Arthur R θ️ 有关此主题的更多信息？ 我从你们那里听到我已经将近一个月了。

谢谢、
Peter

尊敬的 Peter：

我所讨论的问题本来应该已经解决了。 不幸的是、这似乎与您经历的情况不同。

此致、

Arthur

亚瑟

您和/或您的团队当时是否继续进行根本原因调查？ 请继续通知我任何更新。

谢谢、
Peter

尊敬的 Peter：

我们会不断更新、我会尝试将其进一步推向蒸汽束。

此致、

Arthur

亚瑟

您能否在您的内部订票系统(例如 https://sir.ext.ti.com/jira/browse/EXT_EP-9743)中提供此问题的链接、以便我可以监控其进度？

感谢您的所有帮助！
Peter