差别

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

--- digi:rf-wireless:xbee:zigbee:antai-debug [2021/06/24 16:15] – [2021-6-24] robin
+++ digi:rf-wireless:xbee:zigbee:antai-debug [2021/07/07 13:36] (当前版本) – [20210701 log] robin
@@ 行 153: / 行 153: @@
 数据分析： \\
-coordinator端常见failure包：  \\
+coordinator端常见failure包，出现不多：  \\
 unknown: \\
 该节点有数据的三分钟时间内2次 \\
 <code>
-发：7E 00 19 11 F1 00 13 A2 00 41 B6 2B 2D 1E AF E8 E8 00 11 C1 05 00 00 28 00 00 8B C0 12  \\
+发：7E 00 19 11 F1 00 13 A2 00 41 B6 2B 2D 1E AF E8 E8 00 11 C1 05 00 00 28 00 00 8B C0 12
-反馈包：7E 00 07 8B F1 1E AF 00 72 00 44   \\
+反馈包：7E 00 07 8B F1 1E AF 00 72 00 44
 delivery status: 72 (Unknown)
 </code>
+Address Not Found: \\
+该节点有数据的三分钟时间内x次 \\
+一般过8秒没收到ACK即为这错误, 有数据的那5分钟內只出现1次 \\
+<code>
+发：7E 00 19 11 A4 00 13 A2 00 41 B6 25 BE F3 61 E8 E8 00 11 C1 05 00 00 4C 00 00 8B 5E 8B
+反馈包：7E 00 07 8B A4 FF FD 00 24 00 B0
+delivery status: 24 (Address not found)
+</code>
+结论：主动下行发数据似乎还行，出错概率小！
+上行数据测试 \\
+外接个模块，40秒定时发心跳包：\\
+发送100个中，有54个Network ACK Failure \\
+<code>
+发送：7E0019110100000000000000000000E8E80011C10500002D00000BCD41
+正常反馈包：7E00078B01000000000073  有43个
+Network ACK Failure: 7E00078B01000000210052 有54个
+Network ACK Failure：7E00078B01000000210250  有3个
+两种差别在：Discovery Status，少的这种是02(route discovery)，多数是：00 (No discovery overhead)
+可见上发是主要问题，最常见错误是Network ACK Failure, 00 (No discovery overhead)
+</code>
+test module to coord:{{ :digi:rf-wireless:xbee:zigbee:10s-keepalive-disableack-final.zip |}}
+cord received:{{ :digi:rf-wireless:xbee:zigbee:20210624-final-194-receive-10s-keepalive-from-test-module.zip |}}
+withack module to cord: {{ :digi:rf-wireless:xbee:zigbee:api_console_session_2021-06-24-final2.zip |}}
+withack cord: {{ :digi:rf-wireless:xbee:zigbee:20210624-final-194-receive-10s-keepalive-withack.zip |}}
+====20200628-log====
+节点 测试重包情况 \\
+测试模块手动发10个包，每个包带不同的序号作为payload，查看目标丢包和收到包的详细数据 \\
+首先测ACK没禁用的默认情况： \\
+有MTO时一般挺好的，当出现ACK Failure时有多收或丢包情况，此时一般没MTO，可能是路径有变化MTO没来有影响？\\
+挑一段发送不成功的时间段记录如下，都是NetWork ACK Failure的错误，反馈包一般都是发送后5秒才有，虽然反馈包显示错误，但实际上有些协调器是成功收到的。\\
+包：发1个，收到2个。\\
+发：[2021-06-28 14:37:58.354] \\
+收：[2021-06-28 14:37:59.274][2021-06-28 14:38:02.274] \\
+包：发1收1，正常 \\
+发：[2021-06-28 14:38:06.425] \\
+收：[2021-06-28 14:38:10.837]\\
+包：发1收1，正常 \\
+发：[2021-06-28 14:38:16:962] \\
+收：[2021-06-28 14:38:21.149]  \\
+包：发1收1正常  \\
+发：[2021-06-28 14:38:28:099] \\
+收：[2021-06-28 14:38:29.242] \\
+包：发1收1正常  \\
+发：[2021-06-28 14:38:34.634] \\
+收：[2021-06-28 14:38:36.144] \\
+包：发1收1正常 \\
+发：[2021-06-28 14:38:40.746]  \\
+收：[2021-06-28 14:38:42.196] \\
+包：丢  \\
+包：丢  \\
+包：发1收1正常 \\
+发：[2021-06-28 14:38:59.534]  \\
+收：[2021-06-28 14:39:03.680]  \\
+包： 发1收3  \\
+发：\\
+[2021-06-28 14:39:05.287]  \\
+收：\\
+[2021-06-28 14:39:06.305]  \\
+[2021-06-28 14:39:07.898]  \\
+[2021-06-28 14:39:09.526]  \\
+结论： Network ACK Failure在测试环境实际上成功率约80%，如果关掉这个，可以减少重发的包，增强可靠性。\\
+为什么会发生Network ACK Failure的情况呢，猜测是上行通的，下行ACK丢了，因为数据包用0x21，但ACK并没有实许source routing，为了验证这个，发10个keepalive,计算发送端router收到的keep alive确认包，如果确认包和实际发成功被协调器收的包数量一致，则确实是ACK发生丢包。
+不仅ACK丢，MTO也会丢，有时会长时间没收到MTO。
+当network ack failure时，发送keepalive包大多要等1分~3分钟才收到响应包，也就是缓冲区满了，CTS拉高，所以协调器没有发送时机，**缓冲区是0x11独占的，还是0x21也要占用缓冲区？ACK呢，它是否也占缓冲区？**
+考虑到现在节点是192个，数据量还是有点大：协调器每秒处理14.4个包，相当于69ms就有一个包要处理。
+可能的改时：想办法让目标组在发送前收到MTO，看看有什么指令可以产生，ATDN？这个可能只能有路径不可用时产生，不够也许也有用。
+====20210701 log====
+上午主要测试60/120 ，中午改为disale ACK, 测试61/120,51/100 稳定。\\
+共191nodes \\
+：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  \\
+估计没代表意义。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事件不会发生。