TI中文支持网你好:
請問若源設備在重傳超時時間到期後仍未收到目標設備發來的端到端確認，將進行資料重傳。
資料重傳次數和重傳超時時間可由APSC_MAX_FRAME_RETRIES和APSC_ACK_WAIT_DURATION_POLLED控制
我想知道控制資料回傳的function 而非上述的參數，因為都找不到
Kanjie Zhu：
你说的控制回传的function是指接受端发送APS_ACK的函数么？
XXXXX XXXX：
回复 Kanjie Zhu:
不是耶~ 我想知道 因為傳送端沒收到接收端的ACK傳送端再次資料重傳的 function 我想知道資料重傳時，資料先暫存在哪一個function控制 ?
Kanjie Zhu：
回复 XXXXX XXXX:
这部分是不开放的，协议栈会自己完成。
XXXXX XXXX：
回复 Kanjie Zhu:
請問如果要做這部分應該如何做?可以提供意見嗎?
謝謝
Kanjie Zhu：
回复 XXXXX XXXX:
可以在添加对AF_DATA_CONFIRM事件的处理，如果其中的status不是SUCC，说明发送或重传失败了，这时你可以在应用层对其再次重传。
XXXXX XXXX：
回复 Kanjie Zhu:
我用SerialApp做測試你說的添加对AF_DATA_CONFIRM事件的处理，如果其中的status不是SUCC，说明发送或重传失败了
我已嘗試過了 好像達到不到預期的效果例如: 我傳送100筆資料和 設定沒回ACK需要重傳的Buffer [100筆] ，有30筆資料需要重新傳送但是不知道甚麼原因，只能重新傳送10筆資料請問你知道原因和如何解決達到需要重傳的資料都重送成功嗎?
Kanjie Zhu：
回复 XXXXX XXXX:
可以尝试线性的发送。
发送数据–>在confirm中判断，succ继续发下一条，否则重发。1个buffer就够了。
XXXXX XXXX：
回复 Kanjie Zhu:
我想做到連續丟100筆資料 然後有需要重傳的部分先儲存在buffer，等全部都傳完後再來處理重傳的部分請問有辦法嗎?
Kanjie Zhu：
回复 XXXXX XXXX:
可以啊，但不是没回ACK的存入buffer，而是confirm中status不是SUCC的存入buffer。
如下Zigbee的数据发送机制决定了你连续丢100个数据包下去是不合理的：
1. AF_DATA_REQUEST调用完成后数据并不是就已经发出去了，只是发到了mac层，需要等待底层调度后发出。
2. APS层同时能缓存的数据数量也是有限的。同时是指发出一个包在接收方ACK回来前，这个包都会被APS层缓存。如果没收到还会有APS的重发，默认3次。再失败才会通过confirm告诉应用层。
3. 通过2知道，发送一个数据包到回来confirm的时间挺长，这时APS的数据缓冲早就满了，你的AF_DATA_REQUEST会返回fail，所以不是所有的包都扔下去了。不知道你有没有检测AF_DATA_REQUEST返回值的状态。
XXXXX XXXX：
回复 Kanjie Zhu:
我是從PC透過RS232丟100筆資料到串口請問這不合理嗎?我的檢測是成功的狀態由於我是 confirm中status不是SUCC的存入buffer 然後過一段時間再重新傳送不過就像剛剛所說的buffer只留存最後幾筆資料 前面的資料被清掉了
