[参考译文] CC2652P：Zigbee 器件在发送信标请求/信标之前是否实现 CSMA/CA？

添加一些背景：此问题的根源是客户发现终端设备几乎不会使用特定信道(19或20)发送信标请求、但使用其他信道时、同一设备是正常的。 因此、客户想知道这是不是因为当信道噪声过大时终端设备不会发送信标请求。

之后、客户对该问题进行了一些其他测试、发现他们的硬件在使用 SDK 示例的通道19和20上表现正常、但使用自己的代码时表现不佳。 但我不确定是哪种软件配置会导致这种行为、请提出您的建议、谢谢。

此致、

水阳

添加：
在我们的项目中、我们将器件固定在通道19上以进行周期性扫描。 我们发现器件在通电时可以发送一次 BeaconReq、然后看不到器件发送的 BeaconReq 消息、 但调试信息显示器件处于循环调用网络添加的 API、返回状态为成功。

在这种情况下、我们只将通道修改为24、器件发送的 BeaconReq 会定期在监听器中看到、并且可以正常加入网络。

我们在屏蔽盒中对其进行了测试、但它仍然是相同的现象。

我们读取器件的 CCFG 配置信息、差异如下(左侧为 SampleDemo、右侧为我们的项目)：

Shuyang、Howjie、您好、

我已经与软件研发部交谈过、他们认为在信标请求期间使用了 CSMA 机制。  关于 CCFG 更改、如果使用 PA 输出、则保证更高的 DCDC_Vmin 值和禁用 EXT_LOAD。  请考虑相应地进行更改、并监控这是否会对您的系统产生任何影响。  我还记得 在之前的 E2E 帖子中 、CSMA 值在过去发生了变化、因此、请在与默认 SimpleLink 演示进行比较时查看这些值以及其他可能的 MAC 更改。  是否正在评估 SDK v5.20？  所有 Zigbee 应用和 Z-Stack 网络的更改都与此问题无关紧要。

此致、
Ryan

我们的应用是 睡眠终端器件(SDK 5.20)、不使用 PA。

在 我们 的项目中、CCA 阈值始终是默认值。

从 bdb 开始调试到 NLME_NetworkDiscoveryRequest()基本没有区别。

与 SampleLink 演示相比、我们的项目中没有新发现。

电流测试结果非常令人困惑。
当器件出现问题时、我们将刻录样本演示固件、器件将恢复正常(我们可以看到器件在通道19上发送的信标请求)、然后在刻录最新固件后、器件也将正常工作、 正常状态将持续一段时间、不确定器件何时会再次出现这种现象。 换言之、我们不确定如何重现此类器件的问题。

我们只发现有问题的器件、它在固件初始版本烧写时工作正常。 当我们刻录最新版本的固件时、它将会出现问题。 通过重复上述过程可以很好地重现此问题。 目前、我们正在尝试使用此设备执行版本回滚、以缩小问题范围。

注意：我们的电流测试是在屏蔽盒中进行的。

谢谢、

Howjie

如果您重启电源或对器件进行软复位、问题是否已得到解决？  在您的测试期间、器件是否确实加入了网络、您是否曾进行出厂复位而不是完全重新编程器件？  如果降低扫描频率、行为是否会发生变化？  是否所有硬件板都受影响、或者每个器件的行为是否看起来不同？  我想听听您的软件版本比较结果。

此致、
Ryan

感谢您关注 Howjie、我已将您的回答标记为分辨率、但您可以随意在该主题中添加更多信息。

此致、
Ryan

您好、Ryan、

ZStack 中的默认 CCA 模式是什么？

如何修改协议栈中的 CCA 模式？  

是否可以根据 TMR 中的信息直接修改 ti_radio_config.c 中的 ccccco 的相关变量？

谢谢，

Howjie

您好、Ryan、

在我们禁用 syscfg GUI 中的"Include in build"并配置 ccaOpt 后、仍然无法修改 CCA 模式？

MAC_CCA_TYPE_CSMA_CA 意味着 IEEE 802.15.4标准中定义的 CCA 模式1？

谢谢、

Howjie

是的、是的。

此致、
Ryan

您好、Ryan、

是否有办法 通过软件检查 Zstackapi_BdbStartCommissioningReq 的状态？ 例如扫描成功、发送 MAC 关联等

我们已经向 Howjie 查询了他们的 PCB 布局和软件设置、没有发现明显的问题、但是关联请求仍然没有发出。 此外、还使用 SmartRF Studio 测试了射频性能、未发现通道19和其他通道之间存在可疑差异。 因此、我想知道我们是否可以通过软件调试找到更多线索、谢谢。

此致、

水阳

您好、Shuyang、

如 TI Z-Stack API 指南中所述， 在 请求执行Zstackapi_BdbStartCommissingReq()后，zstackmsg_CmdIDs_BDB_notification 将通过 OsalPort 消息传送到应用程序。  因此、您将了解  当前 bdbCommissioningMode (BDB_TUSCING_SUCCESS、BDB_TUSCING_NO_NETWORK、BDB_TCLK_EX_FAILURE、BDB_TUSCING_FAILURE、BDB_TUSCING_FAILURE)的 bdbCommissingStatus (BDB_TUSING 成功、BDB_TING_NO_NETING)。

确保已将设计提交 至 SIMPLELINK-2-4GHz-design-reviews 以供审核、并进一步比较此代码与 之前声明的更可靠的默认 SDK 示例之间的差异。

此致、
Ryan