【導(dǎo)讀】BLE是Bluetooth Low Energy的縮寫，即低功耗藍(lán)牙，是藍(lán)牙規(guī)范的一個子集，從藍(lán)牙4.0版本開始引入。BLE技術(shù)成功地適應(yīng)了物聯(lián)網(wǎng)時代那些需要少量無線數(shù)據(jù)傳輸，并對功耗很敏感的設(shè)備的需求。
BLE是Bluetooth Low Energy的縮寫，即低功耗藍(lán)牙，是藍(lán)牙規(guī)范的一個子集，從藍(lán)牙4.0版本開始引入。BLE技術(shù)成功地適應(yīng)了物聯(lián)網(wǎng)時代那些需要少量無線數(shù)據(jù)傳輸，并對功耗很敏感的設(shè)備的需求。目前已經(jīng)有為數(shù)不少的MCU器件將BLE無線收發(fā)電路集成于片內(nèi)，還保持了MCU的低功耗特性，實現(xiàn)了單芯片的物聯(lián)網(wǎng)解決方案。
近幾年我通過論壇的活動，陸續(xù)接觸過NXP、ST、TI、ON Semi支持BLE的MCU產(chǎn)品，深感BLE的門檻不低。要設(shè)計一個充分發(fā)揮BLE優(yōu)點的作品，需要對這一技術(shù)有比較全面的了解。學(xué)習(xí)理解BLE也需要一個過程，如果每次僅僅是把現(xiàn)有的例子拿來改一改，獲得的經(jīng)驗很有限。從什么切入點開始學(xué)習(xí)比較好？也許不同的人習(xí)慣不同。我打算從MCU硬件工程師的角度提供一些參考，就有了這篇文章的構(gòu)思。
在MCU上使用BLE，目的不外乎發(fā)送數(shù)據(jù)，或者是接收數(shù)據(jù)。為什么BLE入門難？對比下最簡單的：UART、SPI，和稍微復(fù)雜一點的I2C、CAN這些——它們都是有線連接（廢話），發(fā)送方對接收方有一個單獨(dú)（至少在傳輸時候是獨(dú)占）的、可靠（正常情況下發(fā)出1/0就收到1/0）的數(shù)據(jù)通道；并且數(shù)據(jù)傳遞之前主機(jī)先發(fā)出請求，或者數(shù)據(jù)自身就帶有請求標(biāo)志。再看BLE，數(shù)據(jù)通過無線電波發(fā)出，接收者要判斷天線收到的電波里面有沒有給自己的信號，再從有效的信號里解調(diào)出數(shù)據(jù)……復(fù)雜程度已經(jīng)不可比擬了。雖然芯片上的無線功能模塊已經(jīng)把調(diào)制解調(diào)工作做了，但它的工作指令仍然是軟件下達(dá)的。
BLE要用無線電波傳遞信息，就是將數(shù)據(jù)編碼，調(diào)制到射頻信號中發(fā)射。通俗地講BLE使用的電波頻率是2.4G，也就是和Wi-Fi、無線鍵盤鼠標(biāo), 還有Zigbee、Thread等協(xié)議使用的2.4GHz一個概念。那么問題來了，這些信號會不會互相干擾？
首先要明確2.4GHz這個說法指的是一個頻段而不是單一頻率（全稱2.4GHz Industry Science Medicine band），覆蓋從2400MHz到2483.5MHz, 是一個用于短距離，無須執(zhí)照使用的開放頻段。還必須明確：任何帶有信息的信號傳遞都要占用一定的帶寬，不可能是一個單一頻率。單一的頻率只能是一個永久恒定的正弦信號——它無法攜帶信息。例如，無線電廣播所指的頻率是其信號的中心頻率。AM(調(diào)幅) 639kHz的中國之聲，實際信號帶寬是它廣播音頻帶寬的2倍。
BLE在這個2.4GHz頻段安排了40個信道(channel)，中心頻率從2402MHz開始，以2MHz為間隔。如下圖上半部分：
上圖的下半部分是2.4G Wi-Fi的信道占用頻帶示意，注意Wi-Fi的不同信道頻帶就很可能存在交疊。Wi-Fi和BLE整體的頻率覆蓋是重疊的。至于不同的2.4GHz無線設(shè)備是否相互干擾，要看實際通信的電波的能量分布：以時間為第一維度，以頻率為第二維度看，只要不交疊，就不會產(chǎn)生干擾；但即使存在部分交疊，不嚴(yán)重的干擾并不損害被編碼的數(shù)據(jù)；干擾的可能性總是存在的，各種無線協(xié)議還需要校驗和重傳機(jī)制來保證數(shù)據(jù)完整性。
一個BLE設(shè)備，在任一時刻，只能選擇40個信道之中的一個進(jìn)行發(fā)射或者監(jiān)聽。發(fā)射或者試圖監(jiān)聽的載波頻率，就是對應(yīng)信道的中心頻率。
BLE使用的調(diào)制方式叫做GFSK，這是FSK調(diào)制的一個改進(jìn)形式。FSK (Frequency Shift Keying) 是一種簡單的調(diào)制的：就是將輸出信號頻率從2N個頻率中根據(jù)調(diào)制編碼進(jìn)行選擇切換，最簡單是1-bit調(diào)制，稱為2-FSK（本文不討論其它的）如下圖所示：
圖上紅線代表編碼數(shù)據(jù)，藍(lán)線是輸出信號波形。注意調(diào)制后信號的瞬時頻率改變發(fā)生在編碼值改變的時刻。
FSK調(diào)制的一個應(yīng)用是用于音頻電話線路的調(diào)制解調(diào)器(Modem)，用兩個方向的數(shù)據(jù)bit流分別調(diào)制兩個不同的單音，如下圖所示。在線路一端，發(fā)出1170Hz表示0, 發(fā)出1270Hz表示1；線路另一端發(fā)出2025Hz表示0，發(fā)出2225Hz表示1.
我寫了一段MATLAB程序模擬這樣的調(diào)制波，將生成的wav文件從電腦播放出來就能感受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分析畫圖，中心頻率1170Hz和2125Hz的載波用不同顏色表示：
FSK調(diào)制的實現(xiàn)簡單在于只需要用一個開關(guān)信號控制振蕩器，讓振蕩器在兩個工作頻率之間二選一，輸出就是FSK調(diào)制波。從上面這個頻譜分析圖可以看出，F(xiàn)SK輸出波形的頻率成分能量最集中的那段也有一定跨度，并非只震蕩器的“兩個頻率”。距離中心頻率遠(yuǎn)了之后能量分布逐漸減少，但仍可能干擾別的信號。
BLE使用的GFSK調(diào)制，前面加個G字母代表Gaussian, 是讓控制振蕩器頻率的信號波形先通過一個高斯型低通濾波器，讓跳變沿有個平緩的過渡。也就是說，GFSK調(diào)制器雖然也是兩個基本振蕩頻率，但切換過程是平滑的。
GFSK調(diào)制比FSK調(diào)制改善了頻譜的寬度，也就是頻帶的利用效率提高了。BLE使用GFSK調(diào)制，基本數(shù)據(jù)速率是1Mbps, 也就是假若持續(xù)發(fā)射的話一秒可以發(fā)送一百萬個0或者1. BLE 5.0規(guī)范增加了2Mbps選項。
選擇40個信道中的一個，通過GFSK，BLE就能將一串0/1發(fā)送到空中去。這40個信道中有三個要單獨(dú)拿出來，編號是37、38、39，它們是專門用于advertising（若譯作“廣播”有些偏，因為無線電發(fā)射本來就是廣播行為，接收機(jī)都能收到）。其余37個信道用于建立連接之后的通信。
順便再提一下，BLE與經(jīng)典藍(lán)牙（常見于藍(lán)牙音箱、耳機(jī)）是不能兼容，不能相互通信的。BLE并不是傳統(tǒng)藍(lán)牙的簡化版本，在信道劃分上就有所不同，從數(shù)據(jù)格式到上層協(xié)議都差異明顯?，F(xiàn)在主流的智能手機(jī)是既支持經(jīng)典藍(lán)牙又支持BLE的，我們在提及藍(lán)牙概念的時候要注意區(qū)分。
BLE的數(shù)據(jù)發(fā)送是以數(shù)據(jù)包（packet）為單位進(jìn)行的，一個數(shù)據(jù)包就是一串有格式的0和1，經(jīng)GFSK調(diào)制成某個信道上的載波，再被接收機(jī)解調(diào)還原（這當(dāng)中其實還有兩個步驟分別叫做whitening和de-whitening，但不改變數(shù)據(jù)長度和功能，就姑且忽略了）。如下圖，一個原始BLE數(shù)據(jù)包由4段組成：頭部是8-bit Preamble，用于同步，然后是32-bit的Access Address (后面再看它的作用)，接著才是數(shù)據(jù)包內(nèi)容的payload，最后跟著24-bit的CRC校驗值。
接收狀態(tài)的BLE設(shè)備需要在同一信道上監(jiān)聽，才有可能收到這個數(shù)據(jù)包。接收方還需要知道數(shù)據(jù)包長度才能進(jìn)行CRC校驗，包長度是包含在PDU段內(nèi)的。包的類型不同，PDU的具體格式也不同。
信道37、38和39用于advertising, 這是BLE從設(shè)備用來表示自己存在的三個信道，也是主設(shè)備用來掃描和發(fā)起連接用的。在這三個信道中，數(shù)據(jù)包格式如下圖：
Advertising信道中的數(shù)據(jù)包類型有７種，由PDU header字段的PDU Type域決定。包長度信息是header字段的Length域。根據(jù)包類型不同，Payload的內(nèi)容也不同。ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND和ADV_DIRECT_IND類型的包是從設(shè)備按照自己的間隔發(fā)出來的，其中AdvA數(shù)據(jù)字段是自己的地址（手機(jī)上的BLE掃描工具看到的就是這個地址），AdvData數(shù)據(jù)字段提供其它信息比如設(shè)備名稱、廠商代碼等，還可以包括溫度傳感器數(shù)據(jù)這樣的自定信息。ADV_DIRECT_IND這個類型要特殊一點，它是給指定的主設(shè)備發(fā)起連接用的，不附加不必要的數(shù)據(jù)。
ADV_IND和ADV_SCAN_IND類型的包被主設(shè)備收到后，主設(shè)備可以馬上發(fā)送SCAN_REQ包，請求掃描這個設(shè)備，然后從設(shè)備再以SCAN_RSP包回應(yīng)，提供補(bǔ)充數(shù)據(jù)(ScanRspData)。
只有當(dāng)主設(shè)備要發(fā)起連接時，才會對從設(shè)備發(fā)送的包（僅ADV_IND和ADV_DIRECT_IND型有效）以CONNECT_REQ包回應(yīng)。這樣，主從設(shè)備之間就算建立起了連接，接下來將在另外的37個信道中進(jìn)行信息交換。
剛提到過的從設(shè)備advertising有自己的間隔，這由BLE的API中advInterval參數(shù)（就是“隔多長時間廣播一次”的意思）決定。但是，如果兩個設(shè)備的advInterval參數(shù)剛好一樣，就有可能碰巧每次都同時廣播，相互干擾。為了緩解這個問題，BLE規(guī)定實際兩個advertising事件之間的間隔還要加上一個隨機(jī)的延遲，如下圖：
這里的間隔越短，其它條件不變的話，設(shè)備越容易被發(fā)現(xiàn)。當(dāng)然，付出的代價是耗電也增加。前面說了用于advertising的信道有3個，通常主設(shè)備也會在這三個信道上輪流監(jiān)聽，因此，一個advertising事件一般來說是在三個信道上分別發(fā)送一個數(shù)據(jù)包。這么做可以防止一個信道被干擾了就無法使用的情況（注意信道37、38和39的頻率并不是接近的）。下面是一個示意圖，其中38信道上主機(jī)進(jìn)行了一次掃描。
現(xiàn)在我要提醒大家一點：接收（監(jiān)聽）狀態(tài)下BLE無線部分也是消耗很多能量的，沒有比發(fā)射狀態(tài)少太多。與片上的CPU耗電相比，BLE的無線功能的確是耗電大戶，各廠商會把TX/RX時的電流作為省電能力衡量的重要指標(biāo)——重點，RX的耗電不能想當(dāng)然忽略。
作為從設(shè)備，在進(jìn)行advertising事件的時候，才需要把無線發(fā)射功能打開。在此外的間歇期間（幾十毫秒到幾秒）設(shè)備可以休眠等待，因此平均功耗可能很低。但是主設(shè)備想發(fā)現(xiàn)從設(shè)備，可就不能長時間睡大覺了，因為從設(shè)備只有一瞬間發(fā)射，如果主設(shè)備那時沒有監(jiān)聽，就錯過了。但主設(shè)備一直處于（三個信道輪流的）監(jiān)聽狀態(tài)，無線部分的耗電就很大了。通常主設(shè)備也會間歇性地監(jiān)聽來查找從設(shè)備，也就是持續(xù)接收一段時間，再休息一陣的策略。如果從設(shè)備為了減少自身功耗，將廣播的間隔設(shè)得很長，那么主設(shè)備要發(fā)現(xiàn)它就要付出更多的功耗。
BLE要做到主機(jī)和從機(jī)的功耗都小，其要點，我概括為“在事先約定的時間地點碰頭”。上面所描述的從機(jī)advertising階段，主機(jī)因為無法得知從機(jī)在哪個時刻在三個信道中的哪一個廣播，不得不采取守株待兔的辦法，所以主機(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的時間偏移量
Interval: Connection Event的間隔時間
Latency: Slave Latency參數(shù)
Timeout: connSupervisionTimeout參數(shù)，以10ms為單位
ChM: 標(biāo)記要使用的數(shù)據(jù)信道
Hop: hopIncrement, 是跳頻算法的參數(shù)
SCA: 主機(jī)的sleep時鐘誤差參數(shù)
由以上這些字段決定了BLE連接的初始參數(shù)。從機(jī)如何知道主機(jī)會在什么時候，在那個信道發(fā)送數(shù)據(jù)包？請看下面這個圖：
實際上，主機(jī)和叢機(jī)約定了一個未來的時間窗口，主機(jī)會在那個時間窗口內(nèi)發(fā)送第一個數(shù)據(jù)包，從機(jī)需要保持監(jiān)聽。因為雙方約定了一個時間窗口，無線電RX狀態(tài)的時間就可以縮短了，就控制了功耗。主機(jī)發(fā)送數(shù)據(jù)包之后，轉(zhuǎn)到接收狀態(tài)，叢機(jī)接收到主機(jī)的數(shù)據(jù)包，也會很快回應(yīng)一個數(shù)據(jù)包，這兩次雙向的數(shù)據(jù)交互時間是可以預(yù)計的，不存在無用的RX等待狀態(tài)。然后，主機(jī)在一個連接間隔（connInterval）之后的時刻再次發(fā)出數(shù)據(jù)包，也就是新的connection事件開始，不過通信信道由自適應(yīng)跳頻算法重新選擇。上圖只畫了最簡單的狀態(tài)，實際一個connection事件可以有多次的雙向數(shù)據(jù)包交互。
把從機(jī)和主機(jī)并排起來看：
上圖還展示了BLE連接狀態(tài)的一個特性: slave latency, 即允許從機(jī)不響應(yīng)一些（可能是沒有收到的）數(shù)據(jù)包，而連接暫時能保持，不斷掉。因為雙方的時間間隔約定還在，后續(xù)只要成功交互就可以恢復(fù)通信。
BLE連接狀態(tài)下的數(shù)據(jù)包格式本文就不列出了，因為涉及到Link Layer層的許多內(nèi)容，要深入了解的朋友可以參閱藍(lán)牙Core specification 4.0以后版本文檔。
本文的目的在于給大家一個BLE的底層是怎么工作的一個整體印象，以及認(rèn)識到它是怎樣實現(xiàn)低功耗的無線數(shù)據(jù)交互的。
免責(zé)聲明：本文為轉(zhuǎn)載文章，轉(zhuǎn)載此文目的在于傳遞更多信息，版權(quán)歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權(quán)問題，請電話或者郵箱聯(lián)系小編進(jìn)行侵刪。
