• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 3 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 347 次查看
  • 用户 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.

[参考译文] CC2652P：19个器件的开放式现场直线应用中的延迟和配对问题

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1179401/cc2652p-latencies-and-pairing-troubles-in-an-open-field-straight-line-application-with-19-devices

器件型号：CC2652P

早上好。

我们正在测试一个自定义应用程序、该应用程序涉及一些基于 zr_genericapp 和 zed_genericapp 的自定义固件、我们的最后一个设置由以下拓扑表示：

在有14个定制 ZED、3个定制 ZRS 和1个默认 ZR 的情况下，每台路由器与其他路由器以直线的距离约40米，而终端设备则位于路由器之间的路径中。

每个器件都设置为以20dBm 的功率传输、我们在几乎农村地区使用一些偶极式的 TX 天线。

定制设备包含8个智能插头型端点。

我的目标是测量每个端点的每个计量度量度量的轮询时间(仪表组的当前汇总交付结果)。

我发现的问题主要是：

  1.  我将实验室中的所有器件配对、因此终端器件与某些父设备以与最终拓扑不同的临时方式配对、认为它们会在现场更改父设备、从而找到最佳的设备： 仅对7-8个 ZED 就正确地发生了这种情况，其余的 ZED 最终导致网络图中的断开连接。 因此、我必须走到断开的引脚才能重置和重新配对、从而形成正确的最终拓扑。 我缺少什么？ 我避免了现场配对、因为通常它需要可变的重试次数(出厂重置和按下配对按钮)、因为第一次尝试时几乎不会进行配对和面试、而在实验室(桌面)中、它们始终成功完成。
  2. 由于我具有所需的拓扑、我运行我的脚本以轮询每个器件端点(每个器件8个)、以了解我感兴趣的2个集群属性、即 currentSummDelivered 和 OnOff： 我遇到的延迟不是很好、获取完整仪表/ONOFF 所需的时间大约为1m 33s 轮询8个端点、24s 轮询1个端点(请参阅日志)。 

Field test, top 5, 3 routers, 14 end devices, 1 endpoint polled for each device
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Device: 0x00124b0025906ff3 [Router],            Time elapsed: 104.0501ms, Average per attribute : 52.02505ms
Device: 0x00124b00259087a1 [EndDevice],         Time elapsed: 111.1384ms, Average per attribute : 55.5692ms
Device: 0x00124b0025908a6a [EndDevice],         Time elapsed: 110.2387ms, Average per attribute : 55.11935ms
Device: 0x00124b0025907cb1 [EndDevice],         Timed out
Device: 0x00124b002590e021 [Router],            Time elapsed: 794.8357ms, Average per attribute : 397.41785ms
Device: 0x00124b002590dd33 [Router],            Timed out
Device: 0x00124b002590e188 [EndDevice],         Timed out
Device: 0x00124b0025910009 [EndDevice],         Time elapsed: 132.7311ms, Average per attribute : 66.36555ms
Device: 0x00124b0025907b5c [EndDevice],         Time elapsed: 435.9508ms, Average per attribute : 217.9754ms
Device: 0x00124b0025908a25 [EndDevice],         Time elapsed: 319.9962ms, Average per attribute : 159.9981ms
Device: 0x00124b002590f613 [EndDevice],         Time elapsed: 381.8213ms, Average per attribute : 190.91065ms
Device: 0x00124b0025909133 [EndDevice],         Time elapsed: 282.9713ms, Average per attribute : 141.48565ms
Device: 0x00124b0025907b63 [EndDevice],         Time elapsed: 151.1411ms, Average per attribute : 75.57055ms
Device: 0x00124b002591071d [EndDevice],         Time elapsed: 157.2716ms, Average per attribute : 78.6358ms
Device: 0x00124b002590e1d0 [EndDevice],         Timed out
Device: 0x00124b002590dd78 [EndDevice],         Time elapsed: 645.0995ms, Average per attribute : 322.54975ms
Device: 0x00124b002590fbf6 [EndDevice],         Time elapsed: 467.6726ms, Average per attribute : 233.8363ms
Full poll time: 23.9009177s
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Field test, top 5, 3 routers, 14 end devices, 8 endpoints polled for each device
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Device: 0x00124b0025907b63 [EndDevice],         Time elapsed: 1.4851941s, Average per attribute : 92.824624ms
Device: 0x00124b0025910009 [EndDevice],         Time elapsed: 785.6044ms, Average per attribute : 49.100267ms
Device: 0x00124b002590e021 [Router],            Time elapsed: 3.1569569s, Average per attribute : 197.3098ms
Device: 0x00124b0025908a6a [EndDevice],         Time elapsed: 1.4947743s, Average per attribute : 93.423387ms
Device: 0x00124b0025909133 [EndDevice],         Time elapsed: 3.2124645s, Average per attribute : 200.779026ms
Device: 0x00124b002590e1d0 [EndDevice],         Time elapsed: 1.8394391s, Average per attribute : 114.964936ms
Device: 0x00124b0025906ff3 [Router],            Time elapsed: 3.4791768s, Average per attribute : 217.448546ms
Device: 0x00124b002590dd33 [Router],            Timed out
Device: 0x00124b0025908a25 [EndDevice],         Time elapsed: 1.5380671s, Average per attribute : 96.129187ms
Device: 0x00124b002590dd78 [EndDevice],         Time elapsed: 2.8397282s, Average per attribute : 177.483006ms
Device: 0x00124b0025907cb1 [EndDevice],         Timed out
Device: 0x00124b002590fbf6 [EndDevice],         Timed out
Device: 0x00124b00259087a1 [EndDevice],         Time elapsed: 1.0135207s, Average per attribute : 63.345037ms
Device: 0x00124b002591071d [EndDevice],         Time elapsed: 703.0589ms, Average per attribute : 43.941175ms
Device: 0x00124b002590f613 [EndDevice],         Time elapsed: 1.1584657s, Average per attribute : 72.4041ms
Device: 0x00124b002590e188 [EndDevice],         Time elapsed: 1.8645467s, Average per attribute : 116.534165ms
Device: 0x00124b0025907b5c [EndDevice],         Time elapsed: 2.1748023s, Average per attribute : 135.925138ms
Full poll time: 1m33.2618987s
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

