BLE 廣播包數(shù)據(jù)格式解析說明 ...... 矜辰所致

前言

報文格式 是 藍(lán)牙學(xué)習(xí)必備理論基礎(chǔ)，本文來講一講藍(lán)牙廣播報文格式 以及 在 沁恒微藍(lán)牙芯片代碼中如何設(shè)置廣播報文 。

我是矜辰所致，全網(wǎng)同名，盡量用心寫好每一系列文章，不浮夸，不將就，認(rèn)真對待學(xué)知識的我們，矜辰所致，金石為開！

一、 廣播包格式

BLE 廣播報文（Advertising Packet）在空中的完整格式分 4 段，總共 47 字節(jié)（BLE 4.x/5.x 都一樣），用戶能改的只有中間 31 字節(jié) Payload（下圖淺綠色部分），其余由鏈路層自動拼好。

1.1 格式解析

我們先上一張整體的廣播包示意圖（后面會詳細(xì)分析）：

我們再給加上解釋說明：

看完整體的格式包，我們再重點關(guān)注一下我們應(yīng)用時候可以修改的 Payload 部分， 這部分由若干「AD Structure」拼接而成，「AD Structure」是有一定格式的，我們在代碼中定義廣播包的時候就是要按照這種格式填寫我們想要的廣播數(shù)據(jù)。

「AD Structure」 格式如下：

Len(1 B) + Type(1 B) + Data(n B)

整包總長度 ≤ 31 B，不足補 0 ，如下圖：

對于每個 「AD Structure」，我們重點要知道的是類型，AD Type（包括 0x01 ~ 0xFF 的全部定義）由 Bluetooth SIG（藍(lán)牙技術(shù)聯(lián)盟）統(tǒng)一分配和維護(hù)，大家需要用什么可以網(wǎng)上查詢，這里放出部分常用 AD Type（保持更新）：

根據(jù)上面表格，我們?nèi)绻朐O(shè)置短的 16bit UUID：

0x03 0x02 (UUID低8位) (UUID高8位)
0x03 0x02 0xE1 0xFF

如果想設(shè)置完整的名字：

(名字長度加+1) 0x09 (名字，自己取，自己算長度)
0x07 0x09 'S' 'i' 'm' 'p' 'l' 'e'

至此，廣播包格式詳細(xì)大家已經(jīng)完全清楚了。

1.2 藍(lán)牙廣播 和 掃描響應(yīng)

為什么講藍(lán)牙廣播要提到掃描響應(yīng)？

掃描響應(yīng)的報文格式和藍(lán)牙廣播一摸一樣。

我們先來說一下什么是掃描響應(yīng)，廣播是我們從機(jī)主動發(fā)出的報文，掃描響應(yīng)是從機(jī)在收到主機(jī)掃描請求后 回復(fù)的響應(yīng)報文（前提是它支持回復(fù)掃描響應(yīng)），如下圖：

掃描響應(yīng)有什么作用？

我們知道藍(lán)牙廣播包只有 31 個字節(jié)可以用戶自定義，如果我們廣播數(shù)據(jù)放不下，想放更多的數(shù)據(jù)，我們可以寫在 掃描響應(yīng)里面，在手機(jī)掃描過程中，會一并作為廣播包加入解析（下面會有示例說明）。

二、 代碼示例

我們完成了理論說明，我們來看看在實際工程中廣播包的體現(xiàn)，本次測試說明使用的是沁恒微藍(lán)牙芯片 CH585 ，示例為官方的從機(jī)示例 Peripheral 。

2.1 示例效果

我們只要關(guān)注的點就是在工程中peripheral.c 文件里面，有兩個數(shù)組就是廣播包的定義其中 scanRspData[] 對應(yīng)掃描響應(yīng)，advertData[] 對應(yīng)廣播包，我們燒錄好程序觀察一下現(xiàn)象：

通過圖片大家應(yīng)該可以很直觀的理解，然后配合上文說明的 「AD Structure」 格式解析，應(yīng)該都能明白怎么回事。

大家完全可以根據(jù)我們上文的說明，設(shè)置成自己想要的廣播數(shù)據(jù)。

2.2 設(shè)置廣播類型

這里需要額外說明的是，上面說到過不是所有的廣播包都支持掃描響應(yīng)，在 CH58x 的 EVT 是使用：

GAPRole_SetParameter(GAPROLE_ADV_EVENT_TYPE, 1, &advEventType);

