BLE是Bluetooth Low Energy的縮寫
，即低功耗藍牙
，是藍牙規範的一個子集，從藍牙4.0版本開始引入。BLE技術成功地適應了物聯網時代那些需要少量無線數據傳輸，並對功耗很敏感的設備的需求。目前已經有為數不少的MCU器件將BLE無線收發電路集成於片內，還保持了MCU的低功耗特性，實現了單芯片的物聯網解決方案。

　　

近幾年我通過論壇的活動，陸續接觸過NXP、ST

、TI、ON Semi支持BLE的MCU產品，深感BLE的門檻不低。要設計一個充分發揮BLE優點的作品
，需要對這一技術有比較全麵的了解。學習理解BLE也(ye)需(xu)要(yao)一(yi)個(ge)過(guo)程(cheng)，如(ru)果(guo)每(mei)次(ci)僅(jin)僅(jin)是(shi)把(ba)現(xian)有(you)的(de)例(li)子(zi)拿(na)來(lai)改(gai)一(yi)改(gai)
，獲(huo)得(de)的(de)經(jing)驗(yan)很(hen)有(you)限(xian)。從(cong)什(shen)麼(me)切(qie)入(ru)點(dian)開(kai)始(shi)學(xue)習(xi)比(bi)較(jiao)好(hao)？也(ye)許(xu)不(bu)同(tong)的(de)人(ren)習(xi)慣(guan)不(bu)同(tong)。我(wo)打(da)算(suan)從(cong)MCU硬件工程師的角度提供一些參考，就有了這篇文章的構思。

 

在MCU上使用BLE，目的不外乎發送數據，或者是接收數據。為什麼BLE入門難
？對比下最簡單的：UART

、SPI，和稍微複雜一點的I2C、CAN這些——它們都是有線連接（廢話）
，發送方對接收方有一個單獨（至少在傳輸時候是獨占）的、可靠（正常情況下發出1/0就收到1/0）的數據通道；並且數據傳遞之前主機先發出請求，或者數據自身就帶有請求標誌。再看BLE，數據通過無線電波發出
，接收者要判斷天線收到的電波裏麵有沒有給自己的信號，再從有效的信號裏解調出數據……複雜程度已經不可比擬了。雖然芯片上的無線功能模塊已經把調製解調工作做了，但它的工作指令仍然是軟件下達的。

 

BLE要用無線電波傳遞信息，就是將數據編碼，調製到射頻信號中發射。通俗地講BLE使用的電波頻率是2.4G，也就是和Wi-Fi、無線鍵盤鼠標, 還有Zigbee、Thread等協議使用的2.4GHz一個概念。那麼問題來了，這些信號會不會互相幹擾？

　　

首先要明確2.4GHz這個說法指的是一個頻段而不是單一頻率（全稱2.4GHz Industry Science Medicine band），覆蓋從2400MHz到2483.5MHz, 是一個用於短距離

，無須執照使用的開放頻段。還必須明確：任何帶有信息的信號傳遞都要占用一定的帶寬，不可能是一個單一頻率。單一的頻率隻能是一個永久恒定的正弦信號——它無法攜帶信息。例如，無線電廣播所指的頻率是其信號的中心頻率。AM(調幅) 639kHz的中國之聲，實際信號帶寬是它廣播音頻帶寬的2倍。

 

BLE在這個2.4GHz頻段安排了40個信道(channel)
，中心頻率從2402MHz開始，以2MHz為間隔。如下圖上半部分：

上圖的下半部分是2.4G Wi-Fi的信道占用頻帶示意，注意Wi-Fi的不同信道頻帶就很可能存在交疊。Wi-Fi和BLE整體的頻率覆蓋是重疊的。至於不同的2.4GHz無線設備是否相互幹擾，要看實際通信的電波的能量分布：以時間為第一維度，以頻率為第二維度看，隻要不交疊

，就不會產生幹擾；但即使存在部分交疊

，不嚴重的幹擾並不損害被編碼的數據；幹擾的可能性總是存在的