因此、在此测试中、具有智能插头端点的器件仅为17个(3个定制路由器+ 14个定制终端设备)、 但我们希望单个协调器处理其中大约200个、并仔细划分在路由器和终端设备中、以避免需要太多的路由器-路由器跃点(我们尝试将其限制为10个)。

换言之、我们要将拓扑图画出来、将器件编号提高到30、使其像一个以协调器为中心的星型的硬钎焊、例如其中6个分支。

它如何扩展？ 我们是否可以在10分钟内查询每个器件每个端点的完整计量和 ONOFF 属性？ 对于驱动、我们是否可以可靠地命令'ON'或'OFF'命令、并在一秒后确认其上一状态和下一状态？

这种应用是否真的适合使用 Zigbee 协议来完成？ 或者我们可能必须评估一些 WiFi 模块？ 将协调器替换为接入点、 使用 WiFi 中继器的 ZigBee 路由器和具有客户端节点的终端设备。

我们非常感谢您的任何建议。

再次感谢您极其准备就绪的支持。

Roberto

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

    您好、Roberto、

    1.请查看集中式网络的非安全加入。  默认情况下、在 尝试取消安全/信任中心重新加入之前、终端设备将尝试安全地重新加入相同的网络 BDB_MAX_SECURE_RESINON_Attempts 时间。  如果 MAX_RESUE_RETRY 已被禁止 或 TC 重新加入失败、则器件将尝试正常加入、这要求从路由节点打开网络以加入。  此外、如果信任中心在 TC 通过 MAX_DEVICE_UNauth_TIMEOUT 重新加入后未对器件进行身份验证、则器件将恢复出厂设置。  您可以修改 ZD_app.c 以更改此行为、如以下 E2E 线程示例所示：

    https://e2e.ti.com/f/1/t/1163283 
    https://e2e.ti.com/f/1/t/1176456 

    我们已经讨论了延迟和休眠式 ZED 轮询与您之前的 E2E 主题中始终开启的情况。  应该可以 在10分钟内轮询属性，特别是在使用组或广播时。  还提供自动属性报告、是否已经考虑过此问题？  您可能 有多个 Zigbee 网络、其中 ZC 是一个网关、它向通用云服务报告命令并从该服务接收命令、因此它似乎位于一致的 Zigbee 网络上。  仍然可以在没有云/网关选项的情况下使用具有200个节点的 Zigbee 网络、但创建特定的器件关联(如果需要)将是一项挑战。

    此致、
    Ryan

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

    你好、Ryan

    感谢您的参与、我将尝试将终端设备重新加入行为设置为 false (默认为 true)、并将 BDB_MAX_SECURE_REALING_REALIESS_REGINPESS_REGANESS_REGINVESS_ANTESS_REGESS_REGESS_REGESS_REGESS_  

    关于第二点、我已将终端设备设置为始终开启、因此 Zigbee2Mqtt istance 轮询其群集属性之一所需的时间与路由器所需的时间(50到100ms)相当、 因此、大约20个器件的完整轮询需要将近2分钟、您认为这是可以达到的最小延迟吗？

    对于考虑半直线路由器和终端设备的拓扑、自动属性报告似乎不是最佳选择。 是这样吗？

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

    如果我理解正确、20个器件各有8个具有2个属性的端点、因此您将发送320个读取请求、这将触发相同数量的读取响应。  如果每个请求/响应双向通信花费400ms 完成(假设需要重试)、则总共大约需要2分钟。  SWRA650 在更大的网络中表现出更低的延迟。  由于属性报告是单向的、因此这减少了端到端数据包完成距离和所需数据包总数。  它还降低了 ZC 发送如此多消息的压力。  您可以创建一个计时器来跟踪已报告的终端设备以及是否缺少任何终端设备。

    此致、
    Ryan