題:
為什麼Wi-Fi無法以2.4 Gbit / s的速度運行?
MC ΔT
2014-06-30 20:01:48 UTC
view on stackexchange narkive permalink

所以Wi-Fi運行在2.4 GHz頻段上(是的,新的5 GHz)?這意味著Wi-Fi天線每秒輸出24億個方波脈衝,對嗎?

所以我想知道,為什麼它不能在每個脈衝上傳輸數據並能夠以2.4 Gbit / s?即使其中50%是數據編碼,也仍然是1.2 Gbit / s。

或者我是否知道Wi-Fi的工作原理有誤...?

首先,2.4 GHz載波是正弦波。可能使用QPSK或QUAM,以較低的速率調製數據。這是一個非常複雜和廣闊的領域。
好的正弦波。但仍然是wifi速度-通常為300Mb / s?那僅是2.4GHz的12.5%。我的觀點是,該設備已經在運行2.4GHz的正弦波輸出,所以它不能以該速度進行調製嗎?
僅在5GHz頻段上可獲得300MB。根據目前的標準,2.4GHz wifi連接理論上最大支持54mbps。
您可能對類似問題的答案感興趣:http://electronics.stackexchange.com/questions/86151/why-is-channel-capacity-a-factor-of-bandwidth-instead-of-frequency/86152#86152
中途的清晰,乾淨的2.4 GHz方波將需要至少24 GHz的帶寬。
@Kaz很好的解釋。多年以來,我一直在嘗試為人們提供有關RF通信和調製的微型引信.....您當然幫了我一個大忙
2.4GHz是光的“顏色”。就像“紅色”或“紫外線”或“ X射線”一樣。儘管工程師將其視為簡單的“正弦波”,但更具體地說,是天線產生的光子的概率函數的波形。
@Kaz誰說數據必須編碼為方波?
@immibilis上面問題的一部分,“這意味著Wi-Fi天線每秒輸出24億個方波脈衝,對嗎?”
十 答案:
Adam Davis
2014-06-30 22:05:54 UTC
view on stackexchange narkive permalink

您正在將 band bandwidth 混淆。

  • Band-載波的頻率。
  • 帶寬-信號的寬度,通常在載波周圍。

因此,典型的802.11b信號可能在2.4GHz載波上運行-頻段-它只會佔用頻譜的22MHz-帶寬。

由帶寬決定鏈路吞吐量,而不是帶寬。最好將樂隊視為行車線。可能同時有幾個人在不同的通道上傳輸數據。

有些通道更大,可以承載更多數據。有些較小。語音通信通常約為12kHz或更小。較新的wifi標准允許高達160MHz的帶寬。

請記住,雖然帶寬和發送的位是固有鏈接的,但那裡也存在轉換,這與效率有關。最有效的協議每赫茲帶寬可以傳輸十個比特。 Wifi a / g的效率為每赫茲每秒2.7位,因此您可以在其20MHz帶寬上傳輸高達54Mbps的帶寬。較新的wifi標準每赫茲超過5 bps。

這意味著,如果您想要每秒2Gbits,實際上不需要2GHz帶寬,則只需要很高的頻譜效率,而今天,通常在非常高效的調製之外使用MIMO技術就可以做到這一點。例如,您現在可以購買可提供高達3.2Gbps總吞吐量的802.11ac wifi路由器(Netgear Nighthawk X6 AC3200)。

