====2021-6-22 debug====
网络参数：OP＝97A4276E7600F09A OI＝80E5 CH＝17 \\
注意AR产生MTO，0xA1需要排除正常MTO产生的数量。而我们有上次ZS=0，AR＝0时数据。\\
本次测试ZS=2 AR=3分钟 120节点 \\
120节点 第一次数据：\\
测试时间： 11:55:16~12:05:05 \\
time:9分49秒＝589S \\
0xA1(AR_MTO)=3次广播*节点数＝360 \\
实测0xA1 : 1626 \\
0xA1（非AR因素）=1626-360=1266
RRI per second: 2.15 \\
RRI per minute: 129
结论： ZS＝0时RRI每分钟为300以上
120节点，第二次数据： \\
测试时间：12:56:01~13:41:42 \\
45分41s= 2741S \\
0xA1(AR_MTO)＝15*120＝1800 \\
实测0xA1: 7514 \\
0xA1(非AR因素)=7514－1800＝5714
RRI per second ： 2.08 \\
RRI per minute: 125\\
比ZS=2时最优的300减少一半以上的RRI,相当于带宽提升一倍多。 \\
（注，上述120台数据已经是上电稳定后的网络）\\
此时未有80台的数据，14：18 断电36台，等15分钟以上 \\
14：40开始采数据\\
80节点第三次采数据：\\
测试时间：14:40:12~14:55:41 \\
共15分29秒=929S \\
0xA1(AR_MTO)= 5*80=400 \\
实测0xA1:481 \\
0xA1(非AR因素)=81
RRI per second: 0.089 \\
RRI per minute= 5.2 \\
比ZS=0时的144，MTO减少28倍，相当于带宽提升28倍。 \\
15：23上电达138台
15：43开始采数。 \\
共138节点，第四次测试:\\
时间：15:44:33~15:58:23 \\
共：13分50秒 = 830S \\
0xA1(AR_MTO)=4*138=552
实测0xA1: 3047 \\
0xA1(非AR因素) =2495
RRI per second： 3.0 \\
RRI per minute: 180 \\
比上次ZS=0时321提升不到1倍 \\
提升不多可能是网络未稳定就采数，再抓次数据。 \\
测试时间 16:19:17~16:31:41 \\
共12分24秒 = 744S \\
0xA1(AR_MTO)=552
实测0xA1 2753 \\
0xA1(非AR因素）＝2201
RRI per second: 2.96 \\
RRI per minute: 177 \\
比ZS=0时的321提升约2倍左右（略小于2倍）\\
总结： \\
^ 节点数量 ^ ZS＝0时A1/分钟 | ZS＝2时A1/分钟 | 提升 |
| 80 | 144 | 5.2 | 28倍 |
| 120 | 300 | 125 | 2.4倍 |
| 138 | 321 | 177 | 1.81倍 |
17:10上电节点数增到193
====2021-06-23 debug====
半个小时不通上，会离网\\
一个晚上下来，有10个节点退网加到另一个测试通信箱中\\
记录如下：\\
^MAC ^Name ^
|00-13-A2-00-41-B5-1E-B0 |SH-CU-R-3 |
|00-13-A2-00-41-B4-F8-AE |Apr-K8 |
|00-13-A2-00-41-B4-DC-8A |H5 |
|00-13-A2-00-41-B4-F8-49 |Apr-D7 |
|00-13-A2-00-41-B6-2B-40 |Apr-E1 |
|00-13-A2-00-41-B6-25-EF |Apr-M6 |
|00-13-A2-00-41-B6-2A-C8 |Apr-C2 |
|00-13-A2-00-41-B4-DB-F7 |E1 |
|00-13-A2-00-41-B6-23-B4 |Apr-E5 |
|00-13-A2-00-41-B4-F4-14 |Apr-F6 |
先记录183节点的0xA1情况 \\
183节点，测试时间2021-06-23中午 \\
时间：11:38:00~12:27:01 \\
时长：49分1秒=49*60+1=2941S \\
0xA1(AR_MTO)=16*183=2928 \\
测得0xA1=22493 \\
0xA1(非AR)=19565 \\
RRI per sencond= 6.65 \\
RRI per minute= 399 \\
13:14开始长时间抓包，以期查到退网事件，同时用xctu接入一块测试板，定时40秒发心跳包 \\
发现： \\
路由器发送端，有一定概率出现network ACK Failure ， 并且接收到的心跳响应也少，往往延迟较久。 \\
初步判断原因：\\
路由器发送成功，但ACK丢失，应该是network ACK Failure的主要原因之一。接收到的比实际发送的多，也大致是这个原因，即协调器认为收到并返加ACK，而路由器没收到ACK，application layer的retry被当成新包（这可能也是bug?建个Jira） \\
协调器的收优先级大于发，194个节点定时心跳和上报数据，有一定时间概率上同时发送节点数较多，造成协调器发的机率少，发的成功也少。协调器带宽堵上了，路由器上发的窗口也就少了，也容易不成功。
优化方向：
1. 应用分组分时法
因此如果能用RTC，把200个节点分成两组，前5秒1组，后5秒一组，上发数据严格按前5秒组1，后5秒组2来执行，减少碰撞的机率，应该可以改善通信时间。
2. 关掉ACK，减少大量的retry，由应用层retry来保障通信。
新测试目标: 减少心跳包频次的影响
190节点，40s/80s 间隔发数据时 RRI数据 \\
测试时间：2021-6-23 15:05:25~15:18:02 \\
总时长：12分57秒 = 777S \\
0xA1(AR_MTO)=4*190=760 \\
测得0xA1=6203 \\
0xA1(非AR）= 5443 \\
RRI per second = 7.0 \\
RRI per minute = 420 \\
190节点，60s/120s 间隔发数据时 RRI数据 \\
测试时间：2021-6-23 16:15:01~16:37:29 \\
总时长：22分28秒 = 1348S \\
0xA1(AR_MTO)=7*190=1330 \\
测得0xA1=6735 \\
0xA1(非AR）= 5405 \\
RRI per second = 4.0 \\
RRI per minute = 240 \\
测试目标：C8的影响 \\
2021-06-23 17:08 广播C810 并恢复40/80s的心路数据间隔 \\
网络变化： OP＝A57C6EE8BAF7A5FF CH=18 \\
一个晚上，离网14个，可见C8没有更好，但也不足以说明更差，因为数据样本和测试并不够，可以抓一次C810时的A1指标，如果没有更好，则用回C800
====2021-6-24====
2021-6-24 改用xcom抓包测试c810下A1 \\
测试时间：13：30：32~13：40：16 \\
时长：9分46秒=586S \\
0xA1(非AR_MTO)=3*190= 570 \\
测得A1: 4982 \\
0xA1（非AR）=4412 \\
RRI per second= 7.5 \\
RRI per minute= 451 \\
结论：C810效果略差 \\
2021-6-24 15：00 广播ATC800，把C8改加默认0 \\
数据分析： \\
coordinator端常见failure包，出现不多： \\
72 unknown: \\
该节点有数据的三分钟时间内2次 \\
发：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
delivery status: 72 (Unknown)
Address Not Found: \\
该节点有数据的三分钟时间内x次 \\
一般过8秒没收到ACK即为这错误, 有数据的那5分钟內只出现1次 \\
发：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)
结论：主动下行发数据似乎还行，出错概率小！
上行数据测试 \\
外接个模块，40秒定时发心跳包：\\
发送100个中，有54个Network ACK Failure \\
发送：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)
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====
192节点 测试重包情况 \\
测试模块手动发10个包，每个包带不同的序号作为payload，查看目标丢包和收到包的详细数据 \\
首先测ACK没禁用的默认情况： \\
有MTO时一般挺好的，当出现ACK Failure时有多收或丢包情况，此时一般没MTO，可能是路径有变化MTO没来有影响？\\
挑一段发送不成功的时间段记录如下，都是NetWork ACK Failure的错误，反馈包一般都是发送后5秒才有，虽然反馈包显示错误，但实际上有些协调器是成功收到的。\\
01包：发1个，收到2个。\\
发：[2021-06-28 14:37:58.354] \\
收：[2021-06-28 14:37:59.274][2021-06-28 14:38:02.274] \\
02包：发1收1，正常 \\
发：[2021-06-28 14:38:06.425] \\
收：[2021-06-28 14:38:10.837]\\
03包：发1收1，正常 \\
发：[2021-06-28 14:38:16:962] \\
收：[2021-06-28 14:38:21.149] \\
04包：发1收1正常 \\
发：[2021-06-28 14:38:28:099] \\
收：[2021-06-28 14:38:29.242] \\
05包：发1收1正常 \\
发：[2021-06-28 14:38:34.634] \\
收：[2021-06-28 14:38:36.144] \\
06包：发1收1正常 \\
发：[2021-06-28 14:38:40.746] \\
收：[2021-06-28 14:38:42.196] \\
07包：丢 \\
08包：丢 \\
09包：发1收1正常 \\
发：[2021-06-28 14:38:59.534] \\
收：[2021-06-28 14:39:03.680] \\
10包： 发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 \\
14：20改为41/80， 14：29记录15分钟 \\
测试时间：14:29:07~14:44:37, 共15分30秒 =930S \\
测得0xA1=5134 \\
0xA1(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 \\
0xA1(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 \\
0xA1(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上也是非常好的（和松一起观察，未记录）。
**抓包指标分析**
14：20改为41/80， 14：29记录15分钟 \\
测试时间：14:29:07~14:44:37, 共15分30秒 =930S \\
测得0xA1=5134 \\
0xA1(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 \\
0xA1(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 \\
0xA1(MTO_AR)=5*191=955 \\
实际0xA1=5556-955=4601 \\
RRI per second=4.73 \\
RRI per minute = 284 \\
可见，在有外部小干扰时，RRI指标仍减少，也就是网络拥堵不会进一步恶化，流控CTS事件不会发生。