不明数据，拜托帮分析一下（附抓包数据）
各位大侠：
拜托大家帮忙分析一下什么原因啊，
协议栈：zstack 2.5.1a
网络：一个协调器，一个路由结点
问题：每当路由结点上传数据后，协调器就发送一包数据给路由，貌似路由没给回，协调器就连续发送。
协调器发送数据的NWK payload为：02 02 02 00 04 01 02 9C
1374.log20150302.psd
这个数据是APS的ACK帧，你在调用Af_DataRequest的时候，加了AF_ACK_REQUEST
Hi VV:
感谢答复，不过还有问题，
1、为什么这个数据每次都连续发送这么多次？是信号质量不好，重复发送了吗？
我用的协调器有PA，路由器没有PA，并且两个放在一起，距离10cm左右，不应该
有信号不好的情况啊。
2、AF_ACK_REQUEST可不可以去掉，去掉的话会有什么影响啊？
AF_ACK_REQUEST是开启APS层的ACK，没有多大意义，可以不要
AF_ACK_REQUEST开启和关闭会有什么影响或区别啊？
1，带有没有PA的情况下，不要把两个设备放的太近，有可能会造成接收机饱和
2，关于APS ACK和MAC ACK是两种不同的ACK，有不同的特点，你可以参考Z-Stack Developer Guide.pdf第八节
For non-broadcast messages, there are basically 2 types of message retry: end-to-end acknowledgement (APS
ACK) and single-hop acknowledgement (MAC ACK). MAC ACKs are always on by default and are usually
sufficient to guarantee a high degree of reliability in the network. To provide additional reliability, as well as to
enable the sending device get confirmation that a packet has been delivered to its destination, APS
acknowledgements may be used.
APS acknowledgement is done at the APS layer and is an acknowledgement system from the destination device to
the source device. The sending device will hold the message until the destination device sends an APS ACK
message indicating that it received the message. This feature can be enabled/disabled for each message sent with the
options field of the call to AF_DataRequest(). The options field is a bit map of options, so OR in
AF_ACK_REQUEST to enable APS ACK for the message that you are sending. The number of time s that the
message is retried (if APS ACK message isn’t received) and the timeout between retries are configuration items in
f8wConfig.cfg. APSC_MAX_FRAME_RETRIES is the number of retries the APS layer will send the
message if it doesn’t receive an APS ACK before giving up. APSC_ACK_WAIT_DURATION_POLLED is the time
between retries.
Hi VV：
感谢答复。
关于您提到的接收机饱和问题，我有几点疑问啊，我们现在产品部分带PA（2591），
部分不带PA，混合使用，
1、如果太近，不带PA的产品接受带PA产品的强信号会不会导致饱和啊？
2、带PA（2591）的产品，是不是由于2591的限制始终不会有接收机饱和的现象？
3、接受多少dbm会出现饱和情况？