ZigBee解决父节点向休眠终端发送数据的接收时延问题

这篇是承接上次的文章。

前面ZigBee父节点以发送指令的方式修改终端的休眠时长中遗留的问题:

之前是这样配置的:
ZigBee解决父节点向休眠终端发送数据的接收时延问题
1、只是关闭了终端在休眠过程中的Data Request的周期性发送;
2、保留了终端节点在发送给协调器数据并接收到数据确认帧之后立即发送Data Request数据请求。
但是这样配置会有一个问题:
       终端节点以timer1的休眠时长进行休眠,唤醒后向父节点发送数据,收到父节点的数据确认帧之后,再发送Data Request数据请求,父节点在发送给终端指令,直到终端接收到这个指令之间,
实际上是有timer1这样一个时间间隔,如果终端的休眠时长很长的话,那么这个时效性就很差了。

方案:
        在一次次的实验过程中,抓包分析时,发现在终端上传数据并接受到数据确认帧之后,立即发送的Data Request是在协调器发送指令之前,所以终端不能依靠这个data  Request立刻接收到协调器发送的指令,只能等待下一次唤醒之后执行完任任之后再次发送Data Request去接收协调器的指令。这样就产生了一个周期的时延。
解决方案就是保证终端在执行完任务之后,不能立即发送Data Request,而是要等到协调器发送指令之后再发送data Request去请求数据。而等待的这个时长必须要远远小于timer1,否则时效性还是不强。


在进行具体的代码改动之前,我在网上找到了有关配置文件里最常用的POLL_RATE、QUEUED_POLL_RATE、RESPONSE_POLL_RATE这三个参数的解释,了解这个之后更便于我们做进一步的代码修改:

Data Request Polling(数据请求巡检)
周期性的向父节点发送数据请求信息。间隔的时间值可以通过改变这个PollRate来设定和存储,或者调用NLME_SetPollRate()函数,该函数的调用会立马开始巡检,即便是之前被禁止了

Queued Data Polling(数据接收巡检)
在接收到有数据将要传来的信号后,周期性的向父节点发送数据请求信息。间隔的时间值可以通过调用NLME_SetQueuedPollRate()函数改变,或者改变zgQueuedPollRate来设定和存储。这种特点允许快速地接收(卸载)数据,而不用考虑Request Poll Rate。

Response Data Polling(数据相应巡检)接收到数据确认后,周期性的向父节点请求响应信息。间隔的时间值可以通过调用NLME_SetResponseRate()函数改变,或者改变这个ResponsePollRate来设定和存储。这种特点允许快速的接收(卸载)相应信息,而不用考虑zgResponsePollRate。

具体实施:
1、关闭所有Zstack协议栈自带的Data Request的请求,即如下设置:
ZigBee解决父节点向休眠终端发送数据的接收时延问题
另外,NWK_AUTO_POLL得使能
ZigBee解决父节点向休眠终端发送数据的接收时延问题
2、自己定义一个事件,这个事件在每次终端发送数据之后响应。
如图,Start_Poll即为远远小于Sleep_Time的时延。比如在代码中,我是Sleep_Time=10分钟,Start_Poll=100ms。
这个自定义的事件处理中,仅仅发送一次Data Request请求,并不发送数据,使用NLME_SetPollRate(1)函数来完成,另外,这个参数的话,测试过后貌似就1会发送一次Data Request,填写其他值得话,会发送很多的Data Request。但是一次就够了,足以接收到数据了。
ZigBee解决父节点向休眠终端发送数据的接收时延问题
经过这样设置后,基本上就可以实现终端能在可以理解的时间内接收到协调器发送的指令了。