[参考译文] CC2652R：降低网络状态、导致无法与某些器件通信

您好、Antonio、

每个节点的距离有多远、您是否已使用 CC2592前端验证了正确的 TX 功率输出？  请注意、CC2652P 无需外部功率放大器即可实现+20dBm 的功率。  监听器设备位于何处？  它可能会根据干扰和物理位置丢失数据包。  您是否已过滤监听器日志以排除其他信道11网络以及该信道的噪声一般有多大？  ZC 的一些链路状态条目较差、但大多数条目的传入/传出成本可接受。  已经测试了大得多的网络 、但采用了优化的堆栈设置、可行的报告间隔和最小的干扰。

此致、
Ryan

您好、Ryan、

所有节点都分布在办公室(由3-4台设备分组)、它们距离 ZC (大约在中心)最多15米、最多有2个墙壁可绕过。 功率放大器正常、监听器距离 ZC 约1米。 我没有从监听器中排除其他网络、但没有显示其他 ZigBee 网络。

我在另一种情况下看到了18台路由器和1台终端设备的相同行为。 在这种情况下，协调器不在中间位置，路由器分布在3个组中：1个组非常靠近协调器，1个组位于10米处，有2个旁路门，1个设备位于中间。 对于最远的群体、ZC 也没有噪声和良好的可达性。 在这种情况下、问题也会影响非常靠近协调器的某些设备。 另一个问题是终端设备的父设备没有协调器的有效链路状态条目、因此它会将报告发送给父设备、但路由器不会重定向消息。

我们已经完成了一些测试。 我们可以通过执行以下步骤重现此问题：发送 SYS_RESET_REQ、然后等待几分钟、再发送 STARTUP_FAN_APP 消息。 在此时间间隔内，我们在所有路由器中都看到了与 ZC 相关的链路状态成本降低，然后在某个点完全删除该条目。 由于 ZC 处于非活动状态、我认为这是可以接受的。

但是，在恢复 ZC (又称启动消息)后，并非所有路由器都能够恢复到 ZC 的路由，其中一些路由器停止报告数据和 NWK 消息。 我认为这是导致问题的原因。

您是否有任何意见/建议来避免这种行为？

您链接的文档非常有趣。 我们对旧 ZC (基于 CC2530)进行了类似的更改。 由于我们的方案使用更多 ZR 来完成测试、您是否建议我们默认应用这些更改？ 标准路由支持 ZR 的编号限制是多少，最好切换到 MTO 路由？ 换言之：我们如何确定哪种路由更适合我们的方案？

感谢您的支持、
Antonio

您好、Antonio、

您的网络问题似乎是由 CC2530路由器的路由机制引起的、而不是由 CC2652R 协调器引起的。  您可以参阅 已知问题 E2E 讨论页面 、获取有关优化 Z-Stack 3.0.2的建议。  Zigbee 路由是自愈的、并由预构建的 Z-Stack 库自动控制、但是、在检测到路由或消息传输失败时、您可以使用 NLME_RouteDiscoveryRequest 强制路由发现应用。  当然、在您的协调员再次处于活动状态之前、这些操作将不会成功。

多对一路由是一种特殊的路由方案，用于处理涉及集中通信的情形。 它是 Zigbee PRO 功能集的一部分、有助于更大限度地减少流量、尤其是当网络中的所有器件向网关或数据集中器发送数据包时。  您可以在《Z-Stack 用户指南》的"Z-Stack 概述"部分中阅读更多相关内容。  我建议您根据您的用例对其进行评估。

此致、
Ryan