最近看到 Nordic 的 BLE SoC 被用在了一款可穿戴追踪器上。这类消息在圈子里不算大新闻但每次出现都值得聊几句——因为可穿戴设备的选型逻辑和做手机、做智能家居完全是两回事。一颗芯片要在指甲盖大小的面积里同时搞定射频、功耗、算力和成本还要保证量产出货不出幺蛾子这里面的门道比大多数人想象的多。这篇内容就把这套逻辑拆开讲讲从为什么选 Nordic到 BLE 的低功耗机制再到 DFU 升级和手机端通信的实操坑全程用我做过的项目经验说话适合正在选型或者正在调 BLE 项目的硬件/嵌入式开发者参考。1. 项目背后的核心需求与SoC选型逻辑1.1 可穿戴追踪器到底需要什么样的芯片先别急着谈芯片型号先把需求捋清楚。可穿戴追踪器不管是手环、胸贴还是宠物追踪牌本质上是“长时间戴在身上、偶尔上报位置或状态”的设备。这就决定了它的核心诉求不是性能强而是长时间待得住。一颗电池只有几十到几百毫安时要撑几天甚至几周不出问题功耗就是第一指标。在此基础上还有几个硬性要求第一射频要稳天线环境很差——人体本身会吸收信号手环贴在手腕上手腕摆动时信号会被遮挡BLE 链路要有足够的余量第二必须支持低功耗模式下保持连接或者可被发现否则用户掏出手机打开 App 却连不上设备体验直接崩第三Flash 和 RAM 要够用因为现代可穿戴设备几乎都跑蓝牙协议栈加上自定义应用逻辑还要做 DFU 固件升级Flash 小了会非常痛苦。这几个要求叠加起来市面上能选的 SoC 其实就那么几家。而 Nordic 的 nRF5 系列和 nRF52 系列长期霸榜就是因为它们在“功耗-性能-外设”上找到了一个很实用的平衡点。具体来说它有一个非常出名的机制叫“事件驱动” “超低功耗空闲模式”再加上完整的协议栈独立于应用代码运行应用处理器可以在需要时才醒来干活剩下的时间芯片整体处于几微安的休眠状态。1.2 为什么是Nordic而不是其他家很多工程师习惯拿 Nordic 和 TI、Silicon Labs、Dialog 去比。老实说站在 2024 到 2025 年的时间点看各家方案差距没有十年前那么悬殊但 Nordic 在几个细节上依然有明显优势。一是协议栈的成熟度。nRF Connect SDK 和传统的 nRF5 SDK 并存Zephyr RTOS 的官方支持非常积极。BLE 协议栈SoftDevice是预编译好的二进制通过配置就可以启用各种角色稳定性经过大量量产验证。这一点在消费级可穿戴产品上非常关键因为蓝牙协议栈一旦在客户现场出问题排查成本极高。二是射频性能和链路预算。Nordic 的接收灵敏度常年做到 -96 dBm 左右BLE 1Mbps配合实际天线调好后空旷环境下的通信距离能达到 80 到 100 米室内穿一堵墙也没有太大压力。对可穿戴追踪器来说这意味着用户手机在口袋里、设备在手腕上收发数据基本不会断连。三是生态和工具链完善度。从 nRF Connect for Desktop 到 nRF Connect for Mobile再到命令行工具 nrfutilDFU、日志抓取、RTT 调试、在线功耗分析都有配套工具。说句实话如果项目从零开始做可穿戴用 Nordic 的方案大概率是最省心的路径。提示选型时不要只看 CPU 主频和 Flash 大小。一定要把协议栈占用的资源算进去。比如 nRF52832 的 512KB FlashSoftDevice 要占掉约 140KB真正留给应用的不到 372KB这直接影响你后续加不加 DFU、能不能放得下日志。2. 低功耗蓝牙BLE关键机制与实测2.1 广播、连接与功耗三者怎么平衡BLE 之所以叫“低功耗”蓝牙核心在于它的无线电不是一直开的。它通过“广播Advertising”“扫描Scanning”“连接Connected”三种状态切换把平均电流压到很低。对于可穿戴追踪器最典型的场景是设备平时不连接只周期性广播数据手机 App 打开后扫描到设备发起连接然后以连接间隔的方式持续通信。这里有一个新手常踩的坑把广播间隔设得太短。广播间隔越短发现越快但功耗直线上升。比如广播间隔设为 100 ms 时的平均电流可能在 100 µA 以上但如果设为 1 秒平均电流能压到 30 µA 以下。对于追踪器这种不需要秒级被发现的产品广播间隔完全可以设成 1 到 2 秒甚至更长。连接阶段的功耗主要看连接间隔Connection Interval和从机延迟Slave Latency。连接间隔越短通信实时性越高但主从双方都要频繁唤醒。合理的做法是把连接间隔设在 30 到 50 ms同时开启从机延迟让设备在不需要交互时跳过若干次连接事件。实测下来这种配置能让连接状态下的平均电流控制在 200 µA 到 500 µA 之间具体取决于数据包大小和应用唤醒频率。2.2 从nRF52832到nRF5340的选型差异Nordic 的 SoC 家族里nRF52832 是出货量最大的老将nRF52840 算是增强版支持更快的 2Mbps 速率、更多 I/O 和 USB。而 nRF5340 则换成了双 Cortex-M33 核一个高性能应用核一个低功耗网络核架构上更前卫。如果只是做一个简单的追踪器只跑 BLE 标签应用nRF52832 完全够用。它主频 64MHz Cortex-M4F512KB Flash 64KB RAM跑 BLE 一个简易传感器采集绰绰有余。但如果你需要并行处理音频、传感融合或者更复杂的算法nRF5340 的 128MHz 应用核和 1MB Flash 就更有底气。不过双核不是没有代价。nRF5340 的低功耗网络核单独跑 BLE 协议栈应用核随便你怎么折腾两个核之间通过 IPC 通信。这种架构带来更高的灵活性和稳定性但配置起来也更复杂。项目周期紧张的话用单核 nRF52 系列反而更稳。我做过一个宠物追踪器项目当时评估过 nRF5340最后因为团队对 Zephyr 不够熟还是选了 nRF52832开发效率高了很多功耗也完全满足要求。注意选择 nRF53 系列意味着你基本上要拥抱 Zephyr RTOS 和 NCSnRF Connect SDK老 nRF5 SDK 对它的支持有限。如果团队只会裸机开发上手 Zephyr 的曲线会比较陡需要额外评估工期。3. 固件升级DFU与配套工具链的实操坑3.1 小程序DFU实现的关键点现在很多可穿戴产品要求用手机小程序直接给设备升级固件也就是“小程序 DFU”。这个需求在热词里非常典型。微信小程序里做 BLE 通信本来就有不少限制比如 API 是基于 Web 蓝牙的封装无法直接访问底层 GATT 的 CCCD客户端特征配置描述符细节有些平台还不支持自定义 MTU 设置导致一次写入的数据长度受限。Nordic 的 DFU 服务基于 Secure DFU本质是一个 GATT Service往某个 Write 特征写入命令和数据包再监听另一个 Notify 特征接收响应。在小程序里实现时最稳妥的办法是先用手机 AppnRF Connect验证整条 DFU 流程拿到完整时序和包格式再在小程序里照着实现。几个容易踩的坑一是数据分包长度比如 MTU 只有默认的 23 字节你一次最多写 20 字节如果固件有 200KB就要分成 1 万多个包发送中间任何一包丢了或写入失败都得有重传机制二是写入速率限制Nordic DFU 底层要求每个包或每组包之间等待响应不能一口气不断写三是切 bootloader 模式和重连小程序 DFU 经常在固件启动引导加载后断开连接需要重新扫描并连接到新设备。3.2 常见DFU失败排查流程我整理了一个 DFU 排查清单遇到升级失败可以先按这个顺序过一遍确认设备处于 DFU 模式广播名称或服务 UUID 是否正确通常是在正常应用下通过命令软复位进入 bootloader。确认 MTU 协商成功。小程序里通过写入一个“空包”触发 MTU 协商如果协商不成功后续大数据包会直接失败。确认写入的数据满足 20 字节对齐。nRF Secure DFU 要求最后一个包如果不满足 20 字节要补零否则底层校验不过。确认响应超时时间。小程序里如果监听不到 Notify 响应大概率是写入太快导致设备没来得及回复这时需要加延时或者等待前一个 notify 到达后再写下一包。实测经验有一次升级到 90% 时总是失败最后发现是小程序在连续写入时没有加流控底层协议栈丢包后没有重发机制。后来把“写入-等响应-再写入”的流程改成了“写入一包收到响应后紧接着写下一包”问题立刻消失。4. 与手机端的通信实现要点4.1 Android BLE开发常见坑Android BLE 是口碑很差的领域因为碎片化严重。做过 Android BLE 工程的朋友应该都有感触同一套代码在 Pixel 上很稳在国产手机上就各种扫描不到、连接失败、自动断开。扫描不到设备先检查权限。Android 12 以上需要 BLUETOOTH_SCAN 和 BLUETOOTH_CONNECT 动态权限Android 11 及以下需要定位权限否则 scan 回调拿到的结果为空。很多人卡在这一步。连接上之后还有一个经典问题服务发现成功与否取决于设备是否在合理时间内响应。Nordic 设备响应很快但某些手机系统会先做 MTU 协商或者需要你主动 requestMtu如果忘记调默认 23 字节的 MTU 会导致长数据写不进去。对策是连接成功后先requestMtu(247)然后再discoverServices()注意 onMtuChanged 的时序。一个比较稳的处理方式连接成功 → onConnectionStateChange 为 CONNECTED → 调用 requestMtu → onMtuChanged 成功后 → 再 discoverServices → 操作特征。4.2 C#与BLE通信的第三方库选型社区里有个热词问“只安装 shiny.bluetoothle 可以实现 BLE 蓝牙通信吗” 这个问题很典型答案是可以但要看使用范围。Shiny.BluetoothLE 是一个基于 Xamarin/MAUI 的跨平台 BLE 库它封装了 Android 和 iOS 的 BLE 接口提供扫描、连接、读写特征等能力。如果是一个 WinForms 项目面向 .NET Framework 4.7.2再去用 Shiny.BluetoothLE 就不太合适因为那个库主要面向移动平台。Windows 上做 BLE 通信比较成熟的方案是直接用 Windows.Devices.Bluetooth 这个 UWP API.NET Framework 4.7.2 的 WinForms 项目可以通过引用Windows 10 SDK或者用 NuGet 包Microsoft.Windows.SDK.Contracts来调用。此外32feet.NET 这个库也支持 BLE但更偏传统蓝牙可以关注一下。具体操作步骤大概是先通过BluetoothLEDevice.FromIdAsync获取设备然后取得 GATT 服务、特征再通过WriteValueAsync和Characteristic.ValueChanged事件来收发数据。底层也是基于 WinRT 的异步模型写起来比 Android 简单不少。但注意Windows 对 BLE 的设备配对流程有特殊限制有些设备必须先从系统设置里配对然后才能被应用访问这是和 Android 很不一样的地方。5. 常见问题与项目实操心法5.1 从网络热词看开发者最真实的痛点这次搜索到的热词里有几个特别有意思。比如“ble pawr”这是 Nordic 最近在推的 Periodic Advertising with Responses是用来做“无线广播低功耗双向通信”的适合电子价签这类设备。还有“esp32-s3 wifi与ble协议”很多工程师纠结于 ESP32 的 Wi-Fi 和 BLE 同时工作时的 RF 切换问题。说实话ESP32-S3 的 BLE 性能在同价位里还行但深度睡眠电流和 Wi-Fi 共存时的稳定性跟 Nordic 相比还是有差距。所以如果你做的不是 Wi-Fi 加 BLE 的组合产品而是纯 BLE 追踪器Nordic 是更合适的。另外“ekf考虑容量校正soc”这个热词很有意思它把电池管理里的 SoCState of Charge和系统级 SoC 芯片搞混了。在可穿戴追踪器里电池电量的估算非常关键。很多方案直接读 ADC 电压然后查电压-电量表这种方法在低功耗设备上偏差极大因为电池在脉冲负载下的电压波动会误导判断。工程上一般用库仑计加开路电压校准复杂一点就是 EKF扩展卡尔曼滤波去估算。Nordic 的 SoC 内部有比较器、ADC 和 PPI 外设可以辅助实现简单的电量测量但精度有限想要准确还是得外挂专用电量计芯片比如 TI 的 BQ25120 或者 MAX77818。5.2 实测总结哪些坑可以提前避开第一坑天线阻抗匹配。很多硬件工程师画完 PCB 不去调试匹配网络直接用参考设计的天线走线。可穿戴设备外壳会显著改变天线谐振一定要留出 π 型匹配网络的位置。我做过一个手环最开始天线匹配只是参考值戴到手上 RSSI 掉到 -85 dBm连接频繁断开。后来在实验室调整了两个电容RSSI 恢复到 -60 dBm 左右断连问题彻底解决。第二坑晶振精度。BLE 对时钟精度要求很高尤其是连接状态下主从设备要用定时同步来校准接收窗口。如果使用内部 RC 振荡器做蓝牙时钟频率漂移大会导致连接窗口错开出现“刚连上就断开”的怪异现象。建议直接选用 32.768 kHz 外部晶振 16 MHz 外部晶振成本多不了几毛钱但能省很多调试时间。第三坑日志输出影响功耗。很多人调试时喜欢开串口日志或 RTT 日志但忘了在量产固件里关掉。RTT 在芯片不连接调试器时默认不工作影响不大但串口 UART 如果一直开着哪怕不发送数据也会多耗几十微安。低功耗设备里几十微安已经很多了。量产前一定要检查外设的电源域和时钟是否全部关闭。注意做低功耗产品从项目一开始就要习惯测量“工作电流曲线”。用 J-Link 加上 Nordic 的 PPKPower Profiler Kit或者使用带功耗分析的电流探针把整个工作周期的电流录下来。不要只看平均电流还要看尖峰电流和持续时间因为这些会影响电池有效容量尤其是用纽扣电池时内阻大电压跌落会造成系统复位。5.3 一个真实项目的能耗估算思路假设一个追踪器每 10 秒广播一次广播事件约 3 ms广播电流 6 mA广播间隔内休眠电流 2 µA。那么平均电流大约是6mA * 3ms / 10s 2uA 1.8uA 2uA 3.8µA一个月下来约 2.7 mAh。再加上每天连接几次同步数据每次连接 2 秒连接电流 8 mA每天 6 次平均电流约8mA * 12s / 86400s ≈ 1.1µA。总平均大概 5 µA100 mAh 的电池理论上能撑 20000 小时也就是两年多。这是非常理想的情况实际上要留足裕量一般按 70% 的效率算续航也能到一年以上。这也是为什么 BLE 追踪器能用纽扣电池工作很久的原因。6. 关于工具链和生态的一些补充6.1 务必会用Zephyr开发但别被它吓到nRF Connect SDK 从 2.x 以后完全基于 Zephyr RTOS 开发这对老工程师是个适应门槛对新人反而是个好事。Zephyr 的设备树Devicetree和线程化模型一开始比较抽象但一旦理解了“设备树就是硬件描述的配置文件Kconfig 就是编译开关”这两个概念大部分问题都能迎刃而解。举个实际例子在 nRF52832 上初始化一个 PWM 输出呼吸灯。在旧 SDK 里要手写一堆寄存器映射和定时器配置在 Zephyr 里只需在 devicetree 里定义一个 PWMs 节点然后直接pwm_set_dt(pwm_spec)就能输出波形。对于可穿戴产品里常见的振动马达、LED 灯、传感器供电控制这种抽象能省不少时间。不过要注意Zephyr 的电源管理不像裸机那么直观。如果你之前已经在 nRF5 SDK 上积攒了一套低功耗逻辑迁移到 Zephyr 时要重新设计特别是 System OFF、Retention RAM 等特性的用法不太一样。建议量产项目先做最小验证板把“休眠-唤醒-连接-广播”整个链路在 Zephyr 下跑通再扩展业务功能。6.2 云端与App联动设计中容易忽略的点可穿戴追踪器很少是纯本地设备大多数场景需要把数据同步到 App 再上云。这就留下一个问题本地时间戳和云端时间戳经常不一致。很多追踪器为了省电不配备实时时钟晶振每次连接手机后拿手机时间校准但一旦用户长时间不开 App设备本地计时的误差就会累积导致运动轨迹、步数统计的时间轴错位。我在一个儿童手环项目里就吃过这个亏。最初设计是定时和手机 App 同步时间但用户经常一两周不开一次 App最后云端的步数曲线看起来从早上 10 点才开始计算逻辑完全对不上。后来改为设备每次广播数据时附带一个“出厂以来运行毫秒数”的计数器由 App 根据收到包时的本地时间转换成绝对时间戳。这样即使设备时钟错了至少事件顺序不会乱再配合云端修正能够大幅减少时间错乱问题。另外要注意BLE 连接时的 MTU 大小直接决定一次数据传输效率。如果你要同步几千条缓存的历史数据一定要在连接后协商 MTU 到 247否则一条 20 字节的包一次传 1 个字节的协议头效率极低用户体验会很差。6.3 天线与外壳设计的协同讲一个被反复忽略的问题可穿戴追踪器的天线不能等结构定稿后再调试。最理想的流程是项目早期就用手板外壳装入 PCB用网络分析仪测试天线的 S11 参数和实际辐射效率。因为外壳材质尤其在腕带、金属件附近会造成频率偏移。如果发现中心频率偏离 BLE 频段2.4 GHz要通过匹配网络调整然后在整机状态下重测。还有一个隐藏坑人体电容效应。手表戴在手上手部对天线的近场影响显著导致天线方向图变形和效率下降。所以最终测试一定不能在桌面孤零零地测要模拟佩戴场景。相关标准可以借鉴 FCC/CE 的 SAR 测试思路虽然不需要真去实验室做辐射暴露评估但至少要了解结构件对天线的影响好提前留出调试空间。经验备料时多备几种容值的电容电感和几种不同材质的结构件手板方便现场调整匹配。别等结构件送样时只有一款那会非常被动。7. 最后再分享一个小技巧做可穿戴追踪器除了一线工程师关心的射频和功耗产品经理和测试同事往往会忽略一个点设备固件里的日志如何远程获取。量产设备没法接 J-Link那么问题出现时只能靠用户反馈。建议在固件里设计一个“调试模式隐藏服务”例如一个 GATT 特征允许支持工程版 App 读取设备内部日志缓冲区。这样在现场测试或用户投诉时不需要拆机手机连上去就能拉取日志效率高很多。这个特性在 Nordic 的 SoftDevice 架构下实现很容易用 NRF_FSTORAGE 保存历史日志再通过一个自定义 Service 暴露给手机端。注意正式版固件要默认关闭这个服务避免被恶意抓数据。我个人在实际操作中的体会是Nordic 的 BLE SoC 并不是每一项指标都最强但它把“开发效率、稳定性和生态完整性”这三样东西整合得最好。可穿戴追踪器这种产品拼的不是单一性能而是整个量产交付的综合成本。选它不一定是最亮眼的方案但大概率是最稳妥的选择。如果你正要开始做类似项目先把低功耗链路打通再一点点加功能别一上来就炫技。稳扎稳打产品才能早日落地。
最近看到 Nordic 的 BLE SoC 被用在了一款可穿戴追踪器上。这类消息在圈子里不算大新闻但每次出现都值得聊几句——因为可穿戴设备的选型逻辑和做手机、做智能家居完全是两回事。一颗芯片要在指甲盖大小的面积里同时搞定射频、功耗、算力和成本还要保证量产出货不出幺蛾子这里面的门道比大多数人想象的多。这篇内容就把这套逻辑拆开讲讲从为什么选 Nordic到 BLE 的低功耗机制再到 DFU 升级和手机端通信的实操坑全程用我做过的项目经验说话适合正在选型或者正在调 BLE 项目的硬件/嵌入式开发者参考。1. 项目背后的核心需求与SoC选型逻辑1.1 可穿戴追踪器到底需要什么样的芯片先别急着谈芯片型号先把需求捋清楚。可穿戴追踪器不管是手环、胸贴还是宠物追踪牌本质上是“长时间戴在身上、偶尔上报位置或状态”的设备。这就决定了它的核心诉求不是性能强而是长时间待得住。一颗电池只有几十到几百毫安时要撑几天甚至几周不出问题功耗就是第一指标。在此基础上还有几个硬性要求第一射频要稳天线环境很差——人体本身会吸收信号手环贴在手腕上手腕摆动时信号会被遮挡BLE 链路要有足够的余量第二必须支持低功耗模式下保持连接或者可被发现否则用户掏出手机打开 App 却连不上设备体验直接崩第三Flash 和 RAM 要够用因为现代可穿戴设备几乎都跑蓝牙协议栈加上自定义应用逻辑还要做 DFU 固件升级Flash 小了会非常痛苦。这几个要求叠加起来市面上能选的 SoC 其实就那么几家。而 Nordic 的 nRF5 系列和 nRF52 系列长期霸榜就是因为它们在“功耗-性能-外设”上找到了一个很实用的平衡点。具体来说它有一个非常出名的机制叫“事件驱动” “超低功耗空闲模式”再加上完整的协议栈独立于应用代码运行应用处理器可以在需要时才醒来干活剩下的时间芯片整体处于几微安的休眠状态。1.2 为什么是Nordic而不是其他家很多工程师习惯拿 Nordic 和 TI、Silicon Labs、Dialog 去比。老实说站在 2024 到 2025 年的时间点看各家方案差距没有十年前那么悬殊但 Nordic 在几个细节上依然有明显优势。一是协议栈的成熟度。nRF Connect SDK 和传统的 nRF5 SDK 并存Zephyr RTOS 的官方支持非常积极。BLE 协议栈SoftDevice是预编译好的二进制通过配置就可以启用各种角色稳定性经过大量量产验证。这一点在消费级可穿戴产品上非常关键因为蓝牙协议栈一旦在客户现场出问题排查成本极高。二是射频性能和链路预算。Nordic 的接收灵敏度常年做到 -96 dBm 左右BLE 1Mbps配合实际天线调好后空旷环境下的通信距离能达到 80 到 100 米室内穿一堵墙也没有太大压力。对可穿戴追踪器来说这意味着用户手机在口袋里、设备在手腕上收发数据基本不会断连。三是生态和工具链完善度。从 nRF Connect for Desktop 到 nRF Connect for Mobile再到命令行工具 nrfutilDFU、日志抓取、RTT 调试、在线功耗分析都有配套工具。说句实话如果项目从零开始做可穿戴用 Nordic 的方案大概率是最省心的路径。提示选型时不要只看 CPU 主频和 Flash 大小。一定要把协议栈占用的资源算进去。比如 nRF52832 的 512KB FlashSoftDevice 要占掉约 140KB真正留给应用的不到 372KB这直接影响你后续加不加 DFU、能不能放得下日志。2. 低功耗蓝牙BLE关键机制与实测2.1 广播、连接与功耗三者怎么平衡BLE 之所以叫“低功耗”蓝牙核心在于它的无线电不是一直开的。它通过“广播Advertising”“扫描Scanning”“连接Connected”三种状态切换把平均电流压到很低。对于可穿戴追踪器最典型的场景是设备平时不连接只周期性广播数据手机 App 打开后扫描到设备发起连接然后以连接间隔的方式持续通信。这里有一个新手常踩的坑把广播间隔设得太短。广播间隔越短发现越快但功耗直线上升。比如广播间隔设为 100 ms 时的平均电流可能在 100 µA 以上但如果设为 1 秒平均电流能压到 30 µA 以下。对于追踪器这种不需要秒级被发现的产品广播间隔完全可以设成 1 到 2 秒甚至更长。连接阶段的功耗主要看连接间隔Connection Interval和从机延迟Slave Latency。连接间隔越短通信实时性越高但主从双方都要频繁唤醒。合理的做法是把连接间隔设在 30 到 50 ms同时开启从机延迟让设备在不需要交互时跳过若干次连接事件。实测下来这种配置能让连接状态下的平均电流控制在 200 µA 到 500 µA 之间具体取决于数据包大小和应用唤醒频率。2.2 从nRF52832到nRF5340的选型差异Nordic 的 SoC 家族里nRF52832 是出货量最大的老将nRF52840 算是增强版支持更快的 2Mbps 速率、更多 I/O 和 USB。而 nRF5340 则换成了双 Cortex-M33 核一个高性能应用核一个低功耗网络核架构上更前卫。如果只是做一个简单的追踪器只跑 BLE 标签应用nRF52832 完全够用。它主频 64MHz Cortex-M4F512KB Flash 64KB RAM跑 BLE 一个简易传感器采集绰绰有余。但如果你需要并行处理音频、传感融合或者更复杂的算法nRF5340 的 128MHz 应用核和 1MB Flash 就更有底气。不过双核不是没有代价。nRF5340 的低功耗网络核单独跑 BLE 协议栈应用核随便你怎么折腾两个核之间通过 IPC 通信。这种架构带来更高的灵活性和稳定性但配置起来也更复杂。项目周期紧张的话用单核 nRF52 系列反而更稳。我做过一个宠物追踪器项目当时评估过 nRF5340最后因为团队对 Zephyr 不够熟还是选了 nRF52832开发效率高了很多功耗也完全满足要求。注意选择 nRF53 系列意味着你基本上要拥抱 Zephyr RTOS 和 NCSnRF Connect SDK老 nRF5 SDK 对它的支持有限。如果团队只会裸机开发上手 Zephyr 的曲线会比较陡需要额外评估工期。3. 固件升级DFU与配套工具链的实操坑3.1 小程序DFU实现的关键点现在很多可穿戴产品要求用手机小程序直接给设备升级固件也就是“小程序 DFU”。这个需求在热词里非常典型。微信小程序里做 BLE 通信本来就有不少限制比如 API 是基于 Web 蓝牙的封装无法直接访问底层 GATT 的 CCCD客户端特征配置描述符细节有些平台还不支持自定义 MTU 设置导致一次写入的数据长度受限。Nordic 的 DFU 服务基于 Secure DFU本质是一个 GATT Service往某个 Write 特征写入命令和数据包再监听另一个 Notify 特征接收响应。在小程序里实现时最稳妥的办法是先用手机 AppnRF Connect验证整条 DFU 流程拿到完整时序和包格式再在小程序里照着实现。几个容易踩的坑一是数据分包长度比如 MTU 只有默认的 23 字节你一次最多写 20 字节如果固件有 200KB就要分成 1 万多个包发送中间任何一包丢了或写入失败都得有重传机制二是写入速率限制Nordic DFU 底层要求每个包或每组包之间等待响应不能一口气不断写三是切 bootloader 模式和重连小程序 DFU 经常在固件启动引导加载后断开连接需要重新扫描并连接到新设备。3.2 常见DFU失败排查流程我整理了一个 DFU 排查清单遇到升级失败可以先按这个顺序过一遍确认设备处于 DFU 模式广播名称或服务 UUID 是否正确通常是在正常应用下通过命令软复位进入 bootloader。确认 MTU 协商成功。小程序里通过写入一个“空包”触发 MTU 协商如果协商不成功后续大数据包会直接失败。确认写入的数据满足 20 字节对齐。nRF Secure DFU 要求最后一个包如果不满足 20 字节要补零否则底层校验不过。确认响应超时时间。小程序里如果监听不到 Notify 响应大概率是写入太快导致设备没来得及回复这时需要加延时或者等待前一个 notify 到达后再写下一包。实测经验有一次升级到 90% 时总是失败最后发现是小程序在连续写入时没有加流控底层协议栈丢包后没有重发机制。后来把“写入-等响应-再写入”的流程改成了“写入一包收到响应后紧接着写下一包”问题立刻消失。4. 与手机端的通信实现要点4.1 Android BLE开发常见坑Android BLE 是口碑很差的领域因为碎片化严重。做过 Android BLE 工程的朋友应该都有感触同一套代码在 Pixel 上很稳在国产手机上就各种扫描不到、连接失败、自动断开。扫描不到设备先检查权限。Android 12 以上需要 BLUETOOTH_SCAN 和 BLUETOOTH_CONNECT 动态权限Android 11 及以下需要定位权限否则 scan 回调拿到的结果为空。很多人卡在这一步。连接上之后还有一个经典问题服务发现成功与否取决于设备是否在合理时间内响应。Nordic 设备响应很快但某些手机系统会先做 MTU 协商或者需要你主动 requestMtu如果忘记调默认 23 字节的 MTU 会导致长数据写不进去。对策是连接成功后先requestMtu(247)然后再discoverServices()注意 onMtuChanged 的时序。一个比较稳的处理方式连接成功 → onConnectionStateChange 为 CONNECTED → 调用 requestMtu → onMtuChanged 成功后 → 再 discoverServices → 操作特征。4.2 C#与BLE通信的第三方库选型社区里有个热词问“只安装 shiny.bluetoothle 可以实现 BLE 蓝牙通信吗” 这个问题很典型答案是可以但要看使用范围。Shiny.BluetoothLE 是一个基于 Xamarin/MAUI 的跨平台 BLE 库它封装了 Android 和 iOS 的 BLE 接口提供扫描、连接、读写特征等能力。如果是一个 WinForms 项目面向 .NET Framework 4.7.2再去用 Shiny.BluetoothLE 就不太合适因为那个库主要面向移动平台。Windows 上做 BLE 通信比较成熟的方案是直接用 Windows.Devices.Bluetooth 这个 UWP API.NET Framework 4.7.2 的 WinForms 项目可以通过引用Windows 10 SDK或者用 NuGet 包Microsoft.Windows.SDK.Contracts来调用。此外32feet.NET 这个库也支持 BLE但更偏传统蓝牙可以关注一下。具体操作步骤大概是先通过BluetoothLEDevice.FromIdAsync获取设备然后取得 GATT 服务、特征再通过WriteValueAsync和Characteristic.ValueChanged事件来收发数据。底层也是基于 WinRT 的异步模型写起来比 Android 简单不少。但注意Windows 对 BLE 的设备配对流程有特殊限制有些设备必须先从系统设置里配对然后才能被应用访问这是和 Android 很不一样的地方。5. 常见问题与项目实操心法5.1 从网络热词看开发者最真实的痛点这次搜索到的热词里有几个特别有意思。比如“ble pawr”这是 Nordic 最近在推的 Periodic Advertising with Responses是用来做“无线广播低功耗双向通信”的适合电子价签这类设备。还有“esp32-s3 wifi与ble协议”很多工程师纠结于 ESP32 的 Wi-Fi 和 BLE 同时工作时的 RF 切换问题。说实话ESP32-S3 的 BLE 性能在同价位里还行但深度睡眠电流和 Wi-Fi 共存时的稳定性跟 Nordic 相比还是有差距。所以如果你做的不是 Wi-Fi 加 BLE 的组合产品而是纯 BLE 追踪器Nordic 是更合适的。另外“ekf考虑容量校正soc”这个热词很有意思它把电池管理里的 SoCState of Charge和系统级 SoC 芯片搞混了。在可穿戴追踪器里电池电量的估算非常关键。很多方案直接读 ADC 电压然后查电压-电量表这种方法在低功耗设备上偏差极大因为电池在脉冲负载下的电压波动会误导判断。工程上一般用库仑计加开路电压校准复杂一点就是 EKF扩展卡尔曼滤波去估算。Nordic 的 SoC 内部有比较器、ADC 和 PPI 外设可以辅助实现简单的电量测量但精度有限想要准确还是得外挂专用电量计芯片比如 TI 的 BQ25120 或者 MAX77818。5.2 实测总结哪些坑可以提前避开第一坑天线阻抗匹配。很多硬件工程师画完 PCB 不去调试匹配网络直接用参考设计的天线走线。可穿戴设备外壳会显著改变天线谐振一定要留出 π 型匹配网络的位置。我做过一个手环最开始天线匹配只是参考值戴到手上 RSSI 掉到 -85 dBm连接频繁断开。后来在实验室调整了两个电容RSSI 恢复到 -60 dBm 左右断连问题彻底解决。第二坑晶振精度。BLE 对时钟精度要求很高尤其是连接状态下主从设备要用定时同步来校准接收窗口。如果使用内部 RC 振荡器做蓝牙时钟频率漂移大会导致连接窗口错开出现“刚连上就断开”的怪异现象。建议直接选用 32.768 kHz 外部晶振 16 MHz 外部晶振成本多不了几毛钱但能省很多调试时间。第三坑日志输出影响功耗。很多人调试时喜欢开串口日志或 RTT 日志但忘了在量产固件里关掉。RTT 在芯片不连接调试器时默认不工作影响不大但串口 UART 如果一直开着哪怕不发送数据也会多耗几十微安。低功耗设备里几十微安已经很多了。量产前一定要检查外设的电源域和时钟是否全部关闭。注意做低功耗产品从项目一开始就要习惯测量“工作电流曲线”。用 J-Link 加上 Nordic 的 PPKPower Profiler Kit或者使用带功耗分析的电流探针把整个工作周期的电流录下来。不要只看平均电流还要看尖峰电流和持续时间因为这些会影响电池有效容量尤其是用纽扣电池时内阻大电压跌落会造成系统复位。5.3 一个真实项目的能耗估算思路假设一个追踪器每 10 秒广播一次广播事件约 3 ms广播电流 6 mA广播间隔内休眠电流 2 µA。那么平均电流大约是6mA * 3ms / 10s 2uA 1.8uA 2uA 3.8µA一个月下来约 2.7 mAh。再加上每天连接几次同步数据每次连接 2 秒连接电流 8 mA每天 6 次平均电流约8mA * 12s / 86400s ≈ 1.1µA。总平均大概 5 µA100 mAh 的电池理论上能撑 20000 小时也就是两年多。这是非常理想的情况实际上要留足裕量一般按 70% 的效率算续航也能到一年以上。这也是为什么 BLE 追踪器能用纽扣电池工作很久的原因。6. 关于工具链和生态的一些补充6.1 务必会用Zephyr开发但别被它吓到nRF Connect SDK 从 2.x 以后完全基于 Zephyr RTOS 开发这对老工程师是个适应门槛对新人反而是个好事。Zephyr 的设备树Devicetree和线程化模型一开始比较抽象但一旦理解了“设备树就是硬件描述的配置文件Kconfig 就是编译开关”这两个概念大部分问题都能迎刃而解。举个实际例子在 nRF52832 上初始化一个 PWM 输出呼吸灯。在旧 SDK 里要手写一堆寄存器映射和定时器配置在 Zephyr 里只需在 devicetree 里定义一个 PWMs 节点然后直接pwm_set_dt(pwm_spec)就能输出波形。对于可穿戴产品里常见的振动马达、LED 灯、传感器供电控制这种抽象能省不少时间。不过要注意Zephyr 的电源管理不像裸机那么直观。如果你之前已经在 nRF5 SDK 上积攒了一套低功耗逻辑迁移到 Zephyr 时要重新设计特别是 System OFF、Retention RAM 等特性的用法不太一样。建议量产项目先做最小验证板把“休眠-唤醒-连接-广播”整个链路在 Zephyr 下跑通再扩展业务功能。6.2 云端与App联动设计中容易忽略的点可穿戴追踪器很少是纯本地设备大多数场景需要把数据同步到 App 再上云。这就留下一个问题本地时间戳和云端时间戳经常不一致。很多追踪器为了省电不配备实时时钟晶振每次连接手机后拿手机时间校准但一旦用户长时间不开 App设备本地计时的误差就会累积导致运动轨迹、步数统计的时间轴错位。我在一个儿童手环项目里就吃过这个亏。最初设计是定时和手机 App 同步时间但用户经常一两周不开一次 App最后云端的步数曲线看起来从早上 10 点才开始计算逻辑完全对不上。后来改为设备每次广播数据时附带一个“出厂以来运行毫秒数”的计数器由 App 根据收到包时的本地时间转换成绝对时间戳。这样即使设备时钟错了至少事件顺序不会乱再配合云端修正能够大幅减少时间错乱问题。另外要注意BLE 连接时的 MTU 大小直接决定一次数据传输效率。如果你要同步几千条缓存的历史数据一定要在连接后协商 MTU 到 247否则一条 20 字节的包一次传 1 个字节的协议头效率极低用户体验会很差。6.3 天线与外壳设计的协同讲一个被反复忽略的问题可穿戴追踪器的天线不能等结构定稿后再调试。最理想的流程是项目早期就用手板外壳装入 PCB用网络分析仪测试天线的 S11 参数和实际辐射效率。因为外壳材质尤其在腕带、金属件附近会造成频率偏移。如果发现中心频率偏离 BLE 频段2.4 GHz要通过匹配网络调整然后在整机状态下重测。还有一个隐藏坑人体电容效应。手表戴在手上手部对天线的近场影响显著导致天线方向图变形和效率下降。所以最终测试一定不能在桌面孤零零地测要模拟佩戴场景。相关标准可以借鉴 FCC/CE 的 SAR 测试思路虽然不需要真去实验室做辐射暴露评估但至少要了解结构件对天线的影响好提前留出调试空间。经验备料时多备几种容值的电容电感和几种不同材质的结构件手板方便现场调整匹配。别等结构件送样时只有一款那会非常被动。7. 最后再分享一个小技巧做可穿戴追踪器除了一线工程师关心的射频和功耗产品经理和测试同事往往会忽略一个点设备固件里的日志如何远程获取。量产设备没法接 J-Link那么问题出现时只能靠用户反馈。建议在固件里设计一个“调试模式隐藏服务”例如一个 GATT 特征允许支持工程版 App 读取设备内部日志缓冲区。这样在现场测试或用户投诉时不需要拆机手机连上去就能拉取日志效率高很多。这个特性在 Nordic 的 SoftDevice 架构下实现很容易用 NRF_FSTORAGE 保存历史日志再通过一个自定义 Service 暴露给手机端。注意正式版固件要默认关闭这个服务避免被恶意抓数据。我个人在实际操作中的体会是Nordic 的 BLE SoC 并不是每一项指标都最强但它把“开发效率、稳定性和生态完整性”这三样东西整合得最好。可穿戴追踪器这种产品拼的不是单一性能而是整个量产交付的综合成本。选它不一定是最亮眼的方案但大概率是最稳妥的选择。如果你正要开始做类似项目先把低功耗链路打通再一点点加功能别一上来就炫技。稳扎稳打产品才能早日落地。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