來設(shè)置廣播類型的，但是示例中的從機(jī)初始化環(huán)節(jié)并沒有設(shè)置GAPROLE_ADV_EVENT_TYPE 這個類型的操作，那是因為默認(rèn)就是GAP_ADTYPE_ADV_IND類型：

我們可以繼續(xù)查看一下，官方有哪些類型的定義：

上個表格就一目了然了：

說明：沁恒微代碼把「高占空比」和「低占空比」拆成兩條宏，其實都屬于同一個 PDU 類型 ADV_DIRECT_IND 。

所以我們想設(shè)置廣播類型，只要在初始化的時候，加上這兩句代碼：

uint8_t  advEventType = GAP_ADTYPE_ADV_IND;
GAPRole_SetParameter(GAPROLE_ADV_EVENT_TYPE, 1, &advEventType);

2.3 中文廣播包

設(shè)置中文廣播包，首先要知道中文的編碼，藍(lán)牙名稱采用的編碼格式位 UTF-8 格式的，一個漢字 UTF-8 編碼格式占用 3 個字節(jié)。 我們實際生產(chǎn)編碼的時候一般都需要使用工具。

我們測試的時候可以通過這個在線工具生成，網(wǎng)址如下：

https://www.jyshare.com/front-end/695/

然后我們把這個編碼按照格式寫入廣播包定義數(shù)組里面，效果如下：

三、 BLE分析儀抓包

廣播報文不復(fù)雜，我們這里也是簡單上一下藍(lán)牙分析儀抓包的效果：

通過 Adv PDU Type 我們就可以看出空中包的類型，簡單解釋一下：

SCAN_REQ

• 主設(shè)備的掃描請求，主設(shè)備發(fā)送SCAN_REQ請求從機(jī)響應(yīng)，用于獲取從設(shè)備信息（包括設(shè)備名字，或者服務(wù)UUID，及其它如廠家特定格式的信息等）

SCAN_RSP

• 從設(shè)備的響應(yīng)，作為廣播包的補充，從設(shè)備可以給主設(shè)備更多的廣播數(shù)據(jù)，依賴此包補充數(shù)據(jù)，比如說，有些設(shè)備在廣播包里面沒有設(shè)備名字，這個時候就可以把設(shè)備名字放在這個包里面發(fā)給主設(shè)備。

ADV_NONCONN_IND

• 不可連接廣播包
• 用于設(shè)備廣播自身信息（如名稱、服務(wù)類型等），
  數(shù)據(jù)格式：包含廣播地址（AdvA）和廣播數(shù)據(jù)（AdvData），其中AdvData由多個AD結(jié)構(gòu)組成，每個AD結(jié)構(gòu)包含長度、類型和數(shù)據(jù)字段。
  典型設(shè)備：iBeacon等需要周期廣播但無需連接的設(shè)備。

ADC_IND

• 通用廣播包，可被任何設(shè)備接收并響應(yīng)。
  數(shù)據(jù)格式：與 ADV_NONCONN_IND 類似，但類型標(biāo)識符不同（報文類型低4位為0000，此處的類型就是在第一張圖中粉色部分 Header 中的 4 Bit TYPE 類型）。

AD_EXT_IND

• 這個本不是我們本文討論的范圍，但是上圖抓包工具有了，就補充說明一下，AD_EXT_IND 是 BLE5 擴(kuò)展廣播的“索引包”，BLE5 Extended Advertising（輔助廣播）的“頭包”，只在 primary advertising PHY 上發(fā)送，用來告訴掃描者“后面還有一份更長的 payload 在 auxiliary packet 上”。
  BLE5 要發(fā) >31 B 的廣播或想用 2 M / coded PHY 時，鏈路層會先把 Header 做成 AD_EXT_IND，發(fā)到 37/38/39 信道上（1 M PHY）。

3.1 廣播報文類型

上面既然說到了 Adv PDU Type ，那就補充說明一下，這部分的表示是在協(xié)議種的這個部分：

上個表格：

抓包工具怎么看：

結(jié)語

本文我們說明了一下藍(lán)牙廣播包的報文格式，以及使用沁恒微藍(lán)牙芯片如何設(shè)置廣播包，通過本文學(xué)習(xí)，相信大家能夠應(yīng)對所有廣播數(shù)據(jù)修改的問題 。

在藍(lán)牙設(shè)備連接上以后，連接過程數(shù)據(jù)交互也會有自己的協(xié)議包，這個在后期有機(jī)會也會寫一篇文中給大家分析。

好了，本文就到這里。謝謝大家！