最後結論：
一直以為的硬體問題很可能是軟體問題，檢查下程式中是否有陣列操作溢位錯誤。
除錯現象：
用zigbee組網，協調器和路由器/終端組網後，發現路由器上傳到協調器的資料週期並非按照我程式的設定，**段如下：
週期處理段：
>
if傳送段：
>
void
(void
)>
else
>
}
預期出現的現象是協調器約3s收到一次路由器傳送的資料，如下圖：原因分析：1、硬體問題！一定是硬體問題！於是我測試了電源質量，如下圖：實際收到的資料，如下圖：
好傢伙，這麼大的紋波，再看看給cc2530模組供電的3.3v電源訊號質量，如下圖：
咦，我滴個乖，這不是很好嗎？難道是電源紋波對模組的電磁干擾！？管他三七二一，先乾了再說，磁阻，電感，電容，電阻，一切能夠消減電源紋波的手段全都上了，如下圖：
摸著電絡鐵，嗆了幾口松香發出老菸………………
電源質量是改善了，但協調器收到的資料依然是密密麻麻，我t，，。
2、難道不是硬體問題，難道是軟體問題？！
週期處理：
>
if資料傳送：
>
void
(void
)>
else
>
}
3、轉角處的發現：
此時身體略微有些疲軟，深吸一口氣再切換到原來**、編譯，突然，
build框中乙個「金嘆號」閃過，並被我注意，如下圖：
什麼意思，out of range，直覺告訴我此處有鬼並且不一般；憑著我小學二年級的拼音能力，我找到了原因。
——定義的陣列溢位了！
——定義的陣列溢位了！
——定義的陣列溢位了！
你看到了嗎？
解決問題：
經過上面一頓猛如虎的操作，我拖著略顯疲憊但激動萬分的心情…………
我將 uint8 msgtable[12]改為了uint8 msgtable[13]；
頓時，真個世界都有序而美好了。
真是應驗了唐朝李白的一首詩，《轉角遇見愛》
額外的發現。。。。
再排除硬體過程中，我本計畫用rc濾波將電源高頻干擾去除，結果導致cc2530模組直接無法工作，萬用表測量電壓也是3.3v正常，但示波器，測試電源卻發現，如下現象：
原因分析：zigbee在發射時會有較大瞬時功耗，如果此時電源環路阻抗過大將導致能量**不足進而傳送失敗。
解決辦法就是，提高供電迴路供電能力減小阻抗。
——————在兩外乙個專案中我將 ch340c做和cc2530做在一起，並用供電能力只有100ma的ldo進行供電，當插入usb口後，電腦無法識別，正是由於次原因。
Zigbee和wifi通道設定避免同頻干擾
為什麼是這七個通道呢？我們來看一下wifi通道的頻譜與zigbee通道頻譜的重疊就知道了。wifi常用是1,6,11，每個通道是22mhz的頻譜頻寬，那麼對照zigbee通道的分布，可以發現14,15通道正好在wifi通道的1,6通道的中間。這樣就可以理解zigbee聯盟推薦的通道的理由了。以上分析...
Tcp設定傳送和接收超時
linux和windows下用setsockopt設定so sndtimeo,so rcvtimeo的引數的一點區別 udp的socket在某些情況 如對方關閉時，本地可能sendto不出去資料，然後recvfrom就會被阻塞，這時就需要設定 這兩個引數的值提高程式質量。linux struct t...
splunk設定索引週期和索引大小
步驟一 messages coldpath splunk db messages colddb enabledataintegritycontrol 0 enabletsidxreduction 0 homepath splunk db messages db thawedpath splunk d...