，各種無線協議還需要校驗和重傳機製來保證數據完整性。

　　

一個BLE設備，在任一時刻，隻能選擇40個信道之中的一個進行發射或者監聽。發射或者試圖監聽的載波頻率
，就是對應信道的中心頻率。

 

BLE使用的調製方式叫做GFSK，這是FSK調製的一個改進形式。FSK (Frequency Shift Keying) 是一種簡單的調製的：就是將輸出信號頻率從2N個頻率中根據調製編碼進行選擇切換，最簡單是1-bit調製，稱為2-FSK（本文不討論其它的）如下圖所示：
 

 

圖上紅線代表編碼數據，藍線是輸出信號波形。注意調製後信號的瞬時頻率改變發生在編碼值改變的時刻。

 

FSK調製的一個應用是用於音頻電話線路的調製解調器(Modem)，用兩個方向的數據bit流分別調製兩個不同的單音，如下圖所示。在線路一端
，發出1170Hz表示0, 發出1270Hz表示1；線路另一端發出2025Hz表示0，發出2225Hz表示1.
 

 

我寫了一段MATLAB程序模擬這樣的調製波，將生成的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) 調製波進行FFT分析畫圖，中心頻率1170Hz和2125Hz的載波用不同顏色表示：
 

 

FSK調製的實現簡單在於隻需要用一個開關信號控製振蕩器，讓振蕩器在兩個工作頻率之間二選一，輸出就是FSK調製波。從上麵這個頻譜分析圖可以看出，FSK輸出波形的頻率成分能量最集中的那段也有一定跨度
，並非隻震蕩器的“兩個頻率”。距離中心頻率遠了之後能量分布逐漸減少，但仍可能幹擾別的信號。

 

BLE使用的GFSK調製
，前麵加個G字母代表Gaussian, 是讓控製振蕩器頻率的信號波形先通過一個高斯型低通濾波器，讓跳變沿有個平緩的過渡。也就是說，GFSK調製器雖然也是兩個基本振蕩頻率，但切換過程是平滑的。
 

 

GFSK調製比FSK調製改善了頻譜的寬度，也就是頻帶的利用效率提高了。BLE使用GFSK調製，基本數據速率是1Mbps, 也就是假若持續發射的話一秒可以發送一百萬個0或者1. BLE 5.0規範增加了2Mbps選項。

　　

選擇40個信道中的一個

，通過GFSK，BLE就能將一串0/1發送到空中去。這40個信道中有三個要單獨拿出來，編號是37、38
、39，它們是專門用於advertising（若譯作“廣播”有些偏，因為無線電發射本來就是廣播行為
，接收機都能收到）。其餘37個信道用於建立連接之後的通信。

　　

順便再提一下，BLE與經典藍牙（常見於藍牙音箱、耳機）是不能兼容
，不能相互通信的。BLEbingbushichuantonglanyadejianhuabanben，zaixindaohuafenshangjiuyousuobutong
，congshujugeshidaoshangcengxieyidouchayimingxian。xianzaizhuliudezhinengshoujishijizhichijingdianlanyayouzhichiBLE的

，我們在提及藍牙概念的時候要注意區分。

 

BLE的數據發送是以數據包（packet）為單位進行的，一個數據包就是一串有格式的0和1，經GFSK調製成某個信道上的載波
，再被接收機解調還原（這當中其實還有兩個步驟分別叫做whitening和de-whitening，但不改變數據長度和功能
，就姑且忽略了）。如下圖，一個原始BLE數據包由4段組成：頭部是8-bit Preamble，用於同步，然後是32-bit的Access Address (後麵再看它的作用)
，接著才是數據包內容的payload，最後跟著24-bit的CRC校驗值。
 

 

接收狀態的BLE設備需要在同一信道上監聽，才有可能收到這個數據包。接收方還需要知道數據包長度才能進行CRC校驗
，包長度是包含在PDU段內的。包的類型不同
，PDU的具體格式也不同。

 

