[参考译文] CC2745R10-Q1：信道映射更新命令中存在冲突

大家好-

感谢您联系我们。 如果我正确理解您的问题、您会问在您的应用程序中调用这些 HCI 命令是否会干扰堆栈内发生的任何其他通道映射更新。

您是否使用 TI 器件作为您的中央配置？ 如果是、您的应用可以控制何时发送通道映射更新、调用这些 API 不会干扰栈上的其他更新、因为您作为开发人员可以控制何时或是否发生通道映射配置。

我是否正确理解了您的问题？

此致、

Blake

您好：

感谢您的答复。

布莱克的理解是正确的。

我认为该堆栈负责评估和更新通道质量。

这就是为什么我想知道在用户端发出信道映射更新命令是否会被堆栈的处理覆盖。

由于我确认在连接事件期间无线信道切换、因此我假设信道质量评估也由堆栈执行（我假设这是在用户无法访问的系统部分中自动完成的）。

根据您的回答、这是否意味着“用户必须执行“通道质量评估？

我要使用的器件是适用于中央单元和外设单元的 TI 产品 (LaunchPad CC26X)。

此致、

大家好-

是的、用户负责评估通道质量、并向控制器发出这些 HCI 命令以更新通道映射。

在低功耗蓝牙中、堆栈不会覆盖通道映射。 您在连接事件期间观察到的信道切换是标准 BLE 跳频算法 — 它会通过允许的信道集确定循环，并且与信道质量评估无关。 但是、 允许它传输的通道由您上面提到的 HCI 命令决定。 链路层可以暂时抑制某些信道、但不会改变允许的信道。

因此、这些命令

• HCI_LE_SetHostChanClassificationCmd
• HCI_EXT_SetHostConnChanClassificationCmd

不会与栈的 处理相冲突。

如有任何进一步的澄清、请告诉我。

此致、

Blake

您好：

感谢您的答复。

我有几个问题。

您提到、在连接事件期间观察到的信道切换是标准 BLE 跳频算法 — 它通过允许的信道集确定循环，与信道质量评估无关。“

• 这是否意味着这是蓝牙核心规范定义的标准跳频、而不是 AFH（自适应跳频）？
• 假设上述情况正确、是否可以通过 AFH 实施控制？ （AFH 处理是否在 TI 的 BLE 5 堆栈中实现？）

另外、为了确认、我在下面的理解是否正确？ 我很抱歉重复一下自己。

1. 该堆栈不执行通道质量评估。
2. 因此、用户执行通道质量评估。
3. 可以使用信道映射更新命令在信道映射中反映质量评估的结果。
4. 堆栈（链路层？） 使用更新后的通道映射进行通信。
5. （尽管之前的问题中没有提到这一点）使用的通道由 CSA #2 根据通道映射确定。

此致、