1. 項(xiàng)目背景與硬件方案選型思考1.1 寵物健康追蹤設(shè)備的真實(shí)需求拆解這幾年寵物經(jīng)濟(jì)越來越火身邊做智能硬件的朋友不少都在往寵物賽道看。寵物健康追蹤器這類設(shè)備核心要解決的問題其實(shí)很明確讓主人不用去寵物醫(yī)院就能日常掌握寵物的活動(dòng)量、心率、體溫、睡眠質(zhì)量這些關(guān)鍵健康指標(biāo)同時(shí)及時(shí)發(fā)現(xiàn)異常行為趨勢(shì)比如長(zhǎng)時(shí)間不活動(dòng)、心率持續(xù)偏高等。我當(dāng)時(shí)做這個(gè)項(xiàng)目最開始的時(shí)候需求清單列了這么幾條記錄寵物每天的活動(dòng)量區(qū)分走路、跑跳、休息狀態(tài)光學(xué)心率監(jiān)測(cè)能看靜息心率的變化趨勢(shì)體溫采集發(fā)熱能第一時(shí)間提醒續(xù)航至少兩周以上最好能做到一個(gè)月主人手機(jī)端實(shí)時(shí)查看數(shù)據(jù)歷史趨勢(shì)要能存能查支持后續(xù)固件升級(jí)不能每次改功能都讓用戶換設(shè)備這里最關(guān)鍵的一個(gè)約束就是功耗。寵物不會(huì)配合你充電設(shè)備掛在項(xiàng)圈上或者藏在胸背帶里主人大概率不會(huì)天天記得摘下來充電。所以整個(gè)方案選型的第一優(yōu)先級(jí)就是“低功耗”這三個(gè)字。1.2 為什么最終選了Nordic的BLE SoC市面上做低功耗無線方案的選擇其實(shí)不少我當(dāng)時(shí)對(duì)比了好幾個(gè)方向方案優(yōu)勢(shì)劣勢(shì)適不適合這個(gè)項(xiàng)目Nordic nRF52832/nRF52840協(xié)議棧成熟、文檔全、生態(tài)好、功耗極低價(jià)格偏高、Flash/RAM相比MCU方案不算大非常適合首選ESP32-S3WiFiBLE雙協(xié)議、算力強(qiáng)、內(nèi)存大功耗偏大、睡眠電流較高、啟動(dòng)邏輯復(fù)雜不適合純電池設(shè)備TI CC2640/CC2642射頻性能優(yōu)秀、功耗低工具鏈比較老、社區(qū)資料相對(duì)少可以做但是開發(fā)效率不如NordicST BlueNRG封裝小、價(jià)格低BLE協(xié)議棧問題排查難度大有經(jīng)驗(yàn)可以新手慎選Dialog DA14531成本極低Flash資源緊張不適合做復(fù)雜應(yīng)用適合極簡(jiǎn)產(chǎn)品不適合多功能追蹤器最終我選的是Nordic nRF52832。原因有這么幾個(gè)一個(gè)是BLE協(xié)議棧SoftDevice非常成熟而且和應(yīng)用程序代碼做了隔離應(yīng)用崩了不會(huì)把協(xié)議棧搞掛這在調(diào)試期極其重要。另一個(gè)是還有配套的DFU固件升級(jí)方案從Bootloader到手機(jī)端工具鏈都現(xiàn)成后期維護(hù)省了大力氣。還有一個(gè)是我實(shí)際測(cè)試下來nRF52832在System OFF模式下功耗不到1uASystem ON定時(shí)喚醒的運(yùn)行時(shí)平均電流也能控制在10uA級(jí)別這對(duì)一款需要長(zhǎng)時(shí)間續(xù)航的寵物穿戴設(shè)備來說是完全合格的。如果預(yù)算更充足、需要更多Flash和RAM來跑算法可以考慮nRF52840。它的Flash有1MBRAM 256KB還多了一些外設(shè)比如USB支持BLE 5.0的長(zhǎng)距離和高吞吐模式天線調(diào)好之后實(shí)際吞吐可以到1.3Mbps左右。但就寵物健康追蹤器來說nRF52832的512KB Flash 64KB RAM完全夠用沒有必要多花錢。1.3 關(guān)于SoC芯片啟動(dòng)流程和選型時(shí)的認(rèn)識(shí)做硬件的人可能對(duì)“SoC”這個(gè)詞不陌生但真正接觸射頻SoCRF SoC之后你會(huì)發(fā)現(xiàn)手機(jī)里的應(yīng)用處理器和這種BLE單芯片的啟動(dòng)邏輯完全是兩回事。BLE SoC內(nèi)部集成了射頻收發(fā)前端、基帶控制器、協(xié)議棧、應(yīng)用MCU、電源管理單元啟動(dòng)的時(shí)候有一套明確的順序上電或者復(fù)位后芯片內(nèi)部ROM里的固化引導(dǎo)代碼先執(zhí)行引導(dǎo)代碼加載SoftDevice協(xié)議棧鏡像到RAM協(xié)議棧初始化完成后再跳轉(zhuǎn)到應(yīng)用程序入口應(yīng)用程序調(diào)用協(xié)議棧提供的API完成BLE協(xié)議棧使能和廣播配置這個(gè)流程看起來簡(jiǎn)單但如果你直接操作寄存器、跳過協(xié)議棧的初始化很可能會(huì)發(fā)現(xiàn)藍(lán)牙根本起不來或者空中包亂飛。所以在nRF5 SDK上做開發(fā)不管用Keil、IAR還是GCC工程配置里都一定要保證SoftDevice在前、Application在后鏈接腳本的起始地址也要對(duì)齊協(xié)議棧占用的Flash區(qū)域。這個(gè)屬于新人最容易踩的坑。2. 硬件電路設(shè)計(jì)與電源系統(tǒng)的實(shí)際經(jīng)驗(yàn)2.1 供電拓?fù)渑cDC-DC的選擇nRF52832的工作電壓范圍是1.8V到3.6V典型用一顆鋰聚合物電池或者兩節(jié)紐扣電池供電。寵物追蹤器體積限制比較嚴(yán)格我沒法用太大的電池最終選的是90mAh的聚合物鋰電池整機(jī)目標(biāo)平均電流控制在100uA以內(nèi)這樣才能做到三周以上續(xù)航。供電鏈路我做了兩級(jí)。第一級(jí)是電池直接進(jìn)nRF52832的VDD但這里有一個(gè)非常重要的設(shè)計(jì)點(diǎn)nRF52系列內(nèi)部其實(shí)是有一個(gè)可選的DC-DC降壓模式的。開啟這個(gè)模式之后芯片內(nèi)部的高頻RF PA供電由DC-DC來提供發(fā)射電流能從原來的十幾毫安降到幾毫安效果非常明顯。具體做法是在VDD與DEC引腳之間接一個(gè)10uH的電感然后在SoftDevice初始化時(shí)調(diào)用sd_power_dcdc_mode_set(1)來使能。如果不加這個(gè)電感、不用DC-DC模式整機(jī)電流會(huì)明顯偏高。我們用實(shí)際測(cè)試數(shù)據(jù)算過一筆賬同樣每100ms廣播一次、連接間隔50ms的情況下純LDO模式平均電流大約250uA而開啟DC-DC后能降到170uA左右相當(dāng)于續(xù)航直接多了快一半。這一百多微安看著不多但放大到一個(gè)月的時(shí)間維度上差別就是“一周一充”和“兩周一充”的差別。2.2 射頻鏈路與天線匹配的調(diào)試心得做藍(lán)牙BLE設(shè)備射頻調(diào)試是整個(gè)硬件環(huán)節(jié)里最考驗(yàn)?zāi)托牡牟糠?。nRF52832的射頻輸出引腳ANT出來之后一般接一個(gè)π型匹配網(wǎng)絡(luò)再加天線。對(duì)于量產(chǎn)產(chǎn)品直接用芯片參考設(shè)計(jì)里的元件值是能起來的但諧振點(diǎn)和回波損耗不會(huì)剛好落在最優(yōu)位置需要用網(wǎng)絡(luò)分析儀實(shí)測(cè)后調(diào)整。我當(dāng)時(shí)做的是PCB天線。體積限制下PCB天線比如F型倒F天線比陶瓷天線更適合成本也低但設(shè)計(jì)上要注意凈空區(qū)天線底下不要鋪銅、周圍不要走無關(guān)的線、地平面的范圍要足夠。S11回波損耗我調(diào)到最好的時(shí)候能到-25dB以下一般量產(chǎn)只要保證在-10dB以下就夠用了。這里有一個(gè)特別容易被忽略的點(diǎn)天線匹配網(wǎng)絡(luò)的電容電感精度是NP0/C0G檔和繞線電感才會(huì)有穩(wěn)定的性能。如果用X5R陶瓷電容或者疊層電感溫漂和偏壓特性會(huì)讓匹配網(wǎng)絡(luò)在高低溫下飄移直接影響輻射功率和接收靈敏度。我踩過一次坑低溫測(cè)試時(shí)發(fā)現(xiàn)信號(hào)差了一截后來換掉匹配電容就好了。2.3 電源紋波對(duì)藍(lán)牙射頻和模擬采集的影響熱詞里有一條提到“rf soc器件gen3 adc電源紋波”這個(gè)點(diǎn)在我們這種射頻SoC加傳感器的方案里同樣非常關(guān)鍵。nRF52832內(nèi)部有12位SAR ADC可以用來采集電池電壓、NTC體溫、傳感器模擬輸出但ADC的參考電壓來自內(nèi)部VDD如果VDD上疊加了紋波采集結(jié)果會(huì)跟著一起跳。實(shí)測(cè)下來藍(lán)牙發(fā)射瞬間大概2ms-4ms的窗口電流會(huì)突然拉高電源軌上會(huì)出現(xiàn)幾十毫伏的紋波。這種瞬態(tài)紋波對(duì)數(shù)字電路沒影響但對(duì)模擬采集就是災(zāi)難。我的解決辦法是軟件上避開射頻活動(dòng)窗口在ADC采樣前加一個(gè)時(shí)間同步等BLE事件結(jié)束之后再過幾個(gè)毫秒才開始采樣硬件上加大VDD的旁路電容比如4.7uF陶瓷電容并聯(lián)0.1uF高頻電容同時(shí)走線上把模擬采樣地和射頻地做好單點(diǎn)隔離。如果你后續(xù)想做更準(zhǔn)確的電池電量百分比可以考慮用卡爾曼濾波EKF來處理電壓數(shù)據(jù)結(jié)合庫(kù)侖計(jì)做容量校正。這個(gè)在熱詞里也有體現(xiàn)但現(xiàn)實(shí)項(xiàng)目中電池SOC的估算第一版往往用OCV查表法就夠了不要一上來就上EKF加了狀態(tài)矩陣的調(diào)試成本會(huì)翻倍。3. BLE協(xié)議棧與固件開發(fā)的關(guān)鍵細(xì)節(jié)3.1 nRF5 SDK與nRF Connect SDK怎么選做Nordic開發(fā)面前有兩條技術(shù)路線老的nRF5 SDK基于SoftDevice協(xié)議棧比如S132和新的nRF Connect SDK基于Zephyr RTOS。這個(gè)選擇直接決定你后續(xù)的開發(fā)體驗(yàn)和可維護(hù)性。我的建議是如果項(xiàng)目要求快速出原型團(tuán)隊(duì)熟悉傳統(tǒng)嵌入式開發(fā)用nRF5 SDK更穩(wěn)。因?yàn)橘Y料多、示例全、踩坑記錄豐富SoftDevice的API設(shè)計(jì)也相對(duì)直觀。如果項(xiàng)目生命周期長(zhǎng)、后續(xù)可能要加Matter/Thread/藍(lán)牙Mesh或者需要用到較新芯片比如nRF54系列就選nRF Connect SDK。我做寵物追蹤器的時(shí)候用的是nRF5 SDK 17.1.0 S132協(xié)議棧支持CentralPeripheral但只用Peripheral。當(dāng)時(shí)Zephyr版本還沒有現(xiàn)在這么穩(wěn)定開發(fā)效率上nRF5 SDK完勝。但如果你現(xiàn)在才起步可以仔細(xì)評(píng)估一下nRF Connect SDKNordic現(xiàn)在新出的示例基本都是基于Zephyr了再往后nRF5 SDK的更新只會(huì)越來越少。3.2 GATT服務(wù)結(jié)構(gòu)的定義與數(shù)據(jù)格式設(shè)計(jì)寵物健康追蹤器里我定義了這么幾個(gè)服務(wù)和特征值服務(wù)UUID特征值說明數(shù)據(jù)類型0x180D心率測(cè)量標(biāo)準(zhǔn)心率服務(wù)Notify方式8bit BPM 可選RR間期0x180A設(shè)備信息硬件版本、固件版本、序列號(hào)字符串0x180F電池電量標(biāo)準(zhǔn)電池服務(wù)Notify低電量8bit 百分比自定義Service (UUID 0xFF01)活動(dòng)量數(shù)據(jù)自定義服務(wù)Notify方式每半小時(shí)累計(jì)步數(shù)/活動(dòng)強(qiáng)度自定義Service (UUID 0xFF01)體溫?cái)?shù)據(jù)自定義服務(wù)Notify方式16bit 溫度值0.01°C精度自定義Service (UUID 0xFF01)歷史數(shù)據(jù)讀取自定義服務(wù)Read方式分段返回歷史記錄自定義Service (UUID 0xFF01)設(shè)備控制自定義服務(wù)Write方式同步時(shí)間、配置上報(bào)間隔這里有一個(gè)經(jīng)驗(yàn)一律先考慮標(biāo)準(zhǔn)服務(wù)。心率、電量、設(shè)備信息這些iOS和Android系統(tǒng)層面有默認(rèn)的處理邏輯用標(biāo)準(zhǔn)UUID可以省掉很多App端適配工作。自定義部分才用私有UUID而且UUID不要拍腦袋編一個(gè)最好自己定義一個(gè)固定的Base UUID比如 6E400001-B5A3-F393-E0A9-E50E24DCCA9E 這種格式后3位遞增?；顒?dòng)量數(shù)據(jù)我用的是“每半小時(shí)一條記錄每一條是一個(gè)結(jié)構(gòu)化字節(jié)數(shù)組”。第0字節(jié)是狀態(tài)位表示當(dāng)前是走路/跑跳/休息第1-2字節(jié)是步數(shù)第3字節(jié)是活動(dòng)強(qiáng)度等級(jí)。這樣一包數(shù)據(jù)20字節(jié)能傳40條記錄App端收到后直接解析存數(shù)據(jù)庫(kù)。3.3 廣播參數(shù)、連接參數(shù)與低功耗計(jì)算BLE設(shè)備的功耗大頭有三個(gè)廣播、連接事件、傳感器采樣。廣播間隔和連接間隔這兩個(gè)參數(shù)在設(shè)計(jì)時(shí)就要算清楚。我當(dāng)時(shí)的廣播參數(shù)是廣播間隔 100ms廣播數(shù)據(jù)包含設(shè)備名稱8字節(jié) 廠商自定義數(shù)據(jù)6字節(jié)含設(shè)備ID和電池電量發(fā)射功率 0dBm。這個(gè)配置下廣播平均電流大約是 100uA 左右占空比不高手機(jī)端掃描也能穩(wěn)定搜到設(shè)備。連接之后的參數(shù)我設(shè)置了連接間隔 30ms15個(gè)1.25ms單位從機(jī)延遲Slave Latency8個(gè)事件監(jiān)督超時(shí) 5s。這樣連接狀態(tài)下從機(jī)只在每第9個(gè)連接事件里收發(fā)一次平均電流大幅下降。來算一下每個(gè)連接事件上從機(jī)要喚醒接收主機(jī)的包、然后回一個(gè)包這段射頻活動(dòng)時(shí)間大約 2ms按峰值電流 10mA開DC-DC時(shí)約 5mA算單個(gè)連接事件功耗約 20uA·ms0.02mAs。連接間隔30ms、從機(jī)延遲8意味每270ms才有一個(gè)事件平均電流 0.02mAs / 0.27s ≈ 74uA。再加上傳感器采樣的功耗整體可以控制在 120uA-150uA 以內(nèi)。這里有個(gè)容易忽略的坑從機(jī)延遲越大手機(jī)端收到數(shù)據(jù)的實(shí)時(shí)性就越差。如果主人打開App想立即刷新數(shù)據(jù)而設(shè)備還在8個(gè)連接事件后才應(yīng)答體感會(huì)很卡。所以我在代碼里實(shí)現(xiàn)了一個(gè)動(dòng)態(tài)調(diào)整邏輯默認(rèn)空閑時(shí)用長(zhǎng)連接間隔App發(fā)一個(gè)“開始同步”的命令后設(shè)備馬上把連接參數(shù)臨時(shí)切到短間隔比如 15ms同步完成后再切回來。用Nordic的sd_ble_gap_conn_param_update()可以很方便地做到。3.4 iBeacon、PAwR這些新概念該怎么看熱詞里出現(xiàn)了“ble的ibeacon”和“ble pawr”順便聊一下。iBeacon本質(zhì)上是BLE廣播數(shù)據(jù)里面的一種廠商自定義格式里面放了一個(gè)UUID、Major、Minor和發(fā)射功率。寵物追蹤器中如果要做室內(nèi)定位或者“離主人近/遠(yuǎn)”的判斷是可以參考iBeacon的思路的但我實(shí)測(cè)下來iBeacon在空曠室外能跑 50m 左右在室內(nèi)穿墻后就非常不穩(wěn)定做“防丟”提醒不如直接用連接RSSI閾值判斷來得實(shí)在。PAwRPeriodic Advertising with Responses是BLE 5.4里引入的本質(zhì)上是一種一對(duì)多的廣播通信機(jī)制可以讓一個(gè)主設(shè)備周期性地廣播數(shù)據(jù)多個(gè)從設(shè)備在指定的時(shí)隙回傳。這個(gè)技術(shù)做電子價(jià)簽這種海量設(shè)備場(chǎng)景非常適合但寵物健康追蹤這種“一個(gè)主人對(duì)一只寵物”的場(chǎng)景其實(shí)用不上了解一下即可。4. DFU固件升級(jí)的實(shí)現(xiàn)從Nordic底到手機(jī)端4.1 為什么DFU在寵物設(shè)備里是必備功能寵物健康追蹤器掛在寵物脖子上你不可能讓用戶拿線刷機(jī)。固件有Bug、算法要優(yōu)化、心率算法要調(diào)參都需要OTA升級(jí)。而且寵物醫(yī)院和主人不太可能跑到售后網(wǎng)點(diǎn)去刷機(jī)所以從出生開始設(shè)備就必須支持手機(jī)端無線升級(jí)。Nordic的DFUDevice Firmware Update思路是Bootloader SoftDevice Application三個(gè)鏡像分開存放升級(jí)的時(shí)候Bootloader負(fù)責(zé)接收新固件、校驗(yàn)、擦除和寫入。nRF52832的Flash是512KB我當(dāng)時(shí)做了分區(qū)區(qū)域起始地址大小內(nèi)容SoftDevice0x00000152KBS132協(xié)議棧Bootloader0x2600032KBDFU引導(dǎo)程序Application0x28000200KB應(yīng)用代碼用戶數(shù)據(jù)區(qū)之后剩余歷史數(shù)據(jù)存儲(chǔ)DFU時(shí)手機(jī)App把固件分包比如每包 20 字節(jié)發(fā)給設(shè)備設(shè)備寫入臨時(shí)區(qū)域校驗(yàn)CRC無誤后Bootloader再執(zhí)行替換和重啟。4.2 手機(jī)端DFU原生App、nRF Connect還是小程序Nordic官方提供了nRF Connect App內(nèi)置DFU功能研發(fā)階段足夠用。但給用戶交付的話必須把DFU能力集成到我們自己的App里。我自己實(shí)際做的過程中先是在自有App里集成了Nordic官方的Android/iOS DFU庫(kù)。Android端用io.runtime.mcumgr或者Nordic的Device Firmware Update庫(kù)都可以后者更貼近nRF5 SDK的協(xié)議實(shí)現(xiàn)。iOS端用NordicDFU這個(gè)Pod支持ZIP包升級(jí)模式里面包含Bootloader、SoftDevice、Application三個(gè)鏡像的合并包。這里有一個(gè)值得注意的點(diǎn)熱詞里有人問“只安裝shiny.bluetoothle可以實(shí)現(xiàn)BLE藍(lán)牙通信嗎”這個(gè)問題背后反映的是很多人對(duì)BLE庫(kù)的依賴關(guān)系不太清楚。如果你做的是 .NET 環(huán)境下的藍(lán)牙通信單純裝一個(gè)shiny.bluetoothle是不夠的它只是一層封裝底層還需要依賴對(duì)應(yīng)的平臺(tái)原生藍(lán)牙實(shí)現(xiàn)。在Windows上還需要底層藍(lán)牙棧驅(qū)動(dòng)支持?？缙脚_(tái)框架能幫你的只是API統(tǒng)一管不了系統(tǒng)底層。4.3 微信小程序?qū)崿F(xiàn)設(shè)備DFU的經(jīng)驗(yàn)設(shè)備量大了之后用戶未必愿意專門下載一個(gè)App。把DFU能力塞進(jìn)微信小程序理論上可以降低用戶升級(jí)門檻但實(shí)際動(dòng)手會(huì)發(fā)現(xiàn)不少問題。小程序藍(lán)牙API有幾個(gè)硬限制一次writeBLECharacteristicValue最多寫 20 字節(jié)MTU默認(rèn)23上傳一個(gè)大固件包你需要非常小心地分包發(fā)送、每包間隔處理。我當(dāng)時(shí)做了這樣的邏輯先讀取設(shè)備當(dāng)前的MTU值如果設(shè)備支持MTU協(xié)商比如nRF52上可以協(xié)商到 247就先把MTU提到 247這樣每一包可以寫到 244 字節(jié)分包數(shù)量直接少了十幾倍升級(jí)速度從原來的10分鐘縮短到2分鐘以內(nèi)。另外iOS上微信小程序的BLE實(shí)現(xiàn)比較“黑盒”。掃描、連接、緩存很多系統(tǒng)行為不可控尤其是舊版本微信對(duì)藍(lán)牙緩存處理不好經(jīng)常出現(xiàn)調(diào)試時(shí)改了廣播包、手機(jī)還是連不上。我這邊是讓用戶把藍(lán)牙關(guān)閉再打開才恢復(fù)的后來在微信官方社區(qū)查到這屬于iOS系統(tǒng)藍(lán)牙緩存問題解決方案是在掃描前加一段延遲再加上設(shè)備端廣播地址變化用sd_ble_gap_address_set隨機(jī)化地址能明顯減少緩存命中的概率。如果你在微信小程序里做DFU我強(qiáng)烈建議固件包先走網(wǎng)絡(luò)下載到手機(jī)本地再通過藍(lán)牙傳給設(shè)備不要在小程序代碼包里直接塞固件因?yàn)樾〕绦虬畜w積和更新時(shí)限的限制。另外升級(jí)過程中界面要顯示清晰進(jìn)度條并提示用戶“升級(jí)期間請(qǐng)不要遠(yuǎn)離設(shè)備”否則中途斷開設(shè)備變磚的風(fēng)險(xiǎn)會(huì)讓售后壓力很大。5. 手機(jī)App連接與數(shù)據(jù)解析的實(shí)操記錄5.1 Android BLE工程的核心步驟做一個(gè)Android BLE連接工程流程基本是固定的獲取藍(lán)牙權(quán)限 → 掃描設(shè)備 → 連接GATT Server → 協(xié)商MTU → 發(fā)現(xiàn)服務(wù) → 訂閱通知 → 讀寫特征值。權(quán)限這塊Android 12API 31之前要在Manifest里聲明BLUETOOTH、BLUETOOTH_ADMIN而且要ACCESS_FINE_LOCATION才能拿到掃描結(jié)果。Android 12之后引入了BLUETOOTH_SCAN、BLUETOOTH_CONNECT這兩個(gè)運(yùn)行時(shí)權(quán)限邏輯跟之前的定位權(quán)限又不一樣了。如果你的App targetSdkVersion比較高這兩套權(quán)限都要處理好否則會(huì)出現(xiàn)“明明藍(lán)牙開著卻掃不到設(shè)備”的經(jīng)典問題。代碼層面有一個(gè)常見的坑直接在UI線程調(diào)用startLeScan回調(diào)里做刷新。實(shí)際上掃描回調(diào)可能在幾十毫秒內(nèi)被頻繁觸發(fā)如果不做節(jié)流UI會(huì)卡成PPT。我一般是用一個(gè)HashMap緩存掃描到的設(shè)備覆蓋更新RSSI每500ms刷新一次列表。連接之后要記得調(diào)requestMtu(247)。很多第三方設(shè)備默認(rèn)MTU只有23字節(jié)如果你不協(xié)商讀寫大一點(diǎn)的特征值比如歷史數(shù)據(jù)就會(huì)一直報(bào)GATT_INVALID_ATTRIBUTE_LENGTH。5.2 C#環(huán)境做BLE通信的選項(xiàng)熱詞里問“winforms項(xiàng)目對(duì)于net framework4.7.2實(shí)現(xiàn)ble藍(lán)牙通信可以用的第三方庫(kù)”我實(shí)際做過類似的工程這里直接把經(jīng)驗(yàn)放出來。如果你在 .NET Framework 4.7.2 WinForms 環(huán)境里做BLE本質(zhì)上是有兩條路用Windows.Devices.Bluetooth命名空間。這個(gè)API是UWP時(shí)代的產(chǎn)物但在WinForms項(xiàng)目里也能用只要項(xiàng)目目標(biāo)平臺(tái)是Windows 10及以上并且引用了System.Runtime.WindowsRuntime相關(guān)程序集。優(yōu)點(diǎn)是系統(tǒng)原生、不用裝額外驅(qū)動(dòng)。缺點(diǎn)是API是異步模型需要大量async/awaitWinForms里的消息泵配合起來有時(shí)要小心死鎖。用第三方庫(kù)。比如InTheHand.Net.Bluetooth這個(gè)老牌庫(kù)它在Windows平臺(tái)上是基于系統(tǒng)藍(lán)牙協(xié)議棧封裝支持傳統(tǒng)藍(lán)牙和BLE用起來直觀。另外一個(gè)就是shiny.bluetoothle但正如前面說過的它依賴平臺(tái)原生藍(lán)牙棧而且對(duì).NET Framework的支持并不算好建議直接用 .NET 6/8 再考慮它。如果時(shí)間允許最省事的方案還是直接寫一個(gè)小的 UWP 后臺(tái)任務(wù)或者 WinRT 組件把BLE功能包成一個(gè)exe/serviceWinForms只負(fù)責(zé)UI展示這樣藍(lán)牙協(xié)議棧的復(fù)雜性被隔離出去。5.3 數(shù)據(jù)解析與可視化App端拿到設(shè)備Notify上來的數(shù)據(jù)后我做了兩層解析。第一層是通用協(xié)議解析把各個(gè)特征值按照約定好的字段格式拆開變成結(jié)構(gòu)化對(duì)象。第二層是業(yè)務(wù)邏輯處理比如心率數(shù)據(jù)要算滑動(dòng)平均、活動(dòng)量數(shù)據(jù)要按小時(shí)聚合、體溫?cái)?shù)據(jù)要記錄異常閾值?？梢暬矫嫖以诘谝话嬗玫那€是自己用Canvas畫的曲線比較簡(jiǎn)陋縮放和滑動(dòng)體驗(yàn)也不是很好。后來換成了 MPAndroidChart效果提升明顯。圖表核心指標(biāo)是24小時(shí)活動(dòng)量柱狀圖、心率趨勢(shì)折線圖、體溫異常標(biāo)注。如果你的項(xiàng)目需要更強(qiáng)的交互可以看看EChartsAndroid網(wǎng)頁版集成或者AAChartKitiOS。這里有個(gè)實(shí)用的建議BLE設(shè)備傳上來的數(shù)據(jù)一定要帶時(shí)間戳而且App端收到后要重新校準(zhǔn)時(shí)間。因?yàn)樵O(shè)備離線期間可能沒有時(shí)鐘校準(zhǔn)數(shù)據(jù)順序錯(cuò)亂會(huì)嚴(yán)重影響心率趨勢(shì)的準(zhǔn)確性。我當(dāng)時(shí)在設(shè)備端存了“累計(jì)秒數(shù) 本地時(shí)間修正值”App端收到后統(tǒng)一轉(zhuǎn)成“Unix時(shí)間戳”這樣即使斷連過、跨越時(shí)區(qū)數(shù)據(jù)還是能按時(shí)間正確排列。6. 常見問題排查與避坑實(shí)錄6.1 藍(lán)牙連不上或者掉線的排查順序我把做項(xiàng)目過程中遇到的典型問題整理成一個(gè)速查表有類似問題的可以按著這個(gè)順序排查現(xiàn)象可能原因解決方案手機(jī)掃描不到設(shè)備廣播間隔太長(zhǎng)或者設(shè)備處于System OFF狀態(tài)看電流判斷設(shè)備是否活著掃描時(shí)要靠近、延長(zhǎng)掃描時(shí)間掃描到了但連接不上上一臺(tái)手機(jī)還保持著連接設(shè)備端做多個(gè)Central管理或者設(shè)置連接白名單舊連接被踢掉后才能新連連接后馬上斷開監(jiān)督超時(shí)時(shí)間設(shè)置太短conn_sup_timeout不小于連接間隔 × (1 slave_latency) × 3連接一段時(shí)間后掉線手機(jī)藍(lán)牙棧自動(dòng)清理不活躍連接定期有數(shù)據(jù)交互比如每5秒更新一次RSSI解鎖手機(jī)時(shí)掉線iOS的后臺(tái)連接策略App端申請(qǐng)后臺(tái)藍(lán)牙模式設(shè)備端縮短監(jiān)督超時(shí)以快速重連印象最深刻的是有一次設(shè)備長(zhǎng)時(shí)間無故不在線測(cè)電流又發(fā)現(xiàn)睡眠模式正常。后來抓包才發(fā)現(xiàn)是室內(nèi)寵物走到金屬家具附近多徑衰弱導(dǎo)致丟包次數(shù)多了設(shè)備端重傳邏輯又在極短的監(jiān)督超時(shí)范圍內(nèi)沒來得及搶回連接。把監(jiān)督超時(shí)從4秒調(diào)到10秒后問題基本消失。但注意監(jiān)督超時(shí)不能太長(zhǎng)否則真的斷開后重連會(huì)很慢這是一個(gè)需要平衡的參數(shù)。6.2 功耗異常的幾個(gè)隱蔽原因如果實(shí)測(cè)整機(jī)電流比預(yù)想高很多時(shí)候不是射頻的問題而是這些小細(xì)節(jié)GPIO浮空。傳感器、LED、按鍵如果有GPIO懸空未定義方向漏電流可能到幾十甚至上百微安。所有不用的GPIO一定config成輸出低或者輸入上拉不能懸空。定時(shí)器沒有關(guān)閉。nRF52的RTC1/定時(shí)器在進(jìn)入System ON之前如果還在跑是不會(huì)睡眠的電流直接飆高。進(jìn)入System ON前要檢查所有外設(shè)是否停止。外部傳感器供電未切斷。比如光學(xué)心率傳感器MAX30102正常工作電流能到幾百微安甚至毫安級(jí)采樣完一定要把它電源關(guān)斷。SoftDevice沒有進(jìn)入低功耗模式。在System ON空閑時(shí)要調(diào)用sd_app_evt_wait()讓協(xié)議棧進(jìn)入省電狀態(tài)否則CPU一直在跑while(1)電流降不下來。功耗調(diào)試最直接的辦法是串一個(gè)10歐姆采樣電阻用示波器抓電阻兩端壓降波形識(shí)別各個(gè)階段的電流峰值和時(shí)間占比。抓幾次之后心里大概就有譜了。6.3 DFU升級(jí)失敗最典型的兩種場(chǎng)景第一種是升級(jí)包過大導(dǎo)致Flash寫滿。nRF52832的Application區(qū)只有200KB左右如果固件編譯出來超過這個(gè)尺寸Bootloader會(huì)直接拒絕。我這邊把優(yōu)化等級(jí)從 -O0 調(diào)到 -Os再裁剪掉不需要的日志輸出之后固件從 220KB 壓到 150KB才放下了。第二種是簽名校驗(yàn)失敗。Nordic的Secure DFU默認(rèn)是要求所有固件包帶上簽名密鑰的。如果手機(jī)端用了錯(cuò)誤的密鑰簽名設(shè)備端校驗(yàn)時(shí)就直接進(jìn)入錯(cuò)誤狀態(tài)表現(xiàn)就是“升級(jí)進(jìn)度走到了 99%然后設(shè)備重啟固件版本還是舊的”。檢查DFU包簽名和公鑰是不是匹配是調(diào)試這個(gè)問題的首選。另外提醒一句DFU過程中如果設(shè)備沒電比藍(lán)牙斷開的危害更大。設(shè)備進(jìn)入DFU后會(huì)關(guān)閉應(yīng)用邏輯只剩Bootloader在跑不充電的話電池耗盡就直接變磚。所以我量產(chǎn)前特意在DFU模式下把射頻發(fā)射功率調(diào)低到了-20dBm同時(shí)把Bootloader的廣播間隔拉到50ms費(fèi)電但容易被發(fā)現(xiàn)多少能縮短一些升級(jí)窗口的時(shí)間。量產(chǎn)版還在外包裝和App里都提示“升級(jí)前確保設(shè)備電量高于50%”。6.4 關(guān)于BLE連接策略的一些額外思考寵物健康追蹤器與主人的手機(jī)并不是一直保持著連接狀態(tài)。寵物在家跑來跑去手機(jī)藍(lán)牙經(jīng)常處于“斷連-重連”的循環(huán)里。這里我用的是白名單廣播連接策略設(shè)備一直廣播但只接受已配對(duì)手機(jī)的連接請(qǐng)求。這樣未配對(duì)手機(jī)即使掃到設(shè)備也無法連接安全性多了一層保障同時(shí)也避免無意中干擾到鄰居的藍(lán)牙設(shè)備。配對(duì)信息Bond信息存在Flash的系統(tǒng)區(qū)域DFU升級(jí)后這些信息是不會(huì)丟的但如果你在調(diào)試階段反復(fù)擦寫整片F(xiàn)lash就要重新配對(duì)。這也是一個(gè)“設(shè)備突然連不上”的排查方向。7. 寫在最后的幾個(gè)建議如果你正打算做類似的寵物健康追蹤設(shè)備我把個(gè)人覺得最有價(jià)值的幾個(gè)經(jīng)驗(yàn)總結(jié)成以下幾點(diǎn)不一定全面但都是真金白銀踩出來的第一方案評(píng)估階段一定要把“升級(jí)”當(dāng)成必備功能來設(shè)計(jì)不是可選功能。寵物設(shè)備掛在活物身上一旦部署出去你就沒法到現(xiàn)場(chǎng)改代碼了所有Bug修復(fù)和算法迭代都靠OTA撐著。硬件上預(yù)留Bootloader空間、軟件上定好固件分區(qū)方案要在第一天就想清楚后面再改分區(qū)是極其痛苦的。第二BLE的功耗優(yōu)化是一個(gè)系統(tǒng)工程硬件、協(xié)議棧、應(yīng)用、手機(jī)端四層都要配合。別指望光靠一個(gè)低功耗芯片就能做到長(zhǎng)續(xù)航。傳感器選型、采樣策略、發(fā)射功率、連接參數(shù)、手機(jī)App的連接行為都會(huì)影響最終續(xù)航數(shù)據(jù)。第三做BLE開發(fā)尤其要注意“手機(jī)差異性”。同樣的設(shè)備iPhone和不同品牌的Android手機(jī)連接穩(wěn)定性、MTU協(xié)商結(jié)果、掃描速度表現(xiàn)完全不一樣。不要把“在一臺(tái)手機(jī)上測(cè)試通過”當(dāng)作完成了測(cè)試。有條件的話找盡量多的手機(jī)做兼容性驗(yàn)證尤其是老款的Android機(jī)和不同版本的iOS系統(tǒng)。第四如果你只是做技術(shù)驗(yàn)證或者學(xué)習(xí)直接買一塊Nordic官方開發(fā)板nRF52840 DK或者nRF52832 DK先把官方示例跑通再一點(diǎn)一點(diǎn)改成自己的業(yè)務(wù)邏輯。不要一上來就自己畫板子項(xiàng)目里的Bug十有八九是軟硬件問題混在一起很難定位。寵物健康追蹤這個(gè)方向在我看來還遠(yuǎn)沒有到天花板心率算法的精度、活動(dòng)識(shí)別的智能程度、續(xù)航的進(jìn)一步拉長(zhǎng)這些都有很多可以做深的地方。希望這篇文章能給準(zhǔn)備入坑或者正在調(diào)試的朋友一些參考少走一些我走過的彎路。