<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > 射頻解決方案在汽車市場中的應(yīng)用

          射頻解決方案在汽車市場中的應(yīng)用

          作者: 時(shí)間:2013-12-12 來源:網(wǎng)絡(luò) 收藏

          以無線方式發(fā)送數(shù)據(jù)的方法有很多。從遙控?zé)o鑰匙進(jìn)入(RKE)和車庫開門裝置(GDO)等簡單命令和控制方案到WLAN,您有很多種選擇。本文主要探討各種可用的無線網(wǎng)絡(luò)選項(xiàng)和必須在應(yīng)用過程中解決的局限性,旨在為設(shè)計(jì)師提供一些選擇工業(yè)應(yīng)用的無線網(wǎng)絡(luò)時(shí)所需的實(shí)用信息。

          用于車門的上鎖和解鎖的RKE系統(tǒng)就是簡單命令和控制應(yīng)用的一個(gè)典型例子。在RKE應(yīng)用中,命令從遙控鑰匙發(fā)送到接收器上。車門會(huì)上鎖和解鎖,以回應(yīng)正確收到的命令。

          就理論而言,相似車型的接收器也可接受從任何相似型號(hào)的遙控鑰匙中發(fā)送的封包,但車輛僅會(huì)接受從唯一匹配的遙控鑰匙所發(fā)出的命令。通常會(huì)使用滾動(dòng)碼產(chǎn)生器和安全加密等協(xié)定,從遙控鑰匙將唯一識(shí)別碼傳輸?shù)?a class="contentlabel" href="http://www.ex-cimer.com/news/listbylabel/label/汽車">汽車上。如此一來,您的遙控鑰匙便無法對(duì)您的朋友的類似車款解鎖,反之亦然,這樣可確保安全性。

          以汽車RKE為例,遙控鑰匙操作員通常能聽到上鎖的聲音。如果沒有聽到這種“上鎖”聲,操作員只需再按一次該按鈕。透過這種方式,人機(jī)互動(dòng)就完成了RKE例子中的回饋回路。如果您沒有聽到車門解鎖的聲音,只需重新按下按鈕,直至聽到為止。


          圖1.RKE應(yīng)用

          許多任務(wù)業(yè)應(yīng)用都需要傳輸命令和控制類型的數(shù)據(jù)。例如,將感應(yīng)器的溫度指示發(fā)送到主機(jī)。工業(yè)應(yīng)用和RKE的差異在于,前者無需人來確認(rèn)是否實(shí)際收到溫度指示。

          確認(rèn)數(shù)據(jù)是否收到的前提條件是必須存在雙向網(wǎng)絡(luò)。隨著參與數(shù)據(jù)傳輸?shù)尿?qū)動(dòng)器、交換機(jī)和電機(jī)的需求量增多,系統(tǒng)的復(fù)雜程度也會(huì)立即增加。因此,工業(yè)網(wǎng)絡(luò)通常不會(huì)使用簡單的單向RKE網(wǎng)絡(luò),因?yàn)樾枰_認(rèn)已發(fā)送的數(shù)據(jù)是否真正送達(dá)。

          基本上,工業(yè)無線解決方案的每個(gè)節(jié)點(diǎn)都包含一個(gè)微控制器。這種微控制器會(huì)與溫度感應(yīng)器和驅(qū)動(dòng)器之類的實(shí)體設(shè)備連接,以對(duì)這些設(shè)備進(jìn)行數(shù)據(jù)讀取或?qū)懭搿M瑫r(shí),這種微控制器還需負(fù)責(zé)管理網(wǎng)絡(luò)協(xié)定。該協(xié)定的選擇取決于多種因素。傳輸范圍、數(shù)據(jù)速率、功耗和網(wǎng)絡(luò)協(xié)定堆疊的復(fù)雜性等都是判斷哪種解決方案的效果最佳的因素。

          ZigBee最近受到了大量關(guān)注。做為一個(gè)標(biāo)準(zhǔn)網(wǎng)絡(luò),ZigBee或802.15.4在剛開始時(shí)對(duì)許多低功率、低數(shù)據(jù)速率的無線通信應(yīng)用而言是一個(gè)不錯(cuò)的選擇。但是,它真的適合所有應(yīng)用嗎?答案當(dāng)然不是。在某些情況下,對(duì)于高數(shù)據(jù)速率的通信而言,802.11 WLAN才是天衣無縫的搭配。類似地,有些應(yīng)用需要的是更遠(yuǎn)的傳輸范圍和更長的電池壽命。簡言之,特定的架構(gòu)原因決定了特定應(yīng)用所需的無線網(wǎng)絡(luò)類型。

          在無線網(wǎng)絡(luò)中,數(shù)據(jù)速率的提升也會(huì)帶動(dòng)系統(tǒng)資源相應(yīng)增加。以802.11 WLAN為例,部署網(wǎng)絡(luò)所需的功耗和代碼長度決定了這些協(xié)議不適合大部分嵌入式應(yīng)用。一個(gè)典型的802.11 WLAN節(jié)點(diǎn)需要1MB的程序記憶體和功能更強(qiáng)大的處理器才能部署單一功能節(jié)點(diǎn)。


          圖2.不同網(wǎng)絡(luò)所需的系統(tǒng)資源

          藍(lán)牙是另一種經(jīng)常在工業(yè)應(yīng)用中被提及的選擇。但藍(lán)牙的傳輸范圍(短)和代碼需求(稍大)及其本身為點(diǎn)到點(diǎn)通信方案等事實(shí),使其被排除在工業(yè)應(yīng)用的選擇范圍外。

          那專用網(wǎng)絡(luò)呢?專用網(wǎng)絡(luò)是指獨(dú)立于標(biāo)準(zhǔn)網(wǎng)絡(luò)運(yùn)作的網(wǎng)絡(luò)。這種網(wǎng)絡(luò)的頻帶通常為915MHz ISM(工業(yè)、科學(xué)和醫(yī)學(xué))和2.4GHz。在命令和控制類型的應(yīng)用中,有時(shí)也會(huì)使用315MHz或433MHz的頻帶。當(dāng)?shù)胤ㄒ?guī)要求通常會(huì)規(guī)定可以使用的頻率類型。

          做為以空氣傳輸?shù)纳漕l信號(hào),其功率的降低速度與傳輸距離成反比,與頻率成正比。

          除了在自由空間的路徑損耗外,信號(hào)在傳輸過程中還會(huì)受到建筑物、植物和其他物體的阻擋而進(jìn)一步衰減。其他因素(例如,多重路徑和信號(hào)散射等)也會(huì)影響接收器對(duì)所接收的射頻信號(hào)的解碼效果。其他路徑損耗模型(例如,)還需考慮天線的離地距離和市區(qū)影響的損耗,這些模型是路徑損耗更為真實(shí)的顯示。在多數(shù)應(yīng)用中,實(shí)際的路徑損耗值比圖3所示的數(shù)據(jù)高得多。有趣的是,如果頻率增加,路徑損耗也會(huì)增加。這就是為什么2.4GHz系統(tǒng)的傳輸范圍要比同等的915MHz或433MHz系統(tǒng)更小的原因之一。

          射頻工程中常用的一個(gè)經(jīng)驗(yàn)法則是:鏈路預(yù)算每增加6dB,傳輸距離將增加約一倍。只要謹(jǐn)記此法則,即可容易能算出915MHz系統(tǒng)的傳輸距離同等于2.4GHz系統(tǒng)的兩倍以上。同理,433MHz系統(tǒng)的傳輸距離也是915MHz系統(tǒng)的兩倍。因此,頻率較低的系統(tǒng)可進(jìn)行更長距離的數(shù)據(jù)傳輸。

          在為工業(yè)網(wǎng)絡(luò)選擇頻率和調(diào)變類型時(shí),數(shù)據(jù)速率也是一大關(guān)鍵要素。如前所述,以低功率運(yùn)作小型軟體堆疊的專用網(wǎng)絡(luò)是遠(yuǎn)端溫度監(jiān)控和驅(qū)動(dòng)等應(yīng)用的最佳選擇。設(shè)計(jì)師可依預(yù)期應(yīng)用自訂封包,借此大幅簡化這些網(wǎng)絡(luò)。



          關(guān)鍵詞: 射頻 汽車 Hata模型

          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();