TI中文支持网协议栈：MESH1.0
网络：1COO（CC2530），1EN（CC2530）信号查询ACK延迟返回.rar
问题描述：EN发送指令后，COO回复后，很久都没有的到EN的ACK。
附件里从P7开始为该过程。从COO回复到得到ACK竟然要近1s的时间。
所以想请问一下，EN程序哪里可能会导致ACK延迟。EN的休眠已经关闭了，该情况还是会发生。
YiKai Chen：
你的終端設備polling rate是1秒，回應的時間就是要1s
user5032796：
回复 YiKai Chen:
下面的附件是原程序带休眠模式的，3s poll一次，唤醒查询后还是能快速返回。我是在该程序上进行修改的，后面就有问题了。所以不确定是影响到了哪里。
ack应答正常.rar
YiKai Chen：
回复 user5032796:
你可以用你的sniffer log解釋一下那部份是你指的"唤醒查询后还是能快速返回"?
user5032796：
回复 YiKai Chen:
好的。
P8为终端发送的查询指令
P10为协调器回复的消息。100ms后就收到了P12 ACK。
P13也是协调器回复的消息。
或者您可以使用该秘钥“48:77:01:59:33:01:56:36:81:69:03:03:54:11:67:21”进行查看
YiKai Chen：
回复 user5032796:
信号查询ACK延迟返回.rar裡面終端在P11就回應了，但是協調器沒有mac ack才導致終端做了mac retry，所以延遲，這應該要查協調器為什麼沒有mac ack
user5032796：
回复 YiKai Chen:
我这边上传不了截图，但是在“信号查询ACK延迟返回.rar”中，P11是协调器回复给终端的消息包吧。没有收到ACK后，P12到P14连续回复了3个。隔了1s后，在P17又回复了一次，就能正常收到了ACK了。
还有请问一下mac retry是怎么看的。
YiKai Chen：
回复 user5032796:
mac seq都一樣
user5032796：
回复 YiKai Chen:
嗯嗯，谢谢。我再往协调器看看哪里有问题。
Alvin Chen：
回复 user5032796:
你这个终端是低功耗设备，所以通常是由poll rate 决定了回复的快慢，建议你加上AF_ACK_REQUEST，去确认。也有可能是你改出问题了，你可以用sdk里面的GenericApp去试试。
