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,对于节点来说,这样的电能损失非常高。因此协调器会发一个“空包”给节点。这个“空包”的意思就是“老子没有空间给你发数据了,洗洗睡吧”
user4187796:
看原帖了,觉得应该是节点处理机制改改。节点和协调器之间数据可以先定时让节点发送数据给协调器 自己可以接收数据了。
广播方式还是少用为好。
user4441475:
我也玩过一段时间的zigbee,对于终端,我用的是固定的地址,一旦接入过主机,主机就把固定的地址分配完毕,并且写入flash,不再重新改,另外在发送的时候,一般就写分配过的地址,不再广播,这样的话,可以避免很多广播容易出现的问题
HAIQUAN LIU:
我暂时也不知道怎么玩,先试试
VV:
Aries,
为什么说需要收到一个数据包以后才会休眠,在发送data request以后,到休眠是有一定的时间控制的。并不是因为需要有数据包而一直等待的。
发送这个空白的报文目的,目的是为了让节点能够尽快关闭rx,进入休眠。
所以的理解基本正确。但是这个问题的出现,并不是因为buffer满了,没办法分配引起,
举个例子,父设备要给所有的子设备广播发送数据,所以会在mac Ack里面把这个pending bit设置1,如果child设备收到这个广播数据了,父设备会理解发送这个空包让子设备尽快的关闭Rx进入休眠。
yefeng ye:
这个问题有点复杂,我也遇到了,正在研究中
user2000895:
看原提问的意思是发送数据过快 就会导致节点没有数据包。应该是软件mac协议层的协调性问题。还有一个问题,就是会不会信号的不稳定性导致的。
jiaozi tianzhi:
没接触过,来学习的!!
zhoushichuang zhou:
看原提问的意思是发送数据过快 就会导致节点没有数据包。应该是软件mac协议层的协调性问题。还有一个问题,就是会不会信号的不稳定性导致的。
first_name last_name10:
有点小高深,来学习
user4015270:
我以前调试过无线节点也出现过类似情况;我是这样处理,没有收到节点应答时,协调器重新发送指令。