我也總是把這些話題弄糊塗了。我理解您在這裡提到的內容,但是當人們繼續說下載速度慢是因為他們的帶寬有限-與您在此處發布的內容有什麼聯繫?對於聲稱能夠為其客戶提供54Mbps速度的ISP,可以建立什麼樣的關係?
另外,帶寬到底與吞吐量有什麼關係?我記得,傳輸的信息是幅度和相移的形式-絕不是頻率偏移,對嗎?為什麼要求分配的帶寬為22MHz?
幅度和相移固有地會使用更多帶寬,例如在信號被拉伸或收縮時,相移會在移相期間稍微改變頻率。同樣適用於任何類型的調製。您可以在單個頻率上傳輸的唯一單個信號是純連續正弦波。您甚至不能隨便打開或關閉正弦波,因為轉換也需要帶寬。
@sherrellbc您要進入的主題非常複雜,作為後續問題可能會更好,但是簡短的答案是,您也無法在不有效改變“頻率”的情況下改變幅度或相位。更改幅度或相位的速度越快,更改佔用的帶寬就越大。
多年來,帶寬已經改變了其含義,今天,寬鬆地將帶寬定義為“可以傳達的信息量”。您的ISP使用該單詞,而一名無線電工程師使用該單詞,正在將其用於不同的,基本上不相關的事物。高級調製形式使用幅度,相位和頻率調製的組合,儘管更常見的是,它們僅使用幅度和相位調製,例如QAM。因此,是的,頻率調製不常用於數據傳輸。802.11b將每個通道定義為22MHz,這就是為什麼。其他wifi標準使用不同的帶寬。
由於相位是頻率的整數,因此切勿同時使用相位和頻率調製。通常,當需要高密度時,QAM是解決方案。但是,SNR是一個主要問題,因為當同時發送更多位時,接收機更容易出錯。這就是為什麼Wi-Fi會根據鏈路質量在不同的調製格式之間進行切換的原因(僅當鏈路非常好時才使用QAM)。同樣,“帶寬”也可以應用於基帶數字數據-54 Mbps串行數據需要大約27 MHz的帶寬(DC至27 MHz)。
您能否詳細說明如何實現每赫茲1位以上的效率?
@deed02392在這個站點上將是一個很好的問題。
Spehro Pefhany
2014-06-30 20:26:01 UTC
view on stackexchange narkive permalink

Wifi信號的帶寬不像2.4GHz,它是20或40MHZ。

您所建議的(基帶2.4GHz)將使整個EM頻譜在單個通信通道中消耗至2.4GHz。

您可以從 this,它已經很好地用於其他各種用途:

enter image description here

從本質上講,2.4GHz載波會向發送數據,並允許同時傳輸許多信道,同時仍為其他應用程序留有足夠的頻譜,例如智能鑰匙遙控器,AM / FM無線電,艦船和飛機上的轉發器等。

您沒有提到還有另一個會影響數據速率的變量,即信噪比,可以通過增加發射功率來改善它。此關係由信道容量的Shannon-Hartley定理給出,它表明您的數據速率(以b / s為單位)可以大於您的帶寬(以Hz為單位)。但是,FCC還控制著您可以在EM頻譜內的發射機處使用的功率量,也有效地限制了這一因素。
@KGregory但是FCC並未調節本底噪聲,因此理論上...
是的,理論上...
Roman Starkov
2014-07-01 00:46:05 UTC
view on stackexchange narkive permalink

為了使2.4 GHz Wi-Fi信號避免在900/1800 MHz移動電話信號,100 MHz FM信號以及各種其他信號上被踐踏,對如何允許的信號與2.4 GHz正弦波有很大的差異。這是通俗的理解“帶寬”的方式。

例如,一個發射機在2412 MHz上而另一個發射機在2484 MHz上的觀點是,接收機可以過濾掉全部信號,但是它感興趣的信號。您可以通過抑制感興趣的頻段之外的所有頻率來實現。

現在,如果您接收任何信號,並過濾掉2422 MHz以上的所有內容和以下的所有內容在2402 MHz時,剩下的東西不可能與2412 MHz正弦波有太大差異。這就是頻率過濾的工作原理。

我在這個答案上做了一些擴展,在這個答案中添加了一些圖像。

alex.forencich
2014-07-01 04:49:38 UTC
view on stackexchange narkive permalink

Wi-Fi使用的載波頻率為2.4 GHz,但是信道寬度遠小於此。 Wi-Fi可以使用20 MHz或40 MHz寬的信道以及這些信道內的各種調製方案。

2.4 GHz的未調製正弦波將消耗零帶寬,但也會傳輸零信息。在幅度和頻率上調製載波可以傳輸數據。載波調製得越快,它將消耗的帶寬越多。如果您用10 MHz信號對2.4 GHz正弦波進行AM調製,結果將消耗20 MHz帶寬,頻率範圍為2.39 GHz至2.41 GHz(10 MHz與2.4 GHz之和)。

