CC2530-資料重傳
你好:
請問若源設備在重傳超時時間到期後仍未收到目標設備發來的端到端確認，將進行資料重傳。
資料重傳次數和重傳超時時間可由APSC_MAX_FRAME_RETRIES和APSC_ACK_WAIT_DURATION_POLLED控制
我想知道控制資料回傳的function 而非上述的參數，因為都找不到
你说的控制回传的function是指接受端发送APS_ACK的函数么？
不是耶~
我想知道 因為傳送端沒收到接收端的ACK
傳送端再次資料重傳的 function
我想知道資料重傳時，資料先暫存在哪一個function控制 ?
这部分是不开放的，协议栈会自己完成。
請問如果要做這部分應該如何做?
可以提供意見嗎?
謝謝
可以在添加对AF_DATA_CONFIRM事件的处理，如果其中的status不是SUCC，说明发送或重传失败了，这时你可以在应用层对其再次重传。
我用SerialApp做測試
你說的添加对AF_DATA_CONFIRM事件的处理，如果其中的status不是SUCC，说明发送或重传失败了
我已嘗試過了 好像達到不到預期的效果
例如: 我傳送100筆資料和 設定沒回ACK需要重傳的Buffer [100筆] ，有30筆資料需要重新傳送但是不知道甚麼原因，只能重新傳送10筆資料
請問你知道原因和如何解決達到需要重傳的資料都重送成功嗎?
可以尝试线性的发送。
发送数据-->在confirm中判断，succ继续发下一条，否则重发。1个buffer就够了。
我想做到連續丟100筆資料 然後有需要重傳的部分先儲存在buffer，等全部都傳完後再來處理重傳的部分
請問有辦法嗎?
可以啊，但不是没回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返回值的状态。
我是從PC透過RS232丟100筆資料到串口
請問這不合理嗎?
我的檢測是成功的狀態
由於我是 confirm中status不是SUCC的存入buffer 然後過一段時間再重新傳送
不過就像剛剛所說的buffer只留存最後幾筆資料 前面的資料被清掉了
另外，由於 发送一个数据包到回来confirm的时间挺长，
我能夠從afDataConfirm_t -> transID 中判斷目前是第幾個数据包嗎?
然後從confirm中status不是SUCC的数据包開始重新傳送??
謝謝
如果你不使用APS的ACK这样是合理的，如果你使用了APS的ACK，这样不合理，建议发10包左右集中处理confirm，或者每包之间有一定的delay。
可以从transID中判断，但一般transID是应用层发的所有包都会累加，你在发送时最好做好transID的处理与存储。
你說不使用APS的ACK这樣是合理的，不是使用APS的ACK來判斷confirm中status不是SUCC的存入buffer 比較合理嗎?
為什麼??
我是指的对于连续从PC扔100包的情况下：
1. 如果这么连续的发包，不使用APS的ACK才能做到。
2. 使用APS的ACK肯定会有包发不出去而丢失，这是Zigbee的机制决定的。
回过来对于你们的应用，那么必须通过APS的ACK来实现判断发送成功与否的，所以这种情况下就不能从PC串口这么不加控制的往下连续发100包，可以包与包之间加delay或每10包一个停顿这样类似的方式。
我在PC从C# 對串口做每一个40 byte 停顿 50ms，然後做在confirm中判斷，succ繼續發下一條，否則重發
然後confirm中status不是SUCC的存入buffer，發現只能儲存到40byte
我buffer的大小設定蠻大的，應該不是存不下的問題
請問有可能串口收到从PC資料後，可能因為中斷連線而清空buffer資料嗎?
你好，请问，我用4个路由同时给终端点播消息，可是终端有时候接收不到四个，只能接收到三个，请赐教。我觉得是不是同时发，导致发送失败，然后重传多次都失败，然后导致消息丢失，所以没收到。是否f8wConfig.cfg有相关重发的设置，求赐教！