[参考译文] CC2530：ZED 在孤立后无法重新加入

您好！

我无法使用3.0.2 ZED 来重现此问题。

您能否验证 ZED 是否在您的环境中成功接收信标？
尝试检查 是否在 ZED 孤立对象之后调用了 ZDO_BeaconNotifyIndCB 并发送信标请求。

此致、
Toby

Toby Pan 如果您在20190815_CANno_inuate_dk.cWBX 中查看了数据包编号678和680、则器件实际上会发送信标请求并从协调器获取信标帧、我们的问题是为什么器件不会立即重新加入过程。 这将 延长休眠终端设备的孤立状态。 我们的许多终端设备都是 IAS 区域设备、在危急情况下无法承受这种延迟。 请帮助您从 CC2530DK 的一方重现此问题、并尽快提供修复。 谢谢。

我将尝试在我的环境中重现此情况。
您在 DK 上重现此内容的频率如何？
请注意、对于第一个信标请求(pkt678)、信标(pkt680)在426毫秒后发出。 在这种长时间的延迟下、ZED 会假定未接收到信标、并等待定义的延迟、然后再发送下一个信标请求。 您将什么用于 ZC？
对于下一个信标请求(pkt701)、信标(pkt702)在2ms 后发出、然后 ZED 发送重新加入请求。

是的、监听器日志中显示了信标。
但是、ZED 必须在处理信标之前接收信标。
表明它已接收到信标的一个指示是它进入 了 ZDO_beaconNotifyIndCB 函数。
您能确认这种情况在 ZED 上发生吗？

尊敬的 Toby：

百分比为15%。 OTA (OTA 完成、系统重置但不重新加入)后、我们通常会看到此问题。 我们同意您的观点，ZED 不输入 ZDO_BeaconNotifyIndCB --> ZED 不发送重新加入请求。 在其他测试中 、信标请求和信标之间的时间间隔小于3ms。 但 ZED 不会输入 ZDO_beaconNotifyIndCB。 令人担忧的是、ZED 从 ZC 轻松丢失信标的原因。 接下来、我们将在屏蔽室中检查此问题。

您好、Kimi、

感谢您的验证。

显然、ZC 接收来自 ZED 的信标请求、但 ZED 不接收信标。
这可能与射频有关(例如拥塞/噪声通道、ZED 与 ZC 的 TX/Rx 功能差异等)、因此我同意在屏蔽室中测试一个网络是一个很好的下一步。

此致、
Toby

尊敬的 Toby：

目前为止、我们无法在屏蔽室中重现此问题(请继续测试)。 如果我们获得更多信息、我们将进行更新。 谢谢你

@Toby、如果我们不能在屏蔽室中重现这种情况、但却能在真实环境中看到它、我们该怎么办？ 我的意思是、当我们将 ZC 和 ZED 彼此关闭时、我看不到器件在实际环境中无法接收信标帧的原因。 RF RX 窗口是否可能打开过短、因此 ZED 有时会错过信标帧？ 如果是、我们是否可以调整任何参数以放大射频 RX 打开窗口？

在屏蔽室中、信标请求和相应信标之间的时间是多少？

要增加扫描持续时间、可以增大 BDB_DEFAULT_SCAN_DURATION 的值(默认为4)。

扫描持续时间的公式为：
- MAC_A_BASE_超级 帧持续时间*(2^BDB_DEFAULT_SCAN_DURATION + 1)

尊敬的 Toby：

我们再次出现问题" ZED ENTER ZDO_beaconNotifyIndCB、但不发送重新加入请求"。 我在办公室(不是屏蔽室)测试它、但将信道更改为17 (更少干扰)。 我在 ZED 输入 ZDO_beaconNotifyIndCB 时添加"闪烁 LED"。

e2e.ti.com/.../20190829_5F00_openSpace_5F00_rejoin.zip

您好、Kimi、

现在您可以重新创建问题、请尝试调试 ZDO_beaconNotifyIndCB。  我们正在尝试确保变量"Selected"变为 true 并且 pNWKDESC 被正确填充。   pBeacon ->LQI 是否大于 gMIN_tree_LQI？  您可能需要在 NWK_globals.c 中减小此值

此致、
Ryan

您好、Kimi 和 Toby。

   我们完成了相同的测试。 不幸的是，我们不能重复这种做法。 但我们在测试中发现了另一个问题。

协调员在收到"信标请求"后不回复"信标"。 附加文件。 “从数据包 240”显示此问题，重新加入时很容易发生。

HDK：SmartRF05

SDK：Z-Stack 3.0.2

此致。

Dennis

e2e.ti.com/.../2134.coordinator_5F00_not_5F00_response_5F00_beacon_5F00_requesth.zip

@Ryan，我们可以看到这个新问题：如 Dennis 所述，“协调员在收到“信标请求”后不回复“信标”。 您能否帮助检查此新问题？

Dennis、

根据日志、您似乎正在关闭协调器以触发 ZED 成为孤立。

是否确定在发送信标请求之前 ZC 处于联机状态？

此致、
Toby

你(们)好。

     感谢您的回复。 事实上，其中大多数 是 协调员 ，而不是在线的。 但 ZC 无响应的情况 很容易重复、
当 ZED 发出信标请求时、协调器(在线)可能不会响应约15~20%。

谢谢。
BR

Dennis

作为调试工作的一部分、您能否修改协调器、以便它在启动后发送无线消息？

在*_EVENT_LOOP 中是一个很好的执行此操作的地方、例如：

案例 ZDO_State_change：
UI_DeviceStateUpdated((devStates_t)(MSGpkt->HDR.status))；
// Toby 已添加，适用于 e2e 830357
if (MSGpkt->HDR.status =DEV_ZB_COord)
｛
BDB_StartCommissioning (BDB_commissioning_mode_NWK_Steering)；
｝
//添加结束
中断； 

一旦器件完成启动例程并作为网络中的协调器运行、这将通过无线方式发送一条"管理许可加入请求"消息。 (另一个选项是发送虚拟广播消息)。

此消息之后、协调器收到的任何信标请求都应由信标响应。

enterHi Toby。

   很抱歉耽误你的回答。 作为附加文件。  ZC 根据您提供的设置进行修改、仅使 ZED 进入 下电上电循环以执行测试。  下面列出了 ZC 不响应信标的数据包编号。

数据包1：ZC 开机

数据包104： ZED 执行下电上电并尝试重新加入，ZC 对信标请求无响应

数据包159 ： ZED 打功率循环 并尝试重新加入，ZC 对信标请求无响应

数据包220~222 ： ZED 执行电源循环 并尝试重新加入，ZC 对信标请求无响应

Regardse2e.ti.com/.../ZC-always-on_2C00_-power-cycle-the-ZED_5F00_190910.zip