Zigbee疑难问题定位以及思路方法分享 (一)

        最近换了家新公司,花了两个月从不懂ZigBee到解决了不少遗留偶发BUG,有了不少心得体会,下面分享下自己定位思路,以及分析问题的方法。

        刚进公司,接手了另一个工程师做的ZigBee项目(采用CC2530方案),遗留不少问题BUG,前两周看代码,熟悉ZigBee协议,当前遗留了有不少BUG,其中丢包率高、经常性的掉线并且不能自恢复、入网速度慢、入网后概率性的掉线这几个问题最为急切解决,我选择了一个相对简单解决的问题入手----丢包率高。

        首先大概分析了一下,丢包率高有几个可能性的问题:1、外界干扰;2、防冲突机制以及CCA阈值;3、软件BUG。

        其中1是没办法的,只能通过修改信道,错开WIFI干扰区间,如下图

由以前的18、25、26信道,改为11、15、20、26信道,大致测试了一下,相对稍微改善一下,但依旧没有得到质的提升。

        采取2方法,因为CC2530防冲突机制底层封装成库了,无法进行改善,既然底层无法改善,那就修改参数,于是乎,修改了CCACTRL0寄存器里的CCA_THR寄存器,经过反复尝试,选择到一个最佳的值(详细步骤就不说了),但是依旧没有得到预期效果。

       采取3方法,怀疑程序有BUG,但是看代码没有问题,因此根据之前经验,有线的有问题就抓波形,无线有问题就抓包,开始认真研读802.15协议以及ZigBee协议,通过抓包分析,后来突发奇想,既然发送数据错误,就看看错误原因,于是在

在AF_DataRequest函数返回值进行仿真,查看ret的结果值,无意间尝试,把协调器断电,设备发数据,理论上应该得到错误值,但是这个值确是0,我怀疑数据有没有发出去,通过抓包,发现

一直在发数据,没有收到ACK,才知道,判断发送是否成功的地点出错,程序BUG,通过调试,发现在

这里面才是有无收到ACK状态返回,断开网关,返回值在0xe9,信道繁忙,返回值是0xe1,定义在zcomdef.h定义,通过修改,解决了丢包率高的一系列问题,当然还有关联时间过长等问题,稍后分享

猜你喜欢

转载自blog.csdn.net/moonlinux20704/article/details/94751057