天天看點

關于Zstack_2.5.1中的重傳機制

問題起源于丢包率:丢包率的定義由自己去定義,重傳收到資料算不算丢包由你自己去定義。問題起源于丢包率,發100個資料包,結果收到超過100個資料包。Zstack中mac層中預設有CSMA/CA機制,但是最後還是沒有搞清楚這個重傳機制。

1.mac層的ACK隻管點對點的,而且mac層的ack是無法關閉的;多跳的ACK需要應用層的ack,應用層的ack可以關閉。

2.可以嘗試自己抓包看看是否重傳了什麼資料,然後去修改代碼,嘗試自己能夠得出丢包率。

3.協定棧中maxFrameRetries,mac_api.h中的MAC_TXOPTION_ACK等參數可以自己嘗試去修改。但是通過這些參數修改是不能夠關閉協定棧預設的ack,是以若要測丢包率則需要自己在應用層裡面對資料丢包進行比對測試。官方TI有一個無線品質傳輸測試丢包率的Demo,但是那個代碼延遲性太高了,丢包率一直在變動,因為一直在統計曆史資料的丢包情況。打算自己寫,但是一直卡出問題了。如果實在不想寫的話,可以采用官方的SmartRF Studio軟體進行丢包率的測試以及位測試。

4.ZigBee終端與ZigBee協調器之間互相通信過程:

(1)ZigBee終端通過AF函數發送資料;(2)ZigBee Coordinator 回複MAC層的ACK;(3)ZigBee Coordinator的APS層回複ACK幀。

5.關于發送資料的最小周期?

因為丢包率的時候,若一秒發1次,則不會出現丢包;一秒發10個資料包,則出現丢包;這個問題相信也有不少人遇到了。這裡僅僅記錄自己的搜尋到的結果。

若單單從實體層來說,最小周期應該是微秒級的。但是有了協定棧發送資料,很多時間花在OSAL的排程上面,上層到底層的資料幀封裝、任務處理等,是以時間間隔較大。是以建議不要一次性發送大量資料,盡量讓他一段一段發送,另外波特率要大于傳輸速率。需要抓包看看具體有多少包發送出去了。

PS:研究精神還是有待加強,遇到了些許困難還是放棄了。記錄在此,給有需要的人看吧。

  • 後記:最後還是找到了一個解決方案:通過發送節點發送資料包,然後接收節點直接連接配接PC機上的序列槽助手,收到一條資料則列印一條資料(可以标定序号),結果發現在PC機上有些資料包重傳列印在序列槽助手,有些資料則跳過後不顯示在序列槽助手。通過這種方式可以累計統計丢包率。但是還是沒有弄明白Zstack協定棧裡面的重傳機制

繼續閱讀