Z-stack中，协调器/路由器向节点发出“空包”的现象。

http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/78037.aspx

这个帖子中，关于VV问作者，为什么协调器发给节点的数据“看不到”内容。

我以前也遇到过，我认为是“空包”现象。

导致这个现象的，应该是TI-MAC层协议的问题。

协调器发送给节点，最终是采用的Indirect发送模式，即节点向协调器发起一个Data Request，协调器再发数据给节点。

在TI-MAC中，两种数据是Indirect发送：1，MAC_McpsDataReq采用MAC_TXOPTION_INDIRECT的方式发送；2，MAC_MlmeAssociateRsp发送协调器分配给路由/节点短地址的时候。

Indirect发送的时候，依赖发(xie)送(tiao)者(qi)的TX缓存，当一个协调器连续向多个节点发送数据时，必然会造成缓存不足。比如连续多次调用MAC_McpsDataReq和MAC_MlmeAssociateRsp函数，协议栈内部就会连续申请缓存空间，但是没有收到MAC Data Request的时候，已经申请的空间不会释放，后申请的，也无法分配到空间，但是协议栈会分配一个“空包”。

至于为什么会有“空包”，个人认为是和ACK的PEND标志有关。ACK里面的PEND标志，只有在收到MAC Data Request的时候才会用到。因为在触发MAC_McpsDataReq和MAC_MlmeAssociateRsp函数，就已经打开了ACK的PEND标志，在收到MAC Data Request，回复的ACK里面就带有PEND标志。然后MAC Data Request的发起者在收到带有PEND标志的ACK后，不会立即休眠，需要收到一个数据包后才会休眠，否则一直打开RXON，对于节点来说，这样的电能损失非常高。因此协调器会发一个“空包”给节点。这个“空包”的意思就是“老子没有空间给你发数据了，洗洗睡吧”

看原帖了，觉得应该是节点处理机制改改。节点和协调器之间数据可以先定时让节点发送数据给协调器 自己可以接收数据了。

广播方式还是少用为好。

我也玩过一段时间的zigbee，对于终端，我用的是固定的地址，一旦接入过主机，主机就把固定的地址分配完毕，并且写入flash，不再重新改，另外在发送的时候，一般就写分配过的地址，不再广播，这样的话，可以避免很多广播容易出现的问题

我暂时也不知道怎么玩，先试试

Aries,

为什么说需要收到一个数据包以后才会休眠，在发送data request以后，到休眠是有一定的时间控制的。并不是因为需要有数据包而一直等待的。

发送这个空白的报文目的，目的是为了让节点能够尽快关闭rx，进入休眠。

所以的理解基本正确。但是这个问题的出现，并不是因为buffer满了，没办法分配引起，

举个例子，父设备要给所有的子设备广播发送数据，所以会在mac Ack里面把这个pending bit设置1，如果child设备收到这个广播数据了，父设备会理解发送这个空包让子设备尽快的关闭Rx进入休眠。

这个问题有点复杂，我也遇到了，正在研究中

看原提问的意思是发送数据过快 就会导致节点没有数据包。应该是软件mac协议层的协调性问题。还有一个问题，就是会不会信号的不稳定性导致的。

没接触过，来学习的！

看原提问的意思是发送数据过快 就会导致节点没有数据包。应该是软件mac协议层的协调性问题。还有一个问题，就是会不会信号的不稳定性导致的。

有点小高深，来学习

我以前调试过无线节点也出现过类似情况；我是这样处理，没有收到节点应答时，协调器重新发送指令。