一个不严谨的zigbee数据丢失测试

注：本文基于笔者手中的一些CC2530模块测试，不具备普适性。
测试CC2530使用ZSTACK协议栈时，数据丢失的情况。
　　1 cc2530 采用zstack实际能够支持的最大节点数
如果2530作协调器,组一个网状网络.100个节点左右问题不大.如果用2538做协调器,据TI的说法400个.他们有一个测试环境是400个。
http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/73139.aspx
个人测试：
陆续上电，超过25个之后，新的节点上电困难。
全部一块上电，20个之后，有的节点在几分钟之内都无法加入网络。偶尔出现协调器卡死。

　　2 协调器接收数据的能力
15个节点一起向协调器发数据，其中14个每隔10s一起发数据给协调器（一个16字节的数组，放在APSpayload）,1个每隔100ms发一个数据给协调器。协调器通过串口把收到的数据发送给串口助手显示。
协调器正常工作，不阻塞，串口助手数据更新迅速。未测丢包，目测多数接收到。

　　3 协调器收发同时
在2的基础上，让协调器每隔1s发送命令给一个节点，节点收到数据之后，更新LED的状态，把收到的数据发到另一个串口助手。
2次测试，100个命令中平均只有67个被执行。
注，没有被执行的命令不代表没有收到。可能收到之后节点没执行。

　　4 协调器只发命令
在3的基础上，去掉给协调器发数据的节点，只保留接收命令的节点。协调器仍然每隔1s发送命令给一个节点，节点收到数据之后，更新LED的状态，把收到的数据发到另一个串口助手。
2次测试，100个命令中平均只有71个被执行。
非常悲观，看来即便协调器不接收命令，跟节点1V1地1s间隔发命令，也有大约三分之一的命令没被执行。

　　5 在4的基础上，间隔改为5s。
1次测试，100个命令中99被执行。
5s的发送间隔看来问题不大。但也不是百分之百。

　　6 在2的基础上，把协调器发送命令间隔改为5s
1次测试，100个命令中97被执行。但是个别命令执行顺序颠倒。

　　7 6的基础上，改为2s间隔
1次测试，290个命，13个没有被执行。多处命令顺序颠倒。

　　综上，CC2530进行节点数据采集时，系统工作的比较稳定，不会轻易阻塞或崩溃，但可能不适宜不允许丢数据的高要求采集。
　　以较高的频次发送命令时，可能会存在严重的数据丢失，建议节点将执行命令之后的响应反馈给协调器。
　　测试不严谨，加上我是初学者，也不太懂得优化，见谅。