現在,Wi-Fi不使用AM調製; 802.11n實際上支持各種不同的調製格式。調製格式的選擇取決於信道的質量-例如信噪比。調製格式包括BPSK,QPSK和QAM。 BPSK和QPSK是二進制和正交相移鍵控。 QAM是正交幅度調製。 BPSK和QPSK通過移動2.4 GHz載波的相位來工作。發射機可以改變載波相位的速率受到信道帶寬的限制。 BPSK和QPSK之間的區別在於粒度-BPSK具有兩個不同的相移,QPSK具有四個相移。這些不同的相移稱為“符號”,並且信道帶寬限制了每秒可以傳輸多少個符號,但不限制符號的複雜性。如果信噪比良好(大量信號,幾乎沒有噪聲),則QPSK將比BPSK表現更好,因為它以相同的符號速率移動更多的位。但是,如果SNR不好,則BPSK是一個更好的選擇,因為信號中包含的噪聲不太可能導致接收機出錯。相對於只有2種情況,接收機很難確定在傳輸4個可能的相移時特定符號是通過哪個相移發送的。

QAM通過添加幅度調製擴展了QPSK。結果是完全額外的自由度-現在發射的信號可以使用一定範圍的相移和幅度變化。但是,更大的自由度意味著可以容忍更少的噪聲。如果SNR非常好,則802.11n可以使用16-QAM和64-QAM。 16-QAM具有16個不同的幅度和相位組合,而64-QAM具有64個。每個相移/幅度組合稱為符號。在BPSK中,每個符號傳輸一位。在QPSK中,每個符號傳輸2位。 16-QAM允許每個符號傳輸4位,而64-QAM允許6位傳輸。可以傳輸符號的速率取決於信道帶寬。我相信802.11n每秒可以傳輸13或1,440萬個符號。憑藉20 MHz寬帶寬和64-QAM,802.11n可以傳輸72 Mbit / sec。

在為多個並行流添加MIMO並將信道寬度增加到40 MHz時,總速率可以增加到600 Mbit / sec。

如果要增加數據速率,可以增加信道帶寬或SNR。 FCC和規範限制了帶寬和發射功率。可以使用定向天線來改善接收信號的強度,但是不可能降低本底噪聲-如果您知道如何做到這一點,則可以賺很多錢。

Jarrod Christman
2014-06-30 20:27:11 UTC
view on stackexchange narkive permalink

首先,您不能只是通過在空中進行一堆方波來接收並接收信號。您使用載波(以特定頻率運行)來調製數據。這樣的想法是,您可以使用接收器以相同頻率產生波來解調數據。調製的確減少了原始載波頻率可能看起來很明顯的數據量,但是如果沒有某種載波,您將無法恢復數據,因為您將無法將數據與隨機噪聲區分開。應該注意的是,該載波信號的帶寬決定了實際速度。帶寬是指調製技術將實際頻率與純載波頻率相差多少,儘管如此,即使假設理想的1:1比率(如上所述並非如此),您也必須考慮低帶寬的開銷。級別的無線協議,從而降低了有用的速度。其次,您將擁有較高級別協議(通常是TCP / IP堆棧)的開銷,該協議本身也具有開銷,從而降低了有用的速度...然後,您可能會重新傳輸在傳輸中損壞的數據(再次,通常已處理)通過更高級別的協議),甚至可以進一步減少您的數據帶寬。有許多原因說明為什麼即使給定了實際的理論數據帶寬,實際的數據帶寬還是會更少。

