工具与软件：
我的客户发现、当外设侧(CC2642)上的 CSA#2已禁用时、其中央设备(NXP KW45)仍会随 CSA#2发送 CONNECT_IND。
在 BLE 核心规范5.3中、有两个部分 对于 CSA#2而言是矛盾的。 在第6卷第 B 部分第2.3.3.1节中、它指出如果启动器支持 CSA#2、则启动器可以将 ChSel 字段设置为0或1、但广播器不会：
在 第6卷第 B 部分 4.5中、说明当其中一个或两个 PDU 的 ChSel = 0时、应使用 CSA#1：
哪一个是正确的？ 外设不支持时、中央设备使用 CSA#2是否合法？
此致、
沭阳县
尊敬的 Isaac：
请找到针对此问题的监听器日志、可以使用 blueSPY 软件打开该文件。
e2e.ti.com/.../0703_5F00_resetok.pcapng
从监听器日志中、我们可以看到 ADV PDU 使用 CSA#1、而 CONNECT_IND 使用 CSA#2：
我的问题是、这种行为是否符合 BLE 规范？
为了添加更多背景信息、客户报告此情况是因为他们看到0x3E 断开连接。 除了通道选择之外、是否还有其他任何可能导致0x3E 的原因？
此致、
沭阳县
大家好、沭阳
哪一项是正确的？ 当外设不支持 CSA#2时、中央设备使用 CSA#2是否合法？[/QUOT]这两个部分都是正确的。 就最终行为而言、当外设不支持时、中央器件使用 CSA#2是不正确的。
[报价用户 id="168885" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1384874/cc2642r-q1-channel-selection-algorithm-2 "]在 BLE 核心规范5.3中、有两个部分 对于 CSA#2而言是矛盾的。 在第6卷第 B 部分第2.3.3.1节中、它指出如果启动器支持 CSA#2、则启动器可以将 ChSel 字段设置为0或1、但广播器不会：
[报价]
我想在第1节中唯一让人困惑的是：当广播者不支持 CSA#2时、发起者可能会将 ChSel 字段设置为1。
在这种情况下、广播器应将 ChSel 字段设置为0。 在这一点上,第2节中的陈述仍然有效,所以这两节不相互矛盾。广播器始终使用 CSA#1、但启动器在其 CONNECT_IND 数据包中使用 CSA#2、它们的通信方式不相同、这就是它们无法建立连接并导致断开0x3E 的原因。
[报价 userid="168885" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1384874/cc2642r-q1-channel-selection-algorithm-2/5295281 #5295281"]
现在我们来分析为什么 ADV_IND 使用 CSA#1、但 CONNECT_IND 在监听器日志中使用 CSA#2。从监听器日志中、我们可以看到 ADV PDU 使用 CSA#1、而 CONNECT_IND 使用 CSA#2：
[报价]
原因应该是处理 ble 堆栈中归档的 ChSel 存在问题。 接收器件应将 ChSel 设置为0、并在使用 CSA#1时将其忽略。 不应根据 Rx PDU 的 ChSel 文件设置它、因为 ChSel 字段是核心规范5.0之前的 RFU 位。
当广播器不支持 CSA#2时、如果发起方将 ChSel 字段设置为0、则 CONNECT_IND 将使用 CSA#1。 似乎 NXP 的器件没有将 ChSel 字段设置为0、尽管 NXP 符合核心规范、但在这种情况下最好将 ChSel 设置为0。
这是使用 CSA#1的 CC2652和使用 CSA#2的手机的监听日志、这些手机可以正常通信、CONNECT_IND 使用 CSA#1。
(奇怪的是、为什么我不能在此处添加嗅探器附件)
此致、
Kevin
尊敬的 Isaac：
空数据包在 BlueSPY 的设置中被过滤、请启用"Empty Packets"按钮、然后您可以看到在 CONNECT_IND 之后有6个空数据包：
并且客户在 GAP_LINK_ESTABLISTED_EVENT 中添加了调试 GPIO、当问题发生时、似乎未输入该事件。
客户还发现在发生问题时、在 CONNECT_IND 发生后不久出现 ADV_IND、但在成功连接后未看到 ADV_IND (监听器日志中的最后一个连接成功)。
此致、
沭阳县