信道37、38和39用於advertising, 這是BLE從設備用來表示自己存在的三個信道，也是主設備用來掃描和發起連接用的。在這三個信道中，數據包格式如下圖：
 

 

Advertising信道中的數據包類型有７種，由PDU header字段的PDU Type域決定。包長度信息是header字段的Length域。根據包類型不同，Payload的內容也不同。ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND和ADV_DIRECT_IND類型的包是從設備按照自己的間隔發出來的，其中AdvA數據字段是自己的地址（手機上的BLE掃描工具看到的就是這個地址），AdvData數據字段提供其它信息比如設備名稱、廠商代碼等，還可以包括溫度傳感器數據這樣的自定信息。ADV_DIRECT_IND這個類型要特殊一點，它是給指定的主設備發起連接用的，不附加不必要的數據。

　　

ADV_IND和ADV_SCAN_IND類型的包被主設備收到後，主設備可以馬上發送SCAN_REQ包
，請求掃描這個設備
，然後從設備再以SCAN_RSP包回應，提供補充數據(ScanRspData)。

　　

隻有當主設備要發起連接時，才會對從設備發送的包（僅ADV_IND和ADV_DIRECT_IND型有效）以CONNECT_REQ包回應。這樣
，主從設備之間就算建立起了連接，接下來將在另外的37個信道中進行信息交換。

 

剛提到過的從設備advertising有自己的間隔，這由BLE的API中advInterval參數（就是“隔多長時間廣播一次”的意思）決定。但是
，如果兩個設備的advInterval參數剛好一樣，就有可能碰巧每次都同時廣播，相互幹擾。為了緩解這個問題

，BLE規定實際兩個advertising事件之間的間隔還要加上一個隨機的延遲，如下圖：
 

 

這裏的間隔越短，其它條件不變的話，設備越容易被發現。當然，付出的代價是耗電也增加。前麵說了用於advertising的信道有3個，通常主設備也會在這三個信道上輪流監聽，因此，一個advertising事件一般來說是在三個信道上分別發送一個數據包。這麼做可以防止一個信道被幹擾了就無法使用的情況（注意信道37、38和39的頻率並不是接近的）。下麵是一個示意圖
，其中38信道上主機進行了一次掃描。
 

 

現在我要提醒大家一點：接收（監聽）狀態下BLE無線部分也是消耗很多能量的，沒有比發射狀態少太多。與片上的CPU耗電相比
，BLE的無線功能的確是耗電大戶，各廠商會把TX/RX時的電流作為省電能力衡量的重要指標——重點，RX的耗電不能想當然忽略。

　　

作為從設備，在進行advertising事件的時候，才需要把無線發射功能打開。在此外的間歇期間（幾十毫秒到幾秒）設she備bei可ke以yi休xiu眠mian等deng待dai，因yin此ci平ping均jun功gong耗hao可ke能neng很hen低di。但dan是shi主zhu設she備bei想xiang發fa現xian從cong設she備bei
，可ke就jiu不bu能neng長chang時shi間jian睡shui大da覺jiao了le
，因yin為wei從cong設she備bei隻zhi有you一yi瞬shun間jian發fa射she，如ru果guo主zhu設she備bei那na時shi沒mei有you監jian聽ting，就jiu錯cuo過guo了le。但dan主zhu設she備bei一yi直zhi處chu於yu（三個信道輪流的）jiantingzhuangtai，wuxianbufendehaodianjiuhendale。tongchangzhushebeiyehuijianxiexingdijiantinglaizhazhaocongshebei，yejiushichixujieshouyiduanshijian
，zaixiuxiyizhendecelve。ruguocongshebeiweilejianshaozishengonghao，jiangguangbodejiangeshedehenchang
，namezhushebeiyaofaxiantajiuyaofuchugengduodegonghao。

 

