[参考译文] CC2652R7：ZStack 协调器和 ZED 睡眠功能

Sylvain、您好！

您的 ZED 是否也是使用相同 SDK 的 TI 器件？  如果是、评估的示例是什么？  ZC 无法控制休眠终端设备的功耗。  ZED 电源运行模式是在 SysConfig 的 Z-Stack ->电源管理模块中确定的、您也可以在该模块中确定轮询周期。  如果您未在定制板上使用 CUI (客户用户界面、即 LED、按钮和 UART)、则应修改 Project Properties -> CCS Build -> Arm Compiler -> Predefined Symbols 以定义"CUI_disable"和"xBOARD_DISPLAY_USE_UART"、而不是其先前的设置。  Z-Stack 用户指南的"电源配置"部分对此进行了说明、您也可以在其中参阅 Z-Stack 概述 部分以了解有关 ZED 行为的更多信息。  如何确定 ZED 未进入睡眠模式？  即使是休眠式终端设备也可以在数据轮询后响应 ZC 请求、或在必要时发送 ZCL 消息。  TI 每季度对 SDK 进行一次更新、测试和验证一次 ZED 的功耗、以确保提供强大可靠的解决方案。

此致、
Ryan

您好、Ryan、

我的 ZED 不是 TI 器件。

我正在寻找有关睡眠机制如何工作的信息、以确定 ZC 和 ZED 之间的误差。 根据您的回复、我认为这是 ZED、因为 ZC 无法控制 ZED 的睡眠/运行功能。

对于我的 ZC、我已经完成了(我认为)有关 CUI、按钮、UART 所需的一切... 它工作正常。

我通过监控功耗来确定 ZED 是否处于睡眠模式。 实际上、这是一种深度睡眠模式、其中无线电应关闭(遗憾的是、情况并非如此)。 在这种状态下、只有 RTC 或硬件中断可以唤醒系统并恢复通信。

在等待 ZED 制造商提供的信息时、我将让该主题打开几天。 它可能会引起有关 ZStack 的新问题。

无论如何、感谢您的快速回复。

Sylvain Serre

ZED 仅会唤醒以轮询其父节点，以检查是否有任何数据可供其接收。 如果是、它会在短时间内打开 RX 以接收数据、并停止 RX 以进入睡眠模式。 否则、ZED 将直接进入睡眠状态。 其他唤醒 ZED 的东西是 GPI 中断或计划计时器事件。 否则、ZED 处于睡眠模式。

您好！


我在查找和绑定过程中使用协调器(CC2657R7)和 ZED 器件之间的 zShark/Wireshark ZigBee 交换进行监听、并将其发送给 ZED 制造商。 以下是他的回答：

1.TI GW 在我们的器件公告(434、436)之后启动了路由请求帧(447)、这不是预期行为。

2.APS 用于节点描述符响应(439)的 Ack (449-452)直接从 GW 发送到终端设备、而不会从终端设备发出轮询请求(数据请求)。

在中间、我们可以看到终端设备收到的带有轮询请求的几个帧。

由于基于帧546至549的密钥交换失败、因此通信在这之后不会建立、并且我们的器件不会进入深度睡眠模式。


此时、我真的不知道如何解决此问题。 我对 Zigbee 的了解太少、无法判断哪个器件出现故障。

这里有人是否足够好地从 TI 角度查看 Wireshark 日志？ (我想将其附加到我的邮件中、但我找不到如何处理)

ZED 是直接加入 ZC 还是通过 ZR 器件加入 ZC？  网络中当前存在多少个设备、您是否可以将测试网络减少到仅两个设备、以便更好地进行调试？  此外、ZED 使用的是 Zigbee 3.0还是不同的规格版本？  您可以直接将监听器日志拖放到回复框中、或单击插入->图像/视频/文件、然后导航到计算机上的日志目录。

此致、
Ryan

您好！

ZED 直接加入 ZC。

网络上只有这个 ZED、没有更多了。

ZED 使用3.0 R22

正如我了解 ZED 制造商所解释的那样、日志显示 ZC 的作用就像 ZED 是 ZR 而不是 ZED。 结果是 ZC 发送数据而不首先接收数据请求。

e2e.ti.com/.../CoordinatorTiVsZED_5F00_20230201.zip

您是否有可提供的网络密钥和/或过滤监听器日志参数？  如果设备中的功能信息从 ZED 声明、将设备类型位显示为 FFD (全功能设备)而不是 RFD (精简功能设备)、则将其视为 ZR 节点。  其他重要位包括空闲时的电源和接收器打开、尽管这些位不应影响 ZC 的行为方式。  ZR 的功能信息字节通常为0x8E、而 ZED 的容量信息字节通常为0x80。

此致、
Ryan  

很抱歉、是的、我有 Wireshark 筛选器。 最初由 zShark 推荐的一个： udp.port=17754 && ip.TTL=128 &&!icmp

但 ZED 制造商使用更好的一个(我认为)： zbee_nwk.proto_version ==2.

我将尝试找到 Device Announce 消息以了解有关 FFD/RFD 的信息。

感谢您迄今为止的帮助！

您好、再说一次、

我可以确认 ZED 不是 FFD。 这是设备通知字段

顺便说一下、要分析数据、进入 Wireshark 的关键是"5A：69：67：42：65：65：41：6C：69：61：6E：63：65：30：39"(ZigbeeAllianc09)

我无法使用 Wireshark 3.0.X 或4.0.X 对数据包进行解密、因此难以进一步诊断问题。  在首选项中输入默认的全局链接密钥。

此设备或 IEEE 地址是否可能以前作为路由器节点加入了网络？  您是否曾尝试在出厂时重置 ZC、或在重新编程之前擦除所有器件存储器？

此致、
Ryan

我怀疑 Zed 以前作为路由器加入了网络、自我们开始测试以来、其代码没有变化。

我没有尝试擦除所有 ZC 存储器、这是我可以尝试的。

我刚刚收到另一个(不同的) ZigBee Zed、用于比较和查看是否存在相同的问题。 我会告诉你。

此致、

Sylvain

您好！

我测试了另一个有效的 ZED ((MIR - TE100-TY)。 这是 Wireshark 日志。

我可以轻松地看到一个不同之处，这次来文是在找到和约束之后停止的，这是应该的。 但我不能说更多了。 我已将这些日志发送给 ZED 制造商进行分析。

Ryan、很奇怪您无法使用 Wireshark 解密日志。 我使用 Wireshark 版本4.0.3 (v4.0.3-0-gc552f74cdc23)、其中包含一个非常简单的筛选器/密钥、请参阅所附图像。

e2e.ti.com/.../CoordinatorTiVsTuyaTherm.zip

如果有人告诉我 First Zed 出了什么问题、那会非常有帮助...

谢谢、

Sylvain

您是自行设计 First Zed 还是由第三方设计？

它是一款基于微芯片解决方案的自设计产品、定制硬件。 ZigBee 堆栈也来自 Microchip。 这就是我在每个步骤向 Microchip 和 TI 发送信息的原因、直到我发现错误所在。

我认为问题是器件方面的。 如果是 Microchip 解决方案，您应该联系并等待 Microchip 响应。