電路功能

　　無線收發組件中，315MHz收發組件是常用的一種，若要自制則相對要困難些。本文所介紹的無線收發電路采用ATMEL公司的AT89C2051單片機作為編碼和解碼電路的核心器件，接收端采用1602字符液晶顯示器顯示所接收到的數據。

　　工作原理

　　首先介紹編碼電路。在使用過程中，筆者直接將發送模塊的三個端子與自制的一塊學習板相連，沒有添加其他電子元件，屬單片機最小系統，S1和S2為兩個按鍵，本文程序未用。圖1所示為發送端電路圖，圖2為接收端電路圖。

?

　　圖1 發送端電路圖

?

　　圖2 接收端電路圖

　　接收端將接收到的數據送入單片機的同時，還會驅動發光二極管以便對硬件和軟件糾錯，若數據接收成功還將顯示在1602液晶顯示器上，因本文主要是介紹無線遙控，關于1602字符液晶顯示器的原理與應用不做介紹，讀者可以參考《無線電》以往的相關文章，如果出于成本和程序難易程度的考慮，也可改用7段數碼管甚至用發光二極管來作數據的顯示。另外要注意一點，發送端和接收端的時鐘晶振的頻率必須要相同，否則編程會很麻煩甚至數據無法正常接收，這一點在介紹程序時還會提到。

　　軟件方面，借鑒了紅外遙控的編碼思路，首先發送引導脈沖，緊接下來是數據碼和數據反碼，這一過程是在定時中斷里面完成的，定時時間一到就調用一加法程序，然后將結果作為數據發送出去，計數器溢出后就清零進入下一循環。

　　引導脈沖由一個低電平和高電平組成，每個高低電平延時大約11ms,這個靠11ms的延時程序來實現，數據碼和反碼每個位也是使用這個延時，可以說這11ms的延時就相當于比較簡單的通信協議，也是發送和接收程序的核心部分，只要兩邊的延時相同，00H到0FFH內的數據都能被正確接收，接收端檢測到1 lms的高低電平變化后，就調用11ms的延時來判斷數據"0"和"1",并將正確接收到的數據顯示在液晶顯示器上。前面已講過若時鐘晶振的頻率不同那么發送端和接收端的延時子程序就要計算得相一致，這樣程序編制就很麻煩甚至不能正常接收數據，這一點和單片機的串口通信是同樣的道理。加入數據反碼為的是提高抗干擾的效果，接收端的程序中就可以設置兩個數據存儲器，一個放原碼一個放反碼，接收完畢再將兩個存儲器的內容作比較即可判斷是否接收正確，若正確再執行應執行的程序。

　　本刊今年第1期有一篇介紹同樣內容的文章使用的是串口通信的方法，而本文是采用延時，雖方法有點不一樣，但關鍵的一點是數據傳送速度都不能超過發送和接收模塊的最快速度，本文使用11ms的延時，那每秒就大概是100個位的數據傳送速度，讀者可以將延時程序增大和減小，以此就可以測試出315MHz發送和接收模塊的最高和最低數據傳送速度。

　　發射端和接收端的程序見本期配刊光盤，都已盡量地模塊化，能共享的就共享，所以整個程序都比較簡單，且收發程序都使用的是8051最基本最常用的指令，沒有用復雜的數學運算和邏輯運算指令，初學者很容易理解。因為主要是面向單片機初學者，所以本文介紹的編碼格式是比較簡單的，抗干擾效果較差，而無線數據通信的編碼方法有很多種，有行業內的標準化編碼方法，也有廠家獨立研發的，而315MH2收發模塊的工作原理和工作速度就基本決定了它不能用于高速通信，且也沒有硬件抗干擾的能力，要排除干擾只能完全依靠軟件來實現，本文的程序中，當315MHz接收模塊接通電源后就一直處于工作狀態，在有效接收范圍內只要有315MHz發射模塊發射信號，則接收端就會有輸出，程序經筆者實際試驗除配對的發射和接收兩個系統外，再外加了一個機動車防盜遙控手柄，當然也是315MHz的，當發射和接收系統之間正在傳送遙控數據時將遙控手柄的任意鍵按下，發現這樣會打斷系統間的數據傳送導致接收端接收不到任何數據，這是最大的缺點，但是對要求較低的應用場合應該可以滿足，因為程序至少不會對其他的315MHz發射模塊有響應，意即不會有誤動作，比如家里用來遙控電燈，不會隨時都有人拿著個汽車防盜遙控器在附近按來按去。

　　業余條件下的電路調試

　　筆者是單片機愛好者，個人水平和試驗器材有限，是典型的"一臺萬用表打天下",手中既沒有示波器來查看波形，也沒有仿真器，對于軟硬件只能靠收發兩個板子上的發光二極管和接收端的1602液晶顯示器的實際運行來排錯，如果數據發出來，則與發射模塊相連的發光二極管點亮，表明有信號發出，同樣接收端的發光二極管如果與發射端的變化同步，表明接收到了信號，從而完成硬件排錯，最后將接收到的數據顯示在顯示器上。

　　程序上的排錯主要集中在數據延時上，剛開始筆者將要發送的每個數據位的延時選得很短，不知不覺中已遠遠超出315MHz發送和接收模塊的數據收發速度，也就是相當于在串行通信中將波特率設置過高，導致收發失敗，這是筆者遇到的最大障礙，因為筆者開始把問題歸結為硬件故障，在這個不大不小的問題上白白花了很多時間，后來在一次上網查找資料的時候讀到與315MHz模塊相關的一篇文章，里面提到收發速度問題，說它的傳輸速度是很低的，不然將工作不正常甚至無法傳輸數據，筆者這才恍然大悟，回家后立刻對延時進行修改，改一次源碼就重燒錄一次芯片，直到最后將延時鎖定在11ms,至此排錯告一段落，收發雙方能進行正確的數據傳輸了，發送端發送的數據也基本都能在1602顯示器上顯示出來，但仍有個別的數據不穩定，筆者分析這主要是硬件本身固有的缺陷和程序的合理性造成的，感興趣的讀者朋友可以在本文的軟硬件基礎上，發揮自己的能力對電路和軟件再作進一步的修改，以求達到更好的效果。希望大家到《無線電》雜志的BBS論壇里進行討論，將自己對程序的改進方法提出來。