无线模块收发死掉 模块, 无线, 收发

GBA_WE

大家有没有碰到过无线模块不停的收发，过一段时间后会出现无线模块会发送失败或者是接收不到的现象。我用的是Z－Stack的serial重新改写收发程序，现在用coord像router发数据，router没收到一个数据就会再回一个数据给coord。一般情况下，发了10－20万个字节后，会出现coord发送失败，而router接受不到数据，有时有可能是coord死掉，有时是router死掉，只要复位其中一个就会正常收发。我用调试跟踪过，程序本身并没有死，还是在执行。估计是应用层程序影响到无线层这块了。大家有没有什么解决方法啊！

jimmytan

这个可能是由于内存溢出造成的。我建议你可以在应用层，把发送数据的间隔加长一点，最好是让间隔在50ms以上。你在应用层的程序需要优化一下。

GBA_WE

现在我串口发数据的间隔是1s，但是发送一段时间就会死掉。我是一次发57个字节的，是不是与应用层全局变量设的太多有关啊？

jimmytan

你现在coordinator到router是点对点发的不？我觉的这种情况应该是底层的BUFFER数据处理不过来，数据发射出去，还到等ACK回来，确认对方有没有收到，如果没有收到，还会重发，这其中会有一个延时。因为你现在发射的数据包是57个字节，是比较长的。我记得在Z-stack的应该层最多也只能一个包里80个字节左右。所以，我建议你可以做一下试验，把间隔时间改到2s,3s,或着更长一点。这样可以让底层有更充裕的时间来处理数据的发射和接收。

GBA_WE

对，现在是coord到router点对点的。串口驱动这里已经限制了最多是77个字节进来。每发一个包，我都等ACK回来的，ACK成功在打开串口，从串口取数据的来发的，否则不取的。时间间隔长短好像没什么作用，都是发一段时间就会死掉的。

jimmytan

你发数据时占用的内存有没有及时的释放出来呢？会不会是你的变量太多，内存不够造成的。

GBA_WE

应该都及时释放内存的。变量也已经减掉很多了。可还是会在发了10－20万个字节时死掉。还有想问一下，信标模式和非信标模式有什么区别啊？就是有什么不同的现象？多谢了。

jimmytan

你指的应该是beacon模式和non-beacon模式吧。在802.15.4 MAC中，是两种模式都支持的。但在现在的Zigbee 1.0中是不支持beacon模式的。beacon主要是用来省电的，就是由coordinator每隔一段时间发射一信标，然后所有的device都会定时醒来去接收这个信标，其他时间可以睡觉。你现在用的应该是非信标模式吧。关于死机现象，你现在用了省电模式吗？我想确认一下你有没有用网上下载的PRWLIB.

GBA_WE

哦，是这样啊，我没有用信标模式，无线板子是程序是一直在执行的，也没用过PRWLIB。像这样的死机现象，有没有通过软件来控制MC13192这个射频芯片复位的方法啊？我想如果经常这样死机的话，只有定时复位无线收发的芯片了！

jimmytan

如果你要用reset的话，可以采用MCU的watchdog功能啊。在软件上可以做的。具体的设置可以参照GT60 Reference Manual.

GBA_WE

我现在按原来的最初的程序，发净荷77个字节，发到22万个字节时，一直发送失败，于是我就等了2分钟，然后再发，竟然又通了。这样发到55万字节，64万字节，90万字节都出现过这个现象。但是都没有按过复位，说明程序工作都正常的，那为什么会要等一段时间才会发通呢？真是奇怪。

seuafu2005

你的发送间隔是多少时间？ 是coord向router发？
coord到router是indirect方式，本身的传送时间比较久，发送间隔建议在3秒以上。zigbee本身是low duty cycle的协议，太快了并不好。
另外，我猜测是这样，第一次发送失败以后，mac层有三次重发的过程，所以你后面紧跟着的发送会失败，因为底层还在重发前面的数据，后面的自然被丢弃，或者被堵住。等过了一段时间，底层的重发结束了，那么有可以开始正常发送了。

GBA_WE

现在是coord向router发送数据，通过短地址直接发的，77个字节每1.2秒。如果发送失败，会从串口返回一个值，当发到22万字节的时候就不停的发送失败，然后我就暂停不发了。要等2到5分钟左右的时间，再发，又发送成功了。如果mac层有重发的话，我怎么可以知道它重发成功，或者已经重发了3次失败了呢，这样我应用层就可以控制了。

seuafu2005

重发的过程好像你没法知晓，只能有一定时间的等待。
我还是建议你发送间隔延长。因为在非beacon模式下，z-stack默认的router poll的时间是1秒，实际coord发送给router有个来回的过程，所以1.2秒的间隔太小。数据发送少可能看不出，时间久了肯定会有问题。
你试试延长一点。如果还是有这个问题，也不排除z-stack的bug。

GBA_WE

感谢大家的解答！“z-stack默认的router poll的时间是1秒”哪里可以看出来。我现在的处理就是要等收到ACK成功后，在打开串口取数据的MT_SerialFlowControl( ZAPP_PORT, APP_FLOW_ON ); 失败的话要等3秒才打开，如果buffer里数据溢出就清掉的。所以我觉得发数据的间隔应该差不的了。