BLE要做到主機和從機的功耗都小，其要點，我概括為“在事先約定的時間地點碰頭”。上麵所描述的從機advertising階(jie)段(duan)
，主(zhu)機(ji)因(yin)為(wei)無(wu)法(fa)得(de)知(zhi)從(cong)機(ji)在(zai)哪(na)個(ge)時(shi)刻(ke)在(zai)三(san)個(ge)信(xin)道(dao)中(zhong)的(de)哪(na)一(yi)個(ge)廣(guang)播(bo)
，不(bu)得(de)不(bu)采(cai)取(qu)守(shou)株(zhu)待(dai)兔(tu)的(de)辦(ban)法(fa)，所(suo)以(yi)主(zhu)機(ji)耗(hao)電(dian)不(bu)能(neng)像(xiang)從(cong)機(ji)那(na)樣(yang)低(di)。但(dan)是(shi)兩(liang)者(zhe)建(jian)立(li)BLE連接之後就不一樣了，現在回顧主機為了建立連接向從機發送的CONNECT_REQ包的Payload內容：

 

除了主機和從機的BLE地址之外，LLData部分包含了許多字段：

 

AA: Access Address, 用於數據信道數據包中

CRCInit: 隨機生成的CRC初始值

WinSize: Connection Event Transmit Window Size, 以1.25ms為單位

WinOffset: 同上，Transmit Window的時間偏移量

Interval: Connection Event的間隔時間

Latency: Slave Latency參數

Timeout: connSupervisionTimeout參數，以10ms為單位

ChM: 標記要使用的數據信道

Hop: hopIncrement, 是跳頻算法的參數

SCA: 主機的sleep時鍾誤差參數

　　

由以上這些字段決定了BLE連接的初始參數。從機如何知道主機會在什麼時候，在那個信道發送數據包？請看下麵這個圖：

 

實(shi)際(ji)上(shang)，主(zhu)機(ji)和(he)叢(cong)機(ji)約(yue)定(ding)了(le)一(yi)個(ge)未(wei)來(lai)的(de)時(shi)間(jian)窗(chuang)口(kou)，主(zhu)機(ji)會(hui)在(zai)那(na)個(ge)時(shi)間(jian)窗(chuang)口(kou)內(nei)發(fa)送(song)第(di)一(yi)個(ge)數(shu)據(ju)包(bao)
，從(cong)機(ji)需(xu)要(yao)保(bao)持(chi)監(jian)聽(ting)。因(yin)為(wei)雙(shuang)方(fang)約(yue)定(ding)了(le)一(yi)個(ge)時(shi)間(jian)窗(chuang)口(kou)，無(wu)線(xian)電(dian)RX狀zhuang態tai的de時shi間jian就jiu可ke以yi縮suo短duan了le，就jiu控kong製zhi了le功gong耗hao。主zhu機ji發fa送song數shu據ju包bao之zhi後hou

，轉zhuan到dao接jie收shou狀zhuang態tai，叢cong機ji接jie收shou到dao主zhu機ji的de數shu據ju包bao
，也ye會hui很hen快kuai回hui應ying一yi個ge數shu據ju包bao，這zhe兩liang次ci雙shuang向xiang的de數shu據ju交jiao互hu時shi間jian是shi可ke以yi預yu計ji的de，不bu存cun在zai無wu用yong的deRX等待狀態。然後，主機在一個連接間隔（connInterval）之後的時刻再次發出數據包，也就是新的connection事件開始，不過通信信道由自適應跳頻算法重新選擇。上圖隻畫了最簡單的狀態，實際一個connection事件可以有多次的雙向數據包交互。

　　

把從機和主機並排起來看：
 

 

上圖還展示了BLE連接狀態的一個特性: slave latency, 即允許從機不響應一些（可能是沒有收到的）數據包，而連接暫時能保持，不斷掉。因為雙方的時間間隔約定還在，後續隻要成功交互就可以恢複通信。

 

BLE連接狀態下的數據包格式本文就不列出了

，因為涉及到Link Layer層的許多內容，要深入了解的朋友可以參閱藍牙Core specification 4.0以後版本文檔。

　　

本文的目的在於給大家一個BLE的底層是怎麼工作的一個整體印象，以及認識到它是怎樣實現低功耗的無線數據交互的。