接着上回继续分析公司遗留的问题二分析，问题二就是入网速度慢、入网后概率性的掉线。先普及一下我们入网的流程，因为不同的网络有不同的PANID，因此目前入网的方式有三种：1、每个设备出厂时候读取它的MAC地址，生成二维码贴在设备上，入网之前用手机扫描一下，把MAC地址导入到网关端，因此尝试关联的时候网络允许其关联；2、每个设备上做一个NFC标签，设备可以通过I2C等总线读取NFC标签，网关端有一个NFC读写器，把设备靠近网关，嘀一下，网关把PANID同步到NFC标签上，每个设备都会关联该PANID的网络；3、网关端有个标志位，一旦允许加入的时候，所有关联该网关的设备都允许被加入，一旦标志位清零，任何设备都加入不进来。以上三种方法各有各的优势，最后一种方法是成本最低的，但我们偏偏就是最后一种方法。(上面两种判断是否授权可以入网的方法，在ZDO_JoinIndicationCB函数中，如果没有授权的设备入网的话，强行让其关联失败AssocRemove(xxx))
我照样按照自己的节奏，先通过抓包分析，然后再决定采取什么样的策略(就跟古代打仗一样，先派一小队人马试探一下，再进行阵列、战术的调整)，通过抓包发现，关联时候一直在发beacon request，而没有associate关联，当然有4、5个网关同时开着的时候，网关开的越多，关联越慢。
有了一定的规律就通过打印以及抓包分析(个人认为，打印还是最直接有效的定位手段，抓包、仿真、抓波形都是辅助手段)，发现到一点，以前关联设备都是先NLME_NetworkDiscoveryRequest，收到beacon帧回应后，在ZDO_NetworkDiscoveryConfirmCB里面，判断哪些网络可以加入(全局变量NwkDescList的链表里就是所有网关回应beacon帧的消息信息)，问题就在这里，之前公司的代码是每次先连接NwkDescList链表里第一个网关，如果失败，就接着下一个连接，但是连接成功判断条件却是NLME_JoinRequest函数的返回值，因为这个操作是异步的，也就是这个函数结果基本上一直都是0，就会导致，每次扫描后，总是连接第一个返回beacon帧的网关，导致概率性的绑定不上，以及绑定慢，网关越多，绑定的越慢，绑定不上的概率越大。
后来通过修改，每次绑定的时候，网关端拒绝后(ZDO_JoinConfirmCB函数里的结果值是2，具体原因请看802.15协议)，把该网关暂时拉入黑名单，下次收到beacon帧请求不加入，直接next，之前想尝试每次收到所有的beacon帧的网关信息，加入一个数组，associate拒绝后，在associate下一个，但是CC2530有个BUG，你不能直接associate，必须先beacon request，收到beacon帧后再associate就可以，估计里面状态只能这样，都封装成库了，但是修改后，绑定速度快多了，如果在4个网关以下，一般10秒内绑定上，5个网关以上，一般也要20-40秒可以绑定上，代码如下，
详细具体代码就不一一展示了，本次主要分享定位的思路和先后顺序，而不是解读代码，下一讲，分享解决长期运行掉线不能自恢复的隐性BUG。