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

          新聞中心

          EEPW首頁 > 模擬技術 > 設計應用 > 調(diào)制解調(diào)器的詳細介紹

          調(diào)制解調(diào)器的詳細介紹

          作者: 時間:2012-09-26 來源:網(wǎng)絡 收藏

          本文引用地址:http://www.ex-cimer.com/article/185715.htm

          三. Modem的傳輸數(shù)率

          Modem的傳輸速率,指的是Modem每秒鐘傳送的數(shù)據(jù)量大小。我們平常說的14.4K、28.8K、33.6K、56K等,指的就是Modem的傳輸速率。傳輸速率以bps(比特/秒)為單位。因此,一臺33.6K的Modem每秒鐘可以傳輸33600bit的數(shù)據(jù)。由于目前的Modem在傳輸時都對數(shù)據(jù)進行了壓縮,因此33.6K的Modem的數(shù)據(jù)吞吐量理論上可以達到115200bps,甚至230400bps。

          Modem的傳輸速率,實際上是由Modem所支持的調(diào)制協(xié)議所決定的。我們平時在Modem的包裝盒或說明書上看到的V.32、V.32bis、V.34、V.34+、V.fc等等,指的就是Modem的所采用的調(diào)制協(xié)議。其中V.32是非同步/同步4800/9600bps全雙工標準協(xié)議;V.32bis是V.32的增強版,支持14400bps的傳輸速率;V.34是同步28800bps全雙工標準協(xié)議;而V.34+則為同步全雙工33600bps標準協(xié)議。以上標準都是由ITU(國際通訊聯(lián)盟)所制定,而V.fc則是由Rockwell提出的28800bps調(diào)制協(xié)議,但并未得到廣泛支持。

          提到Modem的傳輸速率,就不能不提時下被炒得為熱的56K Modem。其實,56K的標準已提出多年,但由于長期以來一直存在以Rockwell為首的K56flex和以U.S.Robotics為首X2的兩種互不兼容的標準,使得56K Modem遲遲得不到普及。值得慶幸的是,今年2月,在國際電信聯(lián)盟的努力下,56K的標準終于統(tǒng)一為ITU V9.0,眾多的Modem生產(chǎn)廠商亦已紛紛出臺了升級措施,而真正支持V9.0的Modem亦已經(jīng)遍地開花。56K有望在一到兩年內(nèi)成為市場的主流。在這里要順便說一下的是,由于目前國內(nèi)許多ISP并未提供56K的接入服務,因此在購買56K Modem前,最好先向你的服務商打聽清楚,以免造成浪費。
          以上我們所講的傳輸速率,均是在理想狀況的得出的。而在實際使用過程中,Modem的速率往往不能達到標稱值。實際的傳輸速率主要取決于以下幾個因素:

          1、電話線路的質(zhì)量

          因為調(diào)制后的信號是經(jīng)由電話線進行傳送,如果電話線路質(zhì)量不佳,Modem將會降低速率以保證準確率。為此,我們在連接Modem時,要盡量減少連線長度,多余的連線要剪去,切勿繞成一圈堆放。另外,最好不要使用分機,連線也應避免在電視機等干擾源上經(jīng)過。

          2、是否有足夠的帶寬

          如果在同一時間上網(wǎng)的人數(shù)很多,就會造成線路的擁擠和阻塞,Modem的傳輸速率自然也會隨之下降。因此,ISP是否能供足夠的帶寬非常關鍵。另外,避免在繁忙時段上網(wǎng)也是一個解決方法。尤其是在下載文件時,在繁忙時段與非繁忙時段下載所費的時間會相差幾倍之多。

          3、對方的Modem速率

          Modem所支持的調(diào)制協(xié)議是向下兼容的,實際的連接速率取決于速率較低的一方。因此,如果對方的Modem是14.4K的,即使你用的是56K的Modem,也只能以14400bps的速率進行連接。

          四. Modem的傳輸協(xié)議

          Modem的傳輸協(xié)議包括調(diào)制協(xié)議(Modulation Protocols)、差錯控制協(xié)議(Error Control Protocols)、數(shù)據(jù)壓縮協(xié)議(Data Compression Protocols)和文件傳輸協(xié)議。調(diào)制協(xié)議我們在前面已經(jīng)討論過,現(xiàn)在著重談一下其余的三種傳輸協(xié)議。

          1、 差錯控制協(xié)議

          隨著Modem的傳輸速率不斷提高,電話線路上的噪聲、電流的異常突變等,都會造成數(shù)據(jù)傳輸?shù)某鲥e。差錯控制協(xié)議要解決的就是如何在高速傳輸中保證數(shù)據(jù)的準確率。目前的差錯控制協(xié)議存在著兩個工業(yè)標準:MNP4和V4.2。其中MNP(Microcom Network Protocols)是Microcom公司制定的傳輸協(xié)議,包括了MNP1—MNP10。由于商業(yè)原因,Microcom目前只公布了MNP1—MNP5,其中MNP4是目前被廣泛使用的差錯控制協(xié)議之一。而V4.2則是國際電信聯(lián)盟制定的MNP4改良版,它包含了MNP4和LAP-M兩種控制算法。因此,一個使用V4.2協(xié)議的Modem可以和一個只支持MNP4協(xié)議的Modem建立無差錯控制連接,而反之則不能。所以我們在購買Modem時,最好選擇支持V4.2協(xié)議的Modem。

          另外,市面上某些廉價Modem卡為降低成本,并不具備硬糾錯功能,而是使用使用了軟件糾錯方式。大家在購買時要注意分清,不要為包裝盒上的“帶糾錯功能”等字眼所迷惑。

          2、數(shù)據(jù)壓縮協(xié)議

          為了提高數(shù)據(jù)的傳輸量,縮短傳輸時間,現(xiàn)時大多數(shù)Modem在傳輸時都會先對數(shù)據(jù)進行壓縮。與差錯控制協(xié)議相似,數(shù)據(jù)壓縮協(xié)議也存在兩個工業(yè)標準:MNP5和V4.2bis。MNP5采用了Rnu-Length編碼和Huffman編碼兩種壓縮算法,最大壓縮比為2:1。而V4.2bis采用了Lempel-Ziv壓縮技術,最大壓縮比可達4:1。這就是為什么說V4.2bis比MNP5要快的原因。要注意的是,數(shù)據(jù)壓縮協(xié)議是建立在差錯控制協(xié)議的基礎上,MNP5需要MNP4的支持,V4.2bis也需要V4.2的支持。并且,雖然V4.2包含了MNP4,但V4.2bis卻不包含MNP5。

          3、文件傳輸協(xié)議

          文件傳輸是數(shù)據(jù)交換的主要形式。在進行文件傳輸時,為使文件能被正確識別和傳送,我們需要在兩臺計算機之間建立統(tǒng)一的傳輸協(xié)議。這個協(xié)議包括了文件的識別、傳送的起止時間、錯誤的判斷與糾正等內(nèi)容。常見的傳輸協(xié)議有以下幾種:
          ASCII:這是最快的傳輸協(xié)議,但只能傳送文本文件。

          Xmodem:這種古老的傳輸協(xié)議速度較慢,但由于使用了CRC錯誤偵測方法,傳輸?shù)臏蚀_率可高達99.6%。
          Ymodem:這是Xmodem的改良版,使用了1024位區(qū)段傳送,速度比Xmodem要快。
          Zmodem:Zmodem采用了串流式(streaming)傳輸方式,傳輸速度較快,而且還具有自動改變區(qū)段大小和斷點續(xù)傳、快速錯誤偵測等功能。這是目前最流行的文件傳輸協(xié)議。

          除以上幾種外,還有Imodem、Jmodem、Bimodem、Kermit、Lynx等協(xié)議,由于沒有多數(shù)廠商支持,這里就略去不講。


          上一頁 1 2 下一頁

          評論


          相關推薦

          技術專區(qū)

          關閉
          看屁屁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); })();