可穿戴BLE追踪器实战：从nRF52840选型到低功耗与OTA升级全记录

前阵子整理项目资料翻到我们去年做的那个可穿戴追踪器。当初选型的时候大家第一反应都是 Nordic 的 BLE SoC——当时在 nRF52832、nRF52840 以及刚出来不久的 nRF5340 之间摇摆了很久最后定的方案不一定是最惊艳的但绝对是最省心的。这篇文章就把当时从选型、硬件设计、功耗核算、软件调试到 DFU 升级联调这套完整流程梳理一遍很多坑都是官方文档里看不到的希望能给正在做同类项目的朋友一些参考。这个项目本身不复杂本质上就是一个带 BLE 连接功能的低功耗追踪器体积大概一枚硬币大小要塞进电池、传感器、天线、充电管理还要能在微信小程序上做 OTA 固件升级。核心需求非常直接BLE 低功耗连接、室内外定位辅助加速度计和磁力计、至少三周续航、稳定的空中升级。听起来简单但真正落地的时候从射频调试到电量估算再到连接参数调优每一步都有讲究。1. 选型复盘为什么最终选了 Nordic 的 BLE SoC1.1 需求倒推方案先把约束条件列清楚做可穿戴设备选型不能上来就比芯片参数得先看清楚产品的硬约束。我们这个追踪器有几个绕不开的点第一是电池很小预算只有 180mAh 左右锂电池必须找平均功耗能压到几十微安级别的 SoC第二是体积有限能留给天线的净空区很小射频稳定性和抗失谐能力很重要第三是主控要承担传感器采集、数据缓存、电量管理、BLE 协议栈等多重任务不能只当个射频 modem 用。在这些约束下容易想到的两条路线是独立 MCU 外部 BLE 芯片或者单颗 BLE SoC。独立 MCU 方案在调试上更灵活比如用一颗超低功耗 MCU 处理传感器再通过串口或 SPI 和 BLE 芯片通信但代价是多一颗物料、多一组晶振和匹配电路占用 PCB 面积不说两片 IC 之间的通信协议还得自己维护。我们评估下来单 SoC 方案更符合体积和成本要求于是把候选范围缩到了 Nordic nRF52 系列、TI CC2640R2/CC2652、STM32WB55 这几颗料上。1.2 竞品对比协议栈成熟度比峰值算力更重要这几款芯片从纸面性能看都满足需求真正拉开差距的是协议栈稳定性和功耗控制的粒粒度。STM32WB55 的双核架构很有吸引力实际用下来协议栈的资料和工具链相对没那么顺手TI 的 CC2652 射频性能不错但生态在国内的支持力度明显不如之前很多问题要自己去论坛翻。最后我们在 Nordic nRF52832 和 nRF52840 之间二选一。坦白讲单论追踪器这种场景nRF52832 的 512KB Flash 和 64KB RAM 已经够用了后来选 nRF52840 主要是给后期算法升级留了余地——它带 USB 控制器和更多 Flash/RAM做调试和日志导出非常方便。如果你做的是极简功能的追踪器nRF52832 完全够用没必要为冗余的硬件资源多花钱。下面这张对比表可以帮你快速判断对比维度nRF52832nRF52840nRF5340ESP32-S3内核Cortex-M4F 64MHzCortex-M4F 64MHz双核 M33 128/64MHz双核 LX7 240MHzFlash / RAM512KB / 64KB1MB / 256KB1MB / 512KBFlash 外置 / 512KBBLE 版本5.05.05.3 双核WiFi BLE 5.0待机电流约 1.9uA约 1.5uA约 1.5uA20uA 以上典型连接平均电流约 10uA 100ms约 10uA 100ms约 10uA 100ms明显偏高配套工具链成熟成熟持续完善丰富但偏 WiFi当时没有选 ESP32-S3核心原因不是性能而是功耗模型完全不同。ESP32-S3 定位是 WiFi BLE 融合WiFi 协议栈和射频前端决定了它的待机电流和连接平均电流都比纯 BLE SoC 高一个量级做插电类智能家居没问题做一颗电池只有 180mAh 的追踪器就很吃力了。选 Nordic 还有一个很现实的原因低功耗 BLE 场景的配套资料、应用笔记和社区案例非常丰富开发过程中遇到问题基本都能搜到答案这对项目进度来说本身就是一种隐性成本节省。1.3 单 SoC 方案的结构设计起点确定主控之后整个硬件结构就清晰了nRF52840 负责协议栈和主逻辑板上挂加速度计/磁力计组合传感器、电池电量采集电路、充电管理、RGB 状态灯、按键、天线匹配网络。对比独立 MCU BLE 芯片方案这个结构少了一组通信接口和电源域也让硬件工程师少操很多心。更重要的是软硬件可以完全围绕 SoC 的电源域来做——RTC 唤醒、GPIO 中断唤醒、传感器中断唤醒都走同一个电源管理框架软件侧的功耗优化更集中。2. 硬件设计与功耗预算数字怎么算电流怎么省2.1 先建功耗模型再选电池和连接参数硬件设计最忌讳拍脑袋决定电池容量。我们当时先用 Nordic 官方的功耗估算工具在线 Power Profiler把整机电流模型搭出来再反推电池容量。追踪器刚开机时会处于可发现广播状态之后大部分时间要么静默待机、要么保持低延迟连接。为了让续航目标可验证我把整个系统拆成几个工作模式分别测平均电流纯待机RTC 开启、传感器关闭约 2uA加速度计 10Hz 采样 简单计步算法约 15uABLE 广播间隔 100ms纯可发现包约 12uABLE 连接连接间隔 50msslave latency 4短数据包约 20uA连接并传输 40 字节数据间隔 30ms无 latency约 45uA按照一天 24 小时、其中有 2 小时连接、0.5 小时广播、其余时间处于加速计采样模式来算2mAh 的连接耗电 0.2mAh 的广播耗电 剩余时间的采样耗电约 0.6mAh一天总耗电约 1mAh。180mAh 的电池理论续航能到四个月以上。但这是理想值实际上电池自放电、极端温度、异常连接重试都会吃掉额外电流所以我们把目标设计值放宽到了三周以上这样即使环境和用户行为不理想也能兜住。如果你做的是更小的追踪器只有 80mAh 电池同样把连接间隔从 30ms 放宽到 100ms、slave latency 调到 9平均电流能省一半以上。2.2 DCDC 和 LDO 的取舍以及电源纹波对 ADC 采样的影响nRF52840 内部集成了 DCDC 和 LDO 两种供电模式默认不带负载时用 LDO但真正低功耗一定要使能 DCDC 模式否则射频收发那一下的电流功耗差别很大。硬件上 DCDC 需要一个外部电感通常在 10uH 左右选型时注意电感的内阻和额定电流内阻过大会直接吃掉省下来的效率。DCDC 开启后整机连接平均电流能降低 30% 到 40%这个收益非常可观代价只是多一颗电感成本。电源纹波是另一个容易忽略的点。BLE 的 TX 事件瞬间电流能飙到 10mA 以上电池内阻加上 PCB 走线电阻会让 VBAT 出现几十毫伏到上百毫伏的跌落。当时我们发现电池电量百分比在界面上跳来跳去排查到最后不是电量计的问题而是 ADC 采样刚好撞上了射频发射事件。解决方式有两层硬件上在 VBAT 附近加 100nF 和 10uF 陶瓷电容靠近 SoC 电源引脚再用磁珠隔离软件上把电池电压采样放到连接事件的空闲 slot 里避免在射频收发瞬间采样同时做多次采样取中值。这个组合改完之后电量显示稳定了很多。2.3 天线匹配、GPIO 漏电与传感器选型的实操细节天线部分是这个项目最折腾的地方。硬币大小的体积意味着 PCB 天线净空区非常小我们一开始用的 F 型 PCB 天线在裸板上反射损耗能做到 -15dB 左右但装进外壳、旁边放上电池和马达之后天线附近的金属件和塑料外壳的介电常数会让中心频率偏移实际增益掉了差不多 3dB。后来通过网络分析仪反复调 π 型匹配网络把谐振点拉回 2.44GHz整机灵敏度才恢复正常。这个经验我后来做任何带金属外壳的产品都会提前考虑到天线调试一定要带着最终外壳一起测不要等结构定死了再回来改匹配。GPIO 漏电问题也很典型。我们有一版样机测试待机电流从 2uA 涨到了 20uA排查了整整一天最后发现是板子上一个悬空 GPIO 在恶劣环境下出现漏电软件里把它配置成高阻后恢复正常。所以硬件设计阶段就要求所有不用的 GPIO 必须有确定的状态要么固定输出低、要么输入上拉/下拉绝对不能悬空。传感器选型上加速度计优先选带中断唤醒功能的比如 LIS2DH12 这类这样 MCU 可以在传感器数据准备好之前一直睡在 RTC 模式系统总功耗才能压得下来。3. 软件栈与 BLE 连接参数调优从 SoftDevice 到 Zephyr3.1 技术栈选型nRF5 SDK 还是 nRF Connect SDK软件栈的选择直接影响后面大半年开发体验。当时我们项目组比较熟悉 nRF5 SDK SoftDevice S140配合 Segger Embedded Studio 在裸机上开发BLE 协议栈被编译成静态库API 稳定出问题少。这套组合在工业界存量很大资料非常丰富尤其是老工程师留下的代码基本都不用改就能跑。但如果你是刚开始接触 Nordic 的新项目我建议直接上 nRF Connect SDKNCS Zephyr 系统。原因很现实Nordic 已经停止给 nRF5 SDK 添加新模块像 PAwRPeriodic Advertising with Responses、动态多协议等新功能只会出现在 NCS 上。Zephyr 整个协议栈开源遇到奇怪问题可以直接读源码定位这在 SoftDevice 黑盒模式下是做不到的。当然 Zephyr 有学习曲线刚上手时 Kconfig 配置和设备树devicetree这套体系会让很多人不适应但从长期维护和产品迭代角度看这笔学习投入值得。3.2 连接参数矩阵怎么在延迟和功耗之间做平衡BLE 连接参数是追踪器功耗的遥控器这组参数几乎决定了整机平均电流的大头。核心变量有三个连接间隔connection interval、从机延迟slave latency和超时时间supervision timeout。连接间隔越小双向通信延迟越低但射频和 MCU 被唤醒的次数越多功耗越高。从机延迟允许从设备主动跳过一定数量的连接事件只有有数据要发时才唤醒这是省电的大杀器。我们随手测过一组对比数据放在一起看会比较直观连接间隔从机延迟平均电流双向数据延迟30ms0约 45uA约 15ms50ms4约 20uA约 125ms100ms9约 12uA约 500ms追踪器上报位置、步数这类数据500ms 延迟完全无感所以我们最终选了 100ms 间隔加 9 个从机延迟的组合。不过在连接参数协商时要特别注意主设备有权拒绝从设备请求的参数手机厂商往往有自己的偏好名单比如 iOS 倾向于 30ms 左右的连接间隔如果两个参数表差太远连接会退回到主设备支持的默认参数。项目里做了一版参数协商策略首次连接时先满足手机的默认节奏完成数据同步连接稳定后再调用连接参数更新请求切到低功耗档。3.3 广播、iBeacon 与 PAwR按场景选对广播模式不做连接的时候设备靠广播让别人发现。广播间隔越大越省电但被发现的速度变慢、丢包概率增加。我们在追踪器里用了一个策略静止状态下广播间隔拉到 200ms降低功耗检测到设备在关机升级模式或被主动寻找时把广播间隔调到 50ms保证手机能快速发现。广播包里同时塞进了设备类型、序号和一小段状态信息这样手机在没连接前就能显示设备的基本状态也减少了一些无意义的连接握手。室内定位场景还考虑过 iBeacon 和 PAwR。iBeacon 本质上是苹果定义的广播包格式手机扫描到后根据 RSSI 估算距离适合室内寻物但它的工作距离短精度也谈不上高。PAwR 则是一种更新的周期性广播响应机制一个广播同步网络理论上能带几千个节点非常适合仓储、零售场景的海量标签轮询但这套机制目前对 SoC 和协议栈版本有要求需要提前确认芯片支持情况。我们产品定位是个人追踪PAwR 暂时用不上但如果你的项目面对的是几十个甚至更多设备同时在线PAwR 是个值得提前研究的方向。4. DFU 固件升级与跨平台联调从手机 App 到小程序4.1 Secure DFU 升级流程以及为什么必须做双 Bank可穿戴设备出货之后不可能拆壳刷固件OTA DFU 是刚需。Nordic 的 Secure DFU 流程分为 Bootloader Application 两个区域固件下载完成后不是直接覆盖当前应用而是先写进临时银行bank校验通过后由 Bootloader 在下次启动时完成切换。这个双 Bank 机制很关键能在升级中途断电或数据包损坏时保护旧版本还能启动不至于变砖。我们当时用 nRF5 SDK 的 secure_bootloader 工程做了一版后来切到 Zephyr 后用的 MCUboot两者思路相通都是“先备份、再校验、后切换”。4.2 微信小程序实现 DFU 的完整路径手机端升级不能只靠 nRF Connect 工具最终用户要在自己的小程序里完成升级。小程序做 BLE 有个天然限制部分系统或设备不支持协商到高 MTU所以大量固件传输必须按照 20 字节一包的 ATT 数据来分包。流程也很固定先扫描并连接到 DFU Service开启 Notify 接收回复然后按照协议格式逐包发送固件数据每发一个包等一个确认超时重发全部发送完成后等待设备复位并重新广播。实际做下来最难的不是协议本身而是各种边角情况比如小程序切后台导致连接中断、用户升级到一半锁屏让蓝牙停摆、以及分包序号和校验错误的处理。我们当时踩了一个印象很深的坑小程序里用 write 无响应写长数据的时候如果不做发送窗口控制一瞬间把大量包塞进蓝牙缓冲区系统会直接断链。解决方式很简单——维护一个发送队列每发 5 包就停下来等对方确认确认到了再继续下一批。看起来有点原始但在低 MTU 的约束下反而是最稳的。4.3 C# WinForms 和 Android 侧联调选对库能少走很多弯路调试 BLE 不只有手机 App 这一条路。我们有个测试治具是 WinForms 程序跑在 Windows 上用的 .NET Framework 4.7.2。这个框架下做 BLE 通信可选的库不多我实测过两条路一是 Windows.Devices.Bluetooth.GenericAttributeProfile也就是 UWP 的 API在 WinForms 里引用 Windows 10 相关程序集也能调但需要处理一些异步和权限问题二是 InTheHand.Net.Bluetooth 这类第三方库封装度更高接入快很多。如果只做简单读数据直接用 nRF Connect Desktop 就行不推荐自研工具。Android 工程那边也要提前踩坑。BLE 扫描在 Android 6 到 12 上的行为差异很大比如低版本用 startLeScan 容易丢设备高版本又开始限制扫描回调频率。我们最终统一用蓝牙适配器 startScan 带 ScanFilter 的方式并且加了一套扫描去重和超时重启扫描的逻辑。连接状态回调会多次以不同状态触发代码里必须对“已连接-断线-重连”状态机做稳定处理否则设备掉线后很难自动回连。5. 实测问题与排查记录那些只会在现场出现的坑5.1 隔一堵墙就掉线最后是天线失谐的问题第一批工程样机出来后测试同事反馈一个现象把追踪器塞进外壳隔一堵墙连接就开始不稳定甚至走到三米外就掉线。但裸板测试时信号是好的这就非常有迷惑性。我们刚开始怀疑是发射功率被软件配置低了查了一圈发现配置没问题然后把目光转向天线匹配——用网络分析仪实测外壳整机状态下的反射损耗S11 在 2.44GHz 附近只有 -6dB频偏非常明显。原因就是外壳内部的电池和塑胶结构改变了天线附近等效介电常数调试 π 型匹配网络后 S11 压到了 -12dB 以下问题彻底解决。这个案例再次验证了那句话天线调试必须以最终整机形态为准裸板数据只能作参考。5.2 待机电流一夜之间涨了十倍有段时间样品夜测待机电流从 2uA 涨到了 20uA 左右直接把整机续航预估砍掉一大截。排查思路是从外设逐个断开入手先看传感器有没有进 low-power mode再看 GPIO 有没有悬空或者配置成输入但没有上下拉接着查 DCDC 电感是否有啸叫和漏电。最后定位到加速度计没有正确进入 sleep 模式一直以 full-power 状态运行。这个问题很隐蔽因为软件上看起来调用了低功耗接口但初始化时序里有一个寄存器被后面的配置覆盖导致传感器一直没睡。解决办法是加一个启动后的电流检查用例——上电跑五分钟持续采样电流出现超过阈值的立刻报警这样后面每次改动驱动都能快速回归。5.3 电源跌落导致的射频误码和复位另一个让人头疼的问题是设备在连接状态下偶尔重启概率不高但一台设备跑一整天能触发一两次。抓日志发现复位原因是看门狗触发但看门狗超时的源头是射频 TX 瞬间电源跌落导致 RF 收发异常卡在某个等待事件里太久。硬件上是电池内阻在一些电量低的电池上偏大瞬间大电流造成复位软件上没有针对卡死的链路做保护。解决方案是双管齐下硬件上在 VBAT 和 VDD 之间增加储能电容和磁珠隔离软件上在 BLE 事件处理里加了超时看门狗喂狗逻辑避免协议栈长时间卡死。排这个故障的过程也让我意识到低功耗设计不只是软件调参数电源完整性是很容易被忽略的底层基础。5.4 电池电量 SOC 越算越不准用 EKF 校正后终于稳定项目初期电池电量直接用电压查表估算刚充满时显示 100%放一会儿掉到 90%过一会又能跳回 95%用户感知很不好。后来引入 EKF 做容量校正模型里把电压、电流、温度都纳入了状态估计用扩展卡尔曼滤波对 SOC 做滤波比单纯 OCV 查表稳定很多。EKF 的实现并不复杂但有一个工程细节非常重要状态协方差的初值要设置合理否则收敛很慢前几个循环算出来的 SOC 偏差巨大。另外电池在不同温度下可用容量差异很大必须加温度补偿系数否则冬天户外场景下电量会跳变。这一套弄完之后电量显示平滑了很多用户反馈也不再“电量焦虑”了。5.5 断连重连策略别让回连风暴拖垮整机设备断开后会自动重连这是追踪器的基本行为。但如果设计不好断连触发重连后手机和手环会陷入“重连-超时-断开-再重连”的死循环整机电流在半小时内能明显升高。我们做的重连策略借鉴了低功耗行业内常见的退避思路前三次重连间隔短一些比如 300ms、500ms、1s之后逐步拉长到 5s、10s如果长时间连不上就退到低功耗广播模式等待用户主动唤醒。同时 supervision timeout 也不能设得太长否则手机那边已经认为连接断开了设备这边还傻等导致更长的无响应窗口。这个项目从选型到量产前前后后跑了将近一年。回过头看Nordic 这套 BLE SoC 的方案选得值不是因为芯片本身有多惊艳而是它的生态让你在遇到问题时总能找到一条可参考的路径。可穿戴追踪器的技术难点其实不在任何一个单点而在于把功耗、射频、协议栈、用户体验全部捏在一起平衡。如果你正在做类似的东西我最后想分享的小技巧是从硬件原型阶段就把功耗测量和天线整机测试做成固定动作不要等软件全部写完再回头补否则你会发现自己要面对的是好几个同时爆炸的难题。