[参考译文] 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：

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

此致、

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