之前寫過一個zigbee資料測試，由於當時對zigbee理解的很淺，所以寫的程式碼丟包嚴重。最近為了提高資料傳輸的可靠性，改進了一下通訊的方式，結果還不錯。
　　之前：協調器+普通終端節點，協調器廣播，節點接收廣播訊息。
　　現在：協調器+路由節點，協調器記錄路由的網路短地址進行點播（單播）。
　　這樣改進的原因是：
　　1.如果普通終端節點接收資料，那麼由於節點預設會定期進入休眠，所以會在休眠喚醒的時候向父節點發送Data Request來看一看在休眠期間有沒有發給自己的資料，如此便會增加父節點的通訊負擔，也會造成更多的CSMA/CA的避讓，因此改為路由節點並且不休眠。
　　2.單播比廣播穩定，原因是單播可以使用ZSTACK自帶的資料重傳機制。協調器通過單播的方式把資料發給路由節點之後，那麼路由節點會在幾毫秒的時間內就傳送一個MAC ACK。如果協調器沒有收到MAC ACK，就會自動以5毫秒左右的間隔進行多次（預設為8次）資料重傳。MAC ACK跟APS ACK相比，速度更快。
　　本次測試的裝置連線：
PC串列埠助手—-通過串列埠線定時給————-協調器傳送資料
協調器———-通過zigbee網路給———–路由節點發送資料
路由節點——-通過串列埠線把資料傳送給—–另一個PC串列埠助手
　　如此一來就可以根據串列埠助手統計收和發資料的數量，來測試丟包率。
　　注，由於真正測試丟包只需要看節點收到多少資料，而這個方法還會通過串列埠這樣多餘的路徑，所以實際上更苛刻。
　　兩個節點距離90釐米，天線全功率（0xF5）,無干擾，有效16個位元組，結果如下：
1000ms間隔：
　　發31584位元組，收31024位元組，包接收率98.2%
500ms間隔：
　　發18992位元組，收18720位元組，包接收率98.6%（比1000ms還高，，，，不太理解）
總的來說，單播的通訊方式還是比較可靠的。
附，路由回覆的MAC ACK，與在路由掉線時的協調器資料自動重傳抓包：