在正常情況下,TCP / IP開銷僅為2-8%,因此在計算中並不重要。
2%-8%的計算不重要嗎?我想這是主觀的,但這對我來說是很大的一部分。並且考慮到協議中發生了很多重傳(由於小於理想的SNR),這可能是一個較大的因素。儘管我的觀點是,很多因素都會影響理想傳輸速率(即使他對載波頻率的假設不正確)。
當試圖理解為什麼您只獲得預期帶寬的八分之一時,那麼2%到8%的聽起來並不重要。您需要大約60個相同大小的因子,才能解釋為8的因子。但是,如果您想了解整個情況,則需要知道該層存在,並且會產生少量開銷。將重傳視為TCP層的開銷是否真的合適,是另一個問題,因為重傳僅是由於較低層的丟失而發生的。
我不想弄明白這一點。但是,我仍然不同意8%並不重要。我再也沒有試圖指出他的所有損失都來自協議開銷,只是在他的主要誤解之上指出了幾種不同的情況,這將導致實際傳輸速率的損失。我還建議重新傳輸是適當的,因為這只是速率可能低於預期的另一個原因。通常,限制因素是信號的帶寬,但請記住,還有其他因素很重要。
kjgregory
2014-06-30 20:36:34 UTC
view on stackexchange narkive permalink

這確實是一個非常複雜的話題。但是,給您一個簡單的答案,是因為FCC制定了一些規則,這些規則可以控制可用於wifi通信的帶寬和發射機功率。這是因為還有許多其他人試圖將EM頻譜用於各種類型的無線通信(例如,手機,wifi,藍牙,am / fm廣播,電視等)。實際上,載波頻率(2.4GHz)與通信帶寬(或可以達到的數據速率)幾乎沒有關係。

儘管從技術上講是正確的,但我認為這不能很好地回答這個問題:“為什麼x無法攜帶y數據?”“因為規則。”
IMO有點不公平。就像我說的那樣,這是一個非常複雜的主題。他們回答了為什麼*不能*實現2.4Gbps是因為給定足夠的帶寬和功率。之所以不能“實現” 2.4Gbps的答案,是因為它會干擾他人的通信,因此制定了限制其功能的規則。
sanchises
2014-07-01 20:19:04 UTC
view on stackexchange narkive permalink

如前所述,您在混淆帶寬。但是,所有答案都不能給出直觀的解釋。

直觀的解釋可以通過揚聲器來完成。您有一個高蜂鳴聲和一個低蜂鳴聲,表示1和0。通過交替發出高蜂鳴聲和低蜂鳴聲來傳輸數據。音調本身的頻率與您在高音和低音之間交替的速度沒有多大關係(見下文)。它們是載波波:它們接收您的塊波信號並將其轉換為高頻和低頻波。唯一的區別是高頻和低頻波非常靠近,並且以2.4GHz為中心。

現在,對於需要上限的部分。採用我們的“蜂鳴”系統:您當然不能在單個聲波中十次更改蜂鳴聲的音調頻率(頻段)。因此,當頻率變化的頻率以不同的嗶嗶聲可以聽見,以及只是奇怪的失真嗶嗶聲時,有一個下限。您可以更改頻率的速率稱為帶寬;帶寬越低,發出的嗶嗶聲越清晰(因此,當接收不良時,鏈接速度越低)。

hyportnex
2014-07-05 02:34:33 UTC
view on stackexchange narkive permalink
香農的容量定理說,如果給定的附加噪聲中帶寬W中接收到的SNR,則信道具有$ C = Wlog_ {2}(1 + SNR)$$容量,以比特/秒為單位。這裡的容量意味著如果給定W上的所需信息速率小於C,則將存在一個具有足夠複雜度的糾錯碼,利用該糾錯碼可以在給定SNR下有效地實現零錯誤概率信息傳輸。這與載波頻率無關,而僅與FCC法規間接相關。 FCC決定可以在什麼帶寬上傳輸多少功率,設計者決定傳輸系統的複雜性和技術,而用戶端則具有最大的信息速率,因為SNR將取決於所需的距離,功率和帶寬。 FCC允許。在系統相當靜態的PSTN上,存在一種調製格式,該格式使用4kHz標稱帶寬中的1024個波形,從而得出理論上40kbit / sec的信息速率!如果可以在移動信道上實現這種複雜性,那麼在足夠高的SNR下可以達到〜10x20 = 200Mbit / sec,那麼重點就在於足夠高!載波頻率越高,傳播損耗就越大,但使射頻電路在足夠高但具有先驗給定帶寬的條件下工作則變得容易。
supercat
2014-07-02 01:23:41 UTC
view on stackexchange narkive permalink

