休眠相关参数解读

  1. SP: 睡眠时间
  2. ST:最长醒来时间
  3. SN:扩展休眠时间周期

发送相关:

对于发送方来说,发送请求最多也就是尝试完单播超时或扩展超时后,如果还没收到ACK,发送请求会当超时处理完毕。

网络相关: 父节点清理子节点列表时间:ET 子节点主动换父节点:下次醒时polling 三次没成功

XBee Zigbee休眠终端何时会主动离网寻找新的父节点

XBee休眠节点寻找父节点的时机是:下一个醒来时间的三次polling不成功,就会离网更换父节点。

如何让休眠终端快速更换父节点

只需让休眠终端的NJ<FF,它就可以使得休眠终端在父节点不可达时快速切换父节点,这种模式叫rejoin,休眠终端并不退网,短地址并不会变更,如果休眠终端的NJ=FF,则它会主动离网并寻找新的可加入网络。

为何在xctu上,给休眠节点发多个数据包,即使给休眠节点断电超SP+ST时间,它醒来也只丢一包?

注意,在发送端,只有发出一包,其余的在堵塞状态并没有发出,默认地父节点只给子节点缓存一包数据,这包数据没取走,或是pulling timout之前,发给同一节点的并没有真正开始发送。

协调器和休眠节点的通信需要注意什么?

发送给同一个休眠节点的数据,在unicast timeout之前,不应该再尝试发送,以避免造成模块处于阻塞状态。当发生阻塞时,模块等待阻塞解除,即休眠节点醒来时,多个给它的包被接收,在这些发送包之后的AT指令或其它模块的数据发送请求才会被处理。unicast timeout和NH设置有关,默认值为4.8秒。如果你程序希望改小这个值,在小规模网络也是可以的,通常这个默认值足以支持8跳的数据传输。

我可以根据反馈包来判断数据是否被接收端收取么

对于数据量小,跳点少,没有休眠的网络,反馈包是有一定意义的,但数量量大或是涉及到休眠节点时,你不能以反馈包是否success来判断数据是否发送成功,一来是因为它的timeout时间只是估算的值,发给休眠节点的反馈包很可能返回的是address not found,因为目标地址是挂在父节点下的子节点,休眠时间较长时,unicast timeout就会返回该值,但只要父节点休眠时间涵盖或匹配子节点,在下次子节点醒来时仍收得到数据。即使是节点少,数据密集传输时,反馈包也可能丢包,因此,不能用反馈包作为数据被接收与否的确切标志。

1)
50 * NH) + (1.2 * SP