• 状态 Resolved
  • 已锁定 已锁定
  • 回复 33 回复
  • 订户 0 订户
  • 视图 1107 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC2538-CC2592EMK：路由器向终端设备发送保留请求。

admin
Guru**** 2864540 points

Other Parts Discussed in Thread: CC2592, Z-STACK

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/686980/cc2538-cc2592emk-router-sending-leave-request-to-end-device

器件型号：CC2538-CC2592EMK
Thread 中讨论的其他器件：CC2592、 Z-stack

您好，

路由器为什么要向终端设备发送休假请求？

请查找随附的监听器日志。请参阅数据包 ID -89-92

e2e.ti.com/.../router-sending-leave-to-end-device-packet-count-89_2D00_92.rar

  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Dhanraj、

    Nwk_end_dev_timeout_default 值是什么？ 由于之前的数据包中不涉及 ZED、因此很难诊断这种情况。 如果终端设备由于缺少数据请求轮询而超时、则将发送休假请求。 由于缺少 ZR 对数据请求的响应、它也似乎围绕着0x16FB 和0x4827孤儿院的重新加入请求进行包装。 0x2738似乎在几秒钟后以任何速率成功重新加入。 监听器日志中还缺少几个数据包。

    此致、
    Ryan
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我应该在路由器代码或 ZED 代码中检查此项(NWK_END_DEV_TIMEOUT_DEFAULT)吗？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    ZED 的 ZR 代码、END_DEV_TIMEOUT_VALUE (ZGlobals.h)和轮询值(f8wConfig.cfg)。

    此致、
    Ryan
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    ZR，ZGlobals.h
    NWK_END_DEV_TIMEOUT_DEFAULT 8.
    end_dev_timeout_value 8.
    NWK_END_DEVICE_LEW_TIMEOUT 9.

    ZED，f8wConfig.cfg
    -DPOLL_RATE = 5000
    -DQUEUED_POLL_RATE = 100
    DRESPONSE_POLL_RATE = 100
    -DREJOIN_POLL_RATE = 440
    -DREJOIN_BACKOFF=900000
    -DREJOIN_SCAN=900000
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    捕获 ZR 在上次有效 ZED 数据轮询期间发送离开请求的事件。 还要确保 ZR 子系统的数量不超过其 NWK_MAX_DEVICE_LIST。

    此致、
    Ryan
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    好的、我将捕获特定事件。

    那么，您基本上认为 ZED 不发送数据请求，路由器也不接收来自 ZED 的数据请求，因此路由器正在发送休假请求？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    基本上、如果 ZED 在一段时间内未向其父节点发送数据请求、则其父节点将使 ZED 过期、父节点将在父节点接收到来自 ZED 的任何消息时发送 Leave 请求以要求器件重新加入。 这是 Zigbee 3.0中的子老化行为。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    如何更改路由器中的子年龄超时期限？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您可以更改 NWK_END_DEV_TIMEOUT_DEFAULT 以使其成为目标。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    默认值为-
    #define NWK_END_DEV_TIMEOUT_DEFAULT 8 //每个 ZigBee 核心规范的默认值为8
    > 8的单位是什么？

    我认为以下参数也与离开请求或删除设备有关？
    //超时，结束设备将从间接 MAC 消息队列中删除
    //注意：轮询速率低于此速率的终端设备将不会接收到离开请求
    #define NWK_END_DEVICE_LEW_TIMEOUT 9.
    >这里还有9的单位是什么？？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    以下是映射值。

    //儿童老化管理默认值
    //值在 nwk_globals.h 模块的表中指定
    //TimeOutValue[15]
    // 10，// 010秒
    // 2、// 12分钟
    // 4、// 24分钟
    // 8、// 38分钟
    // 16，// 416分钟
    // 32，// 532分钟
    // 64，// 664分钟
    // 128，// 7128分钟
    // 256，// 8256分钟
    // 512，// 9 512分钟
    // 1024，// 101024分钟
    // 2048、// 112048分钟
    // 4096，// 124096分钟
    // 8192，// 138192分钟
    // 16384 // 1416384分钟
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    所以

     #define NWK_END_DEV_TIMEOUT_DEFAULT 8 // 8表示实际超时值为256分钟

    如果任何路由器在256分钟内未收到特定 ZED 子级的任何 Mac 数据请求，则如果 ZED 向其父路由器发送任何消息，它将向 ZED 发送休假请求，正确吗？？

    #define NWK_END_DEVICE_LEW_TIMEOUT 9 // 9表示实际超时值为512分钟

    如果任何路由器 在512分钟内未收到特定子 ZED 的任何 Mac 数据请求 ，则该 zed 将从消息队列中删除，正确吗？？  

  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的、您的理解是正确的。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    256分钟是重要的时间，我的 zed 被编程为在5秒发送数据请求，在4小时内，在任何情况下，我的 zed 都将向父级发送1个以上的数据请求，那么为什么路由器会向 zed 发送休假请求？ 这种行为很奇怪？？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    正如 Ryan 所回答的、由于 ZED 未参与任何先前的数据包、因此很难诊断这种情况。 您必须进行完整的监听器日志、以便我们可以判断到底发生了什么。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    如果我将监听器设置在 zed 附近，那么我们也应该能够看到 zed 数据包！！！
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    如果我回答正确、那么您的 ZED 离 ZC/ZR 不远、对吧？ 如果是、位于所有 ZC/ZR/ZED 中心的监听器应能够监听所有消息。 除非您的器件的射频性能有问题。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的、您是对的、所有东西都在不到10米半径的区域内。
    将在中间设置监听器。\n 希望我们能够找出此问题。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我认为您应该首先确保您的射频性能正确。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    /*在指示同步丢失之前重试轮询父级的次数
    *与父级。 请注意、值越大、子项的延迟就越长
    *重新加入网络。
    *
    -dMAX_POLL_FAILY_RETESS=2

    我认为此参数也与 ZED 重新加入相关，应在 ZED 代码或路由器代码中修改此参数，以延迟 ZED 重新加入？？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    这是关于 ZED 的。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    好的，我通过将监听器保持在中心来捕获监听器日志，

    在日志中，我观察到 ZED 发送数据请求，(数据包 ID 1270)

    2分钟后，路由器将删除设备命令发送到该 ZED (数据包 ID 1771)

    PFA 监听器日志！！

    e2e.ti.com/.../data-request-at-1270-and-remove-device-at-1771.rar

  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    e2e.ti.com/.../573b-sending-data-request-but-still-router-sending-leave-request-to-It-at-packet-3061.rarI又捕获了一个事件，我可以在其中看到来自 ZED (573B)的数据请求，但路由器仍在发送数据包 ID 3061处保留请求

  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    许多数据请求没有 Mac ACK。 我怀疑通道26上可能存在 WiFi 或2.4G 干扰。 我建议您移至另一个通道以再次测试。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    正如 Ryan 在我的另一篇博文 ZigBee 频道15、20、25、26中提到的、始终没有 WiFi 干扰

    此外、您还可以在 下面附加的屏幕截图中看到我的测试设置环境中可用的当前 WiFi 信道流量-

     

  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    这是一般情况，但我不知道信道26是否在您的环境中没有 WiFi 干扰。 我只能建议您更改频道以再次测试。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我已编辑了以前的回复并连接了 WiFi 频道流量，频道26上没有 WiFi 流量。
    您还可以在下面的链接中看到，大多数国家/地区都没有 WiFi 频道14，它仅在日本提供802.11b 版本。
    en.wikipedia.org/.../List_of_WLAN_channels

    如果信息不正确、请更正我。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    通道26上的射频性能可能不好。 为什么不尝试其他频道？
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    1) 1)"通道26上的射频性能可能不好。"
    有没有进一步的解释，为什么？？

    我之前也尝试过其他通道。
    您可以在我之前的回复中的附加图片中看到设置环境中的 WiFi 流量、
    我无法选择任何其他 ZigBee 通道，无线流量太大。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    通道26是最后一个通道、位于 Zigbee 802.15.4调制的边界、因此它可能无法像其他通道那样具有良好的射频性能。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    请提供任何提及 ZigBee 通道26射频性能降低的参考文档。
    还需要 TI 专家的意见。
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    你已经提供了一个链接、指向我对此事的评论。 有关频道26的任何其他信息、请在线搜索。

    community.smartthings.com/.../40159
    acuitysupport.zendesk.com/.../225413967-Zigbee-Networking-Basics-35-000ft-view-

    您是否评估了通道15或20？

    此致、
    Ryan
  • 0
    TI__Guru**** 2864540 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢您通过链接处理 WiFi 干扰。

    但我怀疑 ZigBee 通道26为什么会比其他通道具有糟糕的射频性能、正如 YIKAI Chen 在前一篇回复中提到的那样-"ZigBee 通道26可能由于某些调制问题而具有不良的射频性能"。

    关于这一点，我要求提供一些参考文件。

    是的、我之前已经尝试过通道20、15、11、这是非常糟糕的体验、但也有错误、例如在 z-stack 中 cc2592配置不正确。