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