上圖的下半部分是2.4G Wi-Fi的信道占用頻帶示意,注意Wi-Fi的不同信道頻帶就很可能存在交疊。Wi-Fi和BLE整體的頻率覆蓋是重疊的。至于不同的2.4GHz無(wú)線(xiàn)設(shè)備是否相互干擾,要看實(shí)際通信的電波的能量分布:以時(shí)間為第一維度,以頻率為第二維度看,只要不交疊,就不會(huì)產(chǎn)生干擾;但即使存在部分交疊,不嚴(yán)重的干擾并不損害被編碼的數(shù)據(jù);干擾的可能性總是存在的,各種無(wú)線(xiàn)協(xié)議還需要校驗(yàn)和重傳機(jī)制來(lái)保證數(shù)據(jù)完整性。
一個(gè)BLE設(shè)備,在任一時(shí)刻,只能選擇40個(gè)信道之中的一個(gè)進(jìn)行發(fā)射或者監(jiān)聽(tīng)。發(fā)射或者試圖監(jiān)聽(tīng)的載波頻率,就是對(duì)應(yīng)信道的中心頻率。
BLE使用的調(diào)制方式叫做GFSK,這是FSK調(diào)制的一個(gè)改進(jìn)形式。FSK (Frequency Shift Keying) 是一種簡(jiǎn)單的調(diào)制的:就是將輸出信號(hào)頻率從2N個(gè)頻率中根據(jù)調(diào)制編碼進(jìn)行選擇切換,最簡(jiǎn)單是1-bit調(diào)制,稱(chēng)為2-FSK(本文不討論其它的)如下圖所示:
圖上紅線(xiàn)代表編碼數(shù)據(jù),藍(lán)線(xiàn)是輸出信號(hào)波形。注意調(diào)制后信號(hào)的瞬時(shí)頻率改變發(fā)生在編碼值改變的時(shí)刻。
FSK調(diào)制的一個(gè)應(yīng)用是用于音頻電話(huà)線(xiàn)路的調(diào)制解調(diào)器(Modem),用兩個(gè)方向的數(shù)據(jù)bit流分別調(diào)制兩個(gè)不同的單音,如下圖所示。在線(xiàn)路一端,發(fā)出1170Hz表示0, 發(fā)出1270Hz表示1;線(xiàn)路另一端發(fā)出2025Hz表示0,發(fā)出2225Hz表示1.
我寫(xiě)了一段MATLAB程序模擬這樣的調(diào)制波,將生成的wav文件從電腦播放出來(lái)就能感受FSK的頻譜了。
FS=48000;
Tt=10;
t=0:FS*Tt-1;
f_center=1170; %2125;
f_shift=100;
baud=300;
pe0=2*pi/FS*(f_center-f_shift);
pe1=2*pi/FS*(f_center+f_shift);
s=zeros(1,FS*Tt);
c=s;
p=0;
enc_one=0;
for k=1:FS*Tt
s(k) = 0.9*sin(p);
c(k) = enc_one;
if enc_one
p = p+pe1;
else
p = p+pe0;
end
if mod(k,round(FS/baud))==0
if rand>0.5, enc_one=0; else enc_one=1; end
fprintf(''%d'',enc_one);
end
end
fprintf(''n'');
plot(t,s,t,0.5*c-1.5,''r'');
set(gca,''YLim'',[-1.6 1]);
wavwrite(s,48000,16,''fsktone.wav'');
將模擬的modem FSK (300bits/s) 調(diào)制波進(jìn)行FFT分析畫(huà)圖,中心頻率1170Hz和2125Hz的載波用不同顏色表示:
FSK調(diào)制的實(shí)現(xiàn)簡(jiǎn)單在于只需要用一個(gè)開(kāi)關(guān)信號(hào)控制振蕩器,讓振蕩器在兩個(gè)工作頻率之間二選一,輸出就是FSK調(diào)制波。從上面這個(gè)頻譜分析圖可以看出,F(xiàn)SK輸出波形的頻率成分能量最集中的那段也有一定跨度,并非只震蕩器的“兩個(gè)頻率”。距離中心頻率遠(yuǎn)了之后能量分布逐漸減少,但仍可能干擾別的信號(hào)。
BLE使用的GFSK調(diào)制,前面加個(gè)G字母代表Gaussian, 是讓控制振蕩器頻率的信號(hào)波形先通過(guò)一個(gè)高斯型低通濾波器,讓跳變沿有個(gè)平緩的過(guò)渡。也就是說(shuō),GFSK調(diào)制器雖然也是兩個(gè)基本振蕩頻率,但切換過(guò)程是平滑的。
GFSK調(diào)制比FSK調(diào)制改善了頻譜的寬度,也就是頻帶的利用效率提高了。BLE使用GFSK調(diào)制,基本數(shù)據(jù)速率是1Mbps, 也就是假若持續(xù)發(fā)射的話(huà)一秒可以發(fā)送一百萬(wàn)個(gè)0或者1. BLE 5.0規(guī)范增加了2Mbps選項(xiàng)。
選擇40個(gè)信道中的一個(gè),通過(guò)GFSK,BLE就能將一串0/1發(fā)送到空中去。這40個(gè)信道中有三個(gè)要單獨(dú)拿出來(lái),編號(hào)是37、38、39,它們是專(zhuān)門(mén)用于advertising(若譯作“廣播”有些偏,因?yàn)闊o(wú)線(xiàn)電發(fā)射本來(lái)就是廣播行為,接收機(jī)都能收到)。其余37個(gè)信道用于建立連接之后的通信。
順便再提一下,BLE與經(jīng)典藍(lán)牙(常見(jiàn)于藍(lán)牙音箱、耳機(jī))是不能兼容,不能相互通信的。BLE并不是傳統(tǒng)藍(lán)牙的簡(jiǎn)化版本,在信道劃分上就有所不同,從數(shù)據(jù)格式到上層協(xié)議都差異明顯?,F(xiàn)在主流的智能手機(jī)是既支持經(jīng)典藍(lán)牙又支持BLE的,我們?cè)谔峒八{(lán)牙概念的時(shí)候要注意區(qū)分。
BLE的數(shù)據(jù)發(fā)送是以數(shù)據(jù)包(packet)為單位進(jìn)行的,一個(gè)數(shù)據(jù)包就是一串有格式的0和1,經(jīng)GFSK調(diào)制成某個(gè)信道上的載波,再被接收機(jī)解調(diào)還原(這當(dāng)中其實(shí)還有兩個(gè)步驟分別叫做whitening和de-whitening,但不改變數(shù)據(jù)長(zhǎng)度和功能,就姑且忽略了)。如下圖,一個(gè)原始BLE數(shù)據(jù)包由4段組成:頭部是8-bit Preamble,用于同步,然后是32-bit的Access Address (后面再看它的作用),接著才是數(shù)據(jù)包內(nèi)容的payload,最后跟著24-bit的CRC校驗(yàn)值。
接收狀態(tài)的BLE設(shè)備需要在同一信道上監(jiān)聽(tīng),才有可能收到這個(gè)數(shù)據(jù)包。接收方還需要知道數(shù)據(jù)包長(zhǎng)度才能進(jìn)行CRC校驗(yàn),包長(zhǎng)度是包含在PDU段內(nèi)的。包的類(lèi)型不同,PDU的具體格式也不同。
信道37、38和39用于advertising, 這是BLE從設(shè)備用來(lái)表示自己存在的三個(gè)信道,也是主設(shè)備用來(lái)掃描和發(fā)起連接用的。在這三個(gè)信道中,數(shù)據(jù)包格式如下圖:
Advertising信道中的數(shù)據(jù)包類(lèi)型有7種,由PDU header字段的PDU Type域決定。包長(zhǎng)度信息是header字段的Length域。根據(jù)包類(lèi)型不同,Payload的內(nèi)容也不同。ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND和ADV_DIRECT_IND類(lèi)型的包是從設(shè)備按照自己的間隔發(fā)出來(lái)的,其中AdvA數(shù)據(jù)字段是自己的地址(手機(jī)上的BLE掃描工具看到的就是這個(gè)地址),AdvData數(shù)據(jù)字段提供其它信息比如設(shè)備名稱(chēng)、廠商代碼等,還可以包括溫度傳感器數(shù)據(jù)這樣的自定信息。ADV_DIRECT_IND這個(gè)類(lèi)型要特殊一點(diǎn),它是給指定的主設(shè)備發(fā)起連接用的,不附加不必要的數(shù)據(jù)。
ADV_IND和ADV_SCAN_IND類(lèi)型的包被主設(shè)備收到后,主設(shè)備可以馬上發(fā)送SCAN_REQ包,請(qǐng)求掃描這個(gè)設(shè)備,然后從設(shè)備再以SCAN_RSP包回應(yīng),提供補(bǔ)充數(shù)據(jù)(ScanRspData)。
只有當(dāng)主設(shè)備要發(fā)起連接時(shí),才會(huì)對(duì)從設(shè)備發(fā)送的包(僅ADV_IND和ADV_DIRECT_IND型有效)以CONNECT_REQ包回應(yīng)。這樣,主從設(shè)備之間就算建立起了連接,接下來(lái)將在另外的37個(gè)信道中進(jìn)行信息交換。
剛提到過(guò)的從設(shè)備advertising有自己的間隔,這由BLE的API中advInterval參數(shù)(就是“隔多長(zhǎng)時(shí)間廣播一次”的意思)決定。但是,如果兩個(gè)設(shè)備的advInterval參數(shù)剛好一樣,就有可能碰巧每次都同時(shí)廣播,相互干擾。為了緩解這個(gè)問(wèn)題,BLE規(guī)定實(shí)際兩個(gè)advertising事件之間的間隔還要加上一個(gè)隨機(jī)的延遲,如下圖:
這里的間隔越短,其它條件不變的話(huà),設(shè)備越容易被發(fā)現(xiàn)。當(dāng)然,付出的代價(jià)是耗電也增加。前面說(shuō)了用于advertising的信道有3個(gè),通常主設(shè)備也會(huì)在這三個(gè)信道上輪流監(jiān)聽(tīng),因此,一個(gè)advertising事件一般來(lái)說(shuō)是在三個(gè)信道上分別發(fā)送一個(gè)數(shù)據(jù)包。這么做可以防止一個(gè)信道被干擾了就無(wú)法使用的情況(注意信道37、38和39的頻率并不是接近的)。下面是一個(gè)示意圖,其中38信道上主機(jī)進(jìn)行了一次掃描。
現(xiàn)在我要提醒大家一點(diǎn):接收(監(jiān)聽(tīng))狀態(tài)下BLE無(wú)線(xiàn)部分也是消耗很多能量的,沒(méi)有比發(fā)射狀態(tài)少太多。與片上的CPU耗電相比,BLE的無(wú)線(xiàn)功能的確是耗電大戶(hù),各廠商會(huì)把TX/RX時(shí)的電流作為省電能力衡量的重要指標(biāo)——重點(diǎn),RX的耗電不能想當(dāng)然忽略。
作為從設(shè)備,在進(jìn)行advertising事件的時(shí)候,才需要把無(wú)線(xiàn)發(fā)射功能打開(kāi)。在此外的間歇期間(幾十毫秒到幾秒)設(shè)備可以休眠等待,因此平均功耗可能很低。但是主設(shè)備想發(fā)現(xiàn)從設(shè)備,可就不能長(zhǎng)時(shí)間睡大覺(jué)了,因?yàn)閺脑O(shè)備只有一瞬間發(fā)射,如果主設(shè)備那時(shí)沒(méi)有監(jiān)聽(tīng),就錯(cuò)過(guò)了。但主設(shè)備一直處于(三個(gè)信道輪流的)監(jiān)聽(tīng)狀態(tài),無(wú)線(xiàn)部分的耗電就很大了。通常主設(shè)備也會(huì)間歇性地監(jiān)聽(tīng)來(lái)查找從設(shè)備,也就是持續(xù)接收一段時(shí)間,再休息一陣的策略。如果從設(shè)備為了減少自身功耗,將廣播的間隔設(shè)得很長(zhǎng),那么主設(shè)備要發(fā)現(xiàn)它就要付出更多的功耗。
BLE要做到主機(jī)和從機(jī)的功耗都小,其要點(diǎn),我概括為“在事先約定的時(shí)間地點(diǎn)碰頭”。上面所描述的從機(jī)advertising階段,主機(jī)因?yàn)闊o(wú)法得知從機(jī)在哪個(gè)時(shí)刻在三個(gè)信道中的哪一個(gè)廣播,不得不采取守株待兔的辦法,所以主機(jī)耗電不能像從機(jī)那樣低。但是兩者建立BLE連接之后就不一樣了,現(xiàn)在回顧主機(jī)為了建立連接向從機(jī)發(fā)送的CONNECT_REQ包的Payload內(nèi)容:
除了主機(jī)和從機(jī)的BLE地址之外,LLData部分包含了許多字段:
AA: Access Address, 用于數(shù)據(jù)信道數(shù)據(jù)包中
CRCInit: 隨機(jī)生成的CRC初始值
WinSize: Connection Event Transmit Window Size, 以1.25ms為單位
WinOffset: 同上,Transmit Window的時(shí)間偏移量
Interval: Connection Event的間隔時(shí)間
Latency: Slave Latency參數(shù)
Timeout: connSupervisionTimeout參數(shù),以10ms為單位
ChM: 標(biāo)記要使用的數(shù)據(jù)信道
Hop: hopIncrement, 是跳頻算法的參數(shù)
SCA: 主機(jī)的sleep時(shí)鐘誤差參數(shù)
由以上這些字段決定了BLE連接的初始參數(shù)。從機(jī)如何知道主機(jī)會(huì)在什么時(shí)候,在那個(gè)信道發(fā)送數(shù)據(jù)包?請(qǐng)看下面這個(gè)圖:
實(shí)際上,主機(jī)和叢機(jī)約定了一個(gè)未來(lái)的時(shí)間窗口,主機(jī)會(huì)在那個(gè)時(shí)間窗口內(nèi)發(fā)送第一個(gè)數(shù)據(jù)包,從機(jī)需要保持監(jiān)聽(tīng)。因?yàn)殡p方約定了一個(gè)時(shí)間窗口,無(wú)線(xiàn)電RX狀態(tài)的時(shí)間就可以縮短了,就控制了功耗。主機(jī)發(fā)送數(shù)據(jù)包之后,轉(zhuǎn)到接收狀態(tài),叢機(jī)接收到主機(jī)的數(shù)據(jù)包,也會(huì)很快回應(yīng)一個(gè)數(shù)據(jù)包,這兩次雙向的數(shù)據(jù)交互時(shí)間是可以預(yù)計(jì)的,不存在無(wú)用的RX等待狀態(tài)。然后,主機(jī)在一個(gè)連接間隔(connInterval)之后的時(shí)刻再次發(fā)出數(shù)據(jù)包,也就是新的connection事件開(kāi)始,不過(guò)通信信道由自適應(yīng)跳頻算法重新選擇。上圖只畫(huà)了最簡(jiǎn)單的狀態(tài),實(shí)際一個(gè)connection事件可以有多次的雙向數(shù)據(jù)包交互。
把從機(jī)和主機(jī)并排起來(lái)看:
上圖還展示了BLE連接狀態(tài)的一個(gè)特性: slave latency, 即允許從機(jī)不響應(yīng)一些(可能是沒(méi)有收到的)數(shù)據(jù)包,而連接暫時(shí)能保持,不斷掉。因?yàn)殡p方的時(shí)間間隔約定還在,后續(xù)只要成功交互就可以恢復(fù)通信。
BLE連接狀態(tài)下的數(shù)據(jù)包格式本文就不列出了,因?yàn)樯婕暗絃ink Layer層的許多內(nèi)容,要深入了解的朋友可以參閱藍(lán)牙Core specification 4.0以后版本文檔。
本文的目的在于給大家一個(gè)BLE的底層是怎么工作的一個(gè)整體印象,以及認(rèn)識(shí)到它是怎樣實(shí)現(xiàn)低功耗的無(wú)線(xiàn)數(shù)據(jù)交互的。