digi:rf-wireless:xbee:zigbee:antai-debug [Digi产品中文Wiki]

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

--- digi:rf-wireless:xbee:zigbee:antai-debug [2021/07/01 15:13] – [20210701 log] robin
+++ digi:rf-wireless:xbee:zigbee:antai-debug [2021/07/07 13:36] (当前版本) – [20210701 log] robin
@@ 行 251: / 行 251: @@
 共191nodes \\
 ：20改为41/80， 14：29记录15分钟 \\
 测试时间：14:29:07~14:44:37, 共15分30秒 =930S  \\
 测得0xA1=5134  \\
@@ 行 258: / 行 259: @@
 RRI per minute = 269  \\
 估计没代表意义。30分钟再抓一次。  \\
+测试2：改后一小时
+测试时间：15:26:08~15:41:08, 共15分 =900S  \\
+测得0xA1=5207  \\
+xA1(MTO_AR)=5*191=955  \\
+实际0xA1=5207-900=4307  \\
+RRI per second=4.78  \\
+RRI per minute = 287  \\
+RRI在上电半小时和1小时后，有些增幅，需要再测一次，如果趋势保持，说明稳态后没法消除协调器要发的数据大于能处理的数据，需要进行减少密集发送的行动，也就是增大间隔。 \\
+测试3:  注：有人到协调器边上和松讨论 \\
+测试时间：16:01:20~16:17:32, 共16分12秒 =972S  \\
+测得0xA1=5556  \\
+xA1(MTO_AR)=5*191=955  \\
+实际0xA1=5556-955=4601  \\
+RRI per second=4.73  \\
+RRI per minute = 284  \\
+**附：07－01测试结果**
+今天主要做了Disable ACK的测试，效果远好于默认开ACK的方式。考虑到你们昨天晚上有临时开一下ACK效果不佳的情况，很可能是种意外，可进一步观察。\\
+测试的目标是观察RRI指标是否可以在某种调节模式下变好，也即RRI不会越来越差，这样CTS才有可能避免拉高。\\
+今天的测试结果和指标：\\
+共191个节点，Disable ACK在35/50的指标下工作正常，也就是35秒心跳，50秒数据这个上报间隔。在40/80对RRI的抓取结果显示，其RRI每分钟个数为284，效果比之前好一倍。从数据上线率来看，在35/50上也是非常好的（和松一起观察，未记录）。
+**抓包指标分析**
+：20改为41/80， 14：29记录15分钟 \\
+测试时间：14:29:07~14:44:37, 共15分30秒 =930S  \\
+测得0xA1=5134  \\
+xA1(MTO_AR)=5*191=955  \\
+实际0xA1=5134-955=4179  \\
+RRI per second=4.49  \\
+RRI per minute = 269  \\
+**这个抓包在更改后不到10分钟开始，因此意义不大，过30分钟再抓一次。**  \\
+测试2：改后一小时\\
+测试时间：15:26:08~15:41:08, 共15分 =900S  \\
+测得0xA1=5207  \\
+xA1(MTO_AR)=5*191=955  \\
+实际0xA1=5207-900=4307  \\
+RRI per second=4.78  \\
+RRI per minute = 287  \\
+RRI在上电半小时和1小时后，有些增幅，需要再测一次，如果趋势保持，说明稳态后没法消除协调器要发的数据大于能处理的数据，需要进行减少密集发送的行动，也就是增大间隔。 \\
+测试3:  注：有人到协调器边上和松讨论，可视为平时正常小干扰 \\
+测试时间：16:01:20~16:17:32, 共16分12秒 =972S  \\
+测得0xA1=5556  \\
+xA1(MTO_AR)=5*191=955  \\
+实际0xA1=5556-955=4601  \\
+RRI per second=4.73  \\
+RRI per minute = 284  \\
+可见，在有外部小干扰时，RRI指标仍减少，也就是网络拥堵不会进一步恶化，流控CTS事件不会发生。