TI中文支持网如题，使用CC2530芯片，ZStack-CC2530-2.5.1a协议栈。为了减少Zigbee终端和协调器间的时延，将Zigbee终端设置为一直接受消息，即在f8w.Config.cfg中设置了-DRFD_RCVC_ALWAYS_ON=TRUE，其他不修改。然后在终端和协调器通信过程中，终端总是间隔一段时间和协调器失联。通过抓包发现，终端发送数据包给协调器并且受到该数据包的ACK后突然发出orphan notification包（偶尔是beacon request）。通过查询，我猜想是终端的poll机制（感觉又有点像这个网址：https://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/85924.aspx下的zgChildAgingEnable），即协调器在终端入网的时候会将终端的相关信息（zgEndDeviceTimeoutValue）加入至AssociateList中，然后在timeout减至0的时候将该终端加入至notMyChild的list中，然后终端会发送orphan notification数据包。不知道我理解有没有问题。
问题：我想终端和协调器一直保持通信，要如何设置。谢谢
Susan Yang：
请问您现在为什么要终端和协调器一直保持通信？这样是和zigbee的初衷违背了呀
Cai Mo：
回复 Susan Yang:
Zigbee具有良好的低功耗和组网功能，但目前我需要使用的只是Zigbee强大的组网能力，为了能够满足数据传输的时延要求，我设置了-DRFD_RCVC_ALWAYS_ON=TRUE来满足从主控计算机-Coordinator-EndDevice之间的通信在300ms之内。
对于原问题，我通过实验发现我的描述不准确，我发现在主控计算机不停的通过串口发心跳包给Coordinator，Coordinator再通过无线转发心跳数据包给EndDevice，然后EndDevice通过无线发心跳回复包给Coordinator，Coordinator再将该数据包通过串口发送给主控计算机。在该情况下，如果EndDevice再开启定时器不停的给Coordinator发ADC数据采集包，Coordinator再通过串口发送ADC数据采集包给主控计算机，那么就会频繁的出现orphan notification或者beacon，然后EndDevice再以孤儿的形式重新入网。
（该情况下，
Coordinator作用：
1.通过串口接受主控计算机发来的心跳包，并将该心跳包通过广播发送给EndDevice；
2.接受EndDevice的心跳回复包，并将该心跳回复包串口转发给主控计算机；
3.接受EndDevice的ADC数据采集宝，并将该ADC数据采集包通过串口转发给主控计算机。
EndDevice作用：
1.接受Coordinator发来的心跳数据包，并回复心跳回复包给Coordinator；
2.通过定时器，每几秒发送一次ADC采集数据包给Coordinator。
）
但如果心跳包是Coordinator中通过定时器不停的发给EndDevice的哈，那么即便EndDevice开启定时器不停的给Coordinator发ADC数据采集包，Coordinator再通过串口发送ADC数据采集包给主控计算机。如果是这个情况，那么网络状态比较稳定。
（
该情况下，
Coordinator作用：
1.开启定时器，每5s广播一个心跳包给所有EndDevice；
2.接受EndDevice的心跳回复包，并将该心跳回复包串口转发给主控计算机；
3.接受EndDevice的ADC数据采集宝，并将该ADC数据采集包通过串口转发给主控计算机。
EndDevice作用：
1.接受Coordinator发来的心跳数据包，并回复心跳回复包给Coordinator；
2.通过定时器，每几秒发送一次ADC采集数据包给Coordinator。
）
所以，是因为主控计算机和Coordinator频繁的串口通信导致的终端频繁成孤儿节点么？如果不是，那么为什么会出现第一种的情况