儘管實現的確切方式有所不同,但是無線電通信通常涉及獲取包含要發送信息的低頻信號,並使用一種稱為調製的技術來對更高的頻率範圍進行調製。用“黑匣子”來思考也許是最容易的,在給定兩個包含不同頻率組合的信號的情況下,“黑匣子”將對原始信號中存在的每個信號組合,將總和和差頻與該乘積成比例。原始信號的優勢。如果一個人輸入的音頻信號包含0-10KHz範圍內的頻率以及一個720,000Hz正弦波(WGN-720 Chicago使用的載波),則從盒子中接收的信號中僅包含710,000Hz至730,000Hz。如果接收器將該信號及其自身的720,000Hz正弦波饋入類似的盒中,則它將從該盒中接收0-10Khz範圍內的信號以及1,430,000Hz至1,450,000Hz範圍內的信號。 0-10Khz中的信號將與原始信號匹配;在1,430,000Hz到1,450,000Hz範圍內的那些信號可能會被忽略。

如果除了WGN之外,還有另一個電台正在廣播(例如WBBM-780),則770,000Hz到790,000Hz範圍內的信號由接收器將後者轉換為50,000Hz至70,000Hz(以及1,490,000Hz至1,510,000Hz)範圍內的信號。由於無線電接收機的設計假設是,感興趣的音頻不會涉及10,000Hz以上的頻率,因此它可以忽略所有較高的頻率。

即使在傳輸之前將WiFi數據轉換為2.4GHz附近的頻率,感興趣的“實際”頻率也要低得多。為了避免WiFi傳輸干擾其他廣播,WiFi傳輸必須與其他傳輸使用的頻率保持足夠的距離,以使他們可能接收到的任何不想要的頻率內容與他們所尋找的內容完全不同。

請注意,無線電設計中的“黑匣子”混頻器方法有點簡化;從理論上講,無線電接收器可能會對未濾波的信號使用頻率合併電路,然後對輸出進行低通濾波,但通常需要使用多級濾波和放大。此外,由於各種原因,無線電接收機通常更容易將輸入信號與感興趣的實際載波頻率混合,而不是將較高或較低一定數量的可調頻率混合(術語“ *雜波*達因”指(使用“不同”頻率),對結果信號進行濾波,然後將該濾波後的信號轉換為所需的最終頻率。關鍵是,唯一能夠將WGN傳輸的1KHz音頻信號(頻率為719,000Hz和721,000Hz)與WBBM-780傳輸的59KHz和61Khz音區分開的唯一事實是,無線電台並非期望以超過10Khz的速度傳輸音頻內容,因此接收器將忽略遠超過10Khz的任何內容。

Guill
2014-07-06 23:15:42 UTC
view on stackexchange narkive permalink

簡單的答案是可以完成。。您可以使用所需的任何信號來“調製任何”載波。

假設允許這樣做,那麼問題是,它有用嗎?為了回答這個問題,我們必須了解當調製載波時會發生什麼。讓我們以工作在1 MHz(1,000KHz)的載波為例,我們使用從0到100KHz的信號對其進行調製。信號的“混合”產生900到1,100 KHz的範圍信號。同樣,如果我們使用0到1,000 KHz,則生成信號的範圍現在變為0到2,000 KHz。如果現在將這些信號施加到天線,我們將在0到2,000 KHz範圍內發送信號。如果兩個或多個“附近”人這樣做,則信號將相互干擾,並且接收器將無法檢測任何信息。如果我們將功率限制在天線範圍內,並且兩個人或多個人足夠被分開,則它們可以“操作”而幾乎沒有乾擾。

儘管從理論上講,一個發射機可以使用整個EM頻譜進行操作,但這是不切實際的,因為其他人也希望使用它,就像在其他情況下一樣,限制和需求超過供應,則必須“分割”,共享,限制和控制資源。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...