低功耗BLE探空仪模块开发：基于nRF52832的无线传感器设计实战

一个探空仪项目做完，我对“卫星发射机模块”这类设备有了新的理解。客户要的是一个巴掌大的无线发射模块，用Nordic nRF52832做主控，采集气压、温度、湿度，通过BLE链路实时把数据发回地面接收站，还要在低温、高湿度、剧烈振动环境里连续工作十几个小时。探空仪本身不指望回收，电池用完就报废，成本和功耗必须压到极致。这类设备不是普通蓝牙外设，而是资源极度受限、可靠性要求极高的无线数据前端。

这篇文章会从需求拆解、硬件设计、固件架构、功耗优化、DFU升级到量产调试，完整走一遍这个模块的开发过程。重点放在Nordic BLE SoC（nRF52系列）的实际工程经验上，适合正在做电池供电无线传感器、探空仪、应急信标或者其他低功耗BLE产品的工程师参考。文章里的参数和计算方法都可以直接套用，不需要再去翻几十页数据手册。

说明一下，文中的“卫星发射机模块”指的是高空气象探测、应急定位、野外环境监测这类无线电发射前端，通常配合地面中继或数据采集站使用。BLE负责本地数据链路和配置升级，不是直接用蓝牙和轨道卫星通信。

1. 内容整体设计与思路拆解

1.1 从应用场景倒推硬件需求

做这类模块最忌讳一上来就选芯片画板子，得先想清楚工作场景和约束条件。探空仪的场景可以概括成：搭载在探空气球上，从地面升到30公里左右的高空，期间持续采集气象数据并实时发送。整个飞行时间大约两到三个小时，设备要工作在-60℃到+50℃的温度范围内，供电只能用一次性电池，没有外接电源，也不可能有人去复位它。

把场景翻译成硬件需求，大概是四条。第一，无线链路必须可靠，数据丢包率要控制得住，接收端在很远的距离还能解出数据；第二，整机平均功耗越低越好，电池容量有限，两小时飞行加上地面等待时间，至少要能支撑3到4小时；第三，主控最好把无线收发、协议栈、传感器采集都集成在一个芯片里，体积和成本都占优；第四，开发周期不能太长，协议栈必须成熟稳定，不能拿一个刚出厂的协议栈去赌探空仪能不能按时放飞。

这四条需求基本就把方案定型了：一颗集成2.4GHz收发器、Cortex-M4F内核、BLE协议栈的SoC，外加几个模拟传感器和一个GNSS模块。我选Nordic而不是其他家的原因，主要是它的SDK和文档把低功耗无线开发的门槛压得足够低，飞行项目里最缺的就是时间。

1.2 为什么是Nordic，而不是TI、ST或者Silicon Labs

这个问题经常被问。老实说，TI的CC2640、ST的BlueNRG、Silicon Labs的EFR32都有自己的优势，有的射频指标更好，有的价格更低。但在“快速做出可靠的低功耗无线产品”这件事上，Nordic的生态成熟度目前还是最省心的。

关键差异在三点。一是SoftDevice这种协议栈预编译加事件回调的模型，把BLE状态机封装得干干净净，不需要关心链路层细节，只需要处理连接、断开、数据收发这些事件；二是nRF Connect SDK和老的nRF5 SDK提供了大量可直接修改的例程，从BLE UART到DFU升级都有现成模板；三是社区和工具链，nRF Connect for Desktop、Power Profiler Kit、Sniffer这些工具几乎是做低功耗BLE的标配，调试起来比裸读寄存器快太多了。

芯片型号的选择上，nRF52832是均衡之选：512KB Flash、64KB RAM、BLE 5.0、灵敏度-96dBm，对于探空仪这种不需要大容量存储和外设扩展的场景绰绰有余。如果传感器多、需要同时跑BLE和802.15.4，或者要有USB口，可以考虑nRF52840，Flash和RAM翻倍，还带USB和更多外设。新项目建议直接用nRF Connect SDK，基于Zephyr RTOS，设备驱动和协议栈集成度更高。老nRF5 SDK虽然还能用，但已经进入维护模式，新项目没必要再学一套过时的方案。

2. 硬件设计：最小系统与射频链路

2.1 SoC最小系统设计：电源、晶振、调试接口

nRF52系列的外部电路并不复杂，但每个细节都影响无线性能和功耗。先讲电源。绝大多数nRF52芯片支持1.8V到3.6V的供电范围，内部集成LDO和DCDC。如果用LDO模式，芯片在TX峰值时电流可能到10mA以上，整体效率偏低；如果启用DCDC模式，峰值电流能降到5mA左右，平均功耗尤其明显。具体做法是在VDDH和VDD之间加一个10uH电感，配合去耦电容，然后用SDK里的sd_power_dcdc_mode_set()或者Zephyr的regulator API把DCDC打开。

晶振方面，32.768kHz的LFXO没有外部误差校准，低温下频率漂移会影响RTC计时精度，所以探空仪这种跨温区工作的产品，最好在软件里对RTC做周期校准，或者选用带温度补偿的TCXO。32MHz的HFXO直接影响射频频偏，频偏太大会导致接收端误码率升高，甚至无法连接。批量生产时一定要在射频测试工位检查中心频点，频偏超过±10ppm就要换晶振或补匹配。

调试接口不要省。SWD两根线加上RST，量产板子上留4个1.27mm的测试点，既便宜又稳定。注意芯片的DEC1、DEC2、DEC3这些去耦引脚，必须按数据手册放足够容值的电容，位置尽量靠近引脚，否则晶振起振不稳、射频发射频谱变差的问题会非常难查。

2.2 天线选型与射频链路预算

天线是这类模块最容易翻车的环节。探空仪外壳通常是塑料或泡沫材质，对外置天线的净空区要求不高，我倾向于用弹簧单极天线或者四分之一波长单极子，通过SMA座引出，方便地面测试时换成标准天线。PCB上如果有空间，用倒F天线也行，但调试匹配网络需要矢量网络分析仪，小团队未必有这个条件。

链路预算不用算得很玄乎，核心公式就一个：

接收功率(dBm) = 发射功率(dBm) + 发射天线增益(dBi) + 接收天线增益(dBi) - 自由空间路径损耗(dB) - 系统损耗(dB)

自由空间路径损耗公式：

FSPL(dB) = 20*log10(d) + 20*log10(f) + 32.44

d以米为单位，f以GHz为单位。代入1000米和2.44GHz，得到约100dB的路径损耗。如果发射功率0dBm、接收灵敏度-96dBm，链路裕量大概只有-4dB，明显不够。所以这类模块不要只开0dBm，把nRF52840的最大发射功率+8dBm或者nRF52832的+4dBm用上，再配合接收端的高增益天线，才能在同样距离下保住至少十几dB的裕量。

地面接收站的天线一定要架高，尽量减少地面反射和多径衰落。我实测过一个有意思的现象：同样一个探空仪模块，放在桌子上和贴在窗户玻璃上，接收信号强度可以差到10dB以上。这就是多径和人体、金属结构吸收的影响，现场测试的时候别忽略环境变量。

2.3 传感器采集与模拟前端

探空仪一般要采集气压、温度、湿度，有的还要加速度和GNSS位置。温度传感器可以集成在SoC内部，但精度不够，还是用外部数字传感器更放心。气压传感器用BMP388或者MS5611，湿度用SHT35，都是I2C接口，和nRF52的TWI外设对接非常顺。要注意的是传感器上电瞬间会有浪涌电流，好几个传感器同时上电可能把电源电压拉低，软件里要分时使能传感器电源，或者加一个RC延时电路。

如果项目需要采集模拟信号，比如模拟温度电桥或者电池电压，nRF52的SAADC是12位逐次逼近型ADC，采样速率最高200kSPS，完全够用。但务必注意输入阻抗和采样保持容抗的影响，信号源内阻比较大的时候要开内部增益配置，或者外接运放做缓冲，否则采样值会偏小。电池电压检测直接用电阻分压后送ADC，分压电阻要选高精度低温漂的，误差会直接反映在电量估算上。

3. 固件架构与核心实现

3.1 SoftDevice、SDK与应用层的事件模型

nRF5 SDK里，协议栈以SoftDevice二进制方式烧录在Flash低地址区，应用代码从高地址开始运行。应用调用SoftDevice提供的API，通过回调事件拿到数据。这种设计把BLE协议栈和用户代码隔离，有两个好处：一是协议栈升级不必改应用代码，二是应用崩溃不容易把协议栈拖死。缺点是Flash和RAM都要预留固定区域，比如S132需要约48KB Flash和4.4KB RAM，这些在链接脚本里必须配置正确，否则运行到一半直接HardFault。

新项目用nRF Connect SDK就不一样了，底层是Zephyr RTOS，BLE协议栈、驱动、应用都编译成一个镜像，Flash和RAM分配更加灵活，但有OS的概念要学。事件处理依然遵循“回调统一放线程上下文”的原则，不要在GATT回调里做I2C读取、延时、Flash写入这些耗时操作，否则会阻塞协议栈线程，造成连接超时。我的习惯是在回调里只做数据拷贝和flag置位，真正的数据处理放在主循环或者独立线程里。

3.2 BLE数据协议设计：广播、连接、MTU怎么选

探空仪这种单向数据流设备，首选广播模式，而不是建立连接。GAP广播包最多31字节，可以带厂商自定义数据，刚好塞下温度、湿度、气压和序列号，加一个2字节CRC。接收端用扫描方式捕获，不需要配对，也不会有连接管理开销。缺点是广播间隔不能太短，太短会增大功耗和信道占用，通常设100ms到1s之间，再配合动态修改广播间隔：地面等待时用1s，升空后改成100ms，提高刷新率。

如果需要对模块做参数配置或者固件升级，就得进连接模式。连接后的ATT MTU默认23字节，也就是每包最多20字节有效数据。nRF52支持协商更大MTU，最高可达247字节，把一批传感器数据合并发送，能显著提高吞吐和电池效率。在nRF5 SDK里调用sd_ble_gattc_exchange_mtu_request()，在Zephyr里用bt_gatt_exchange_mtu()。MTU协商是双向的，接收端也要支持才行，否则只能回到分包发送的老路。

数据包格式设计建议参考下面的结构，头部固定、长度明确，接收端解析时可以少做很多兼容判断。

typedef struct __attribute__((packed)) { uint8_t sync; // 0xA5 同步字 uint8_t msg_id; // 帧类型: 0x01遥测 0x02配置回执 0x03DFU状态 uint16_t seq; // 序列号, 用于丢包统计 uint8_t sensor_num; // 传感器数量 int32_t pressure; // 气压, 0.01hPa int16_t temp; // 温度, 0.01℃ uint16_t humidity; // 湿度, 0.01% uint16_t battery; // 电池电压, mV uint16_t crc16; // 对前面所有字节的CRC16 } telemetry_frame_t;

这个包不到20字节，可以直接放进一条BLE广播数据里，也可以用GATT通知发送。CRC16一定要加，BLE链路本身有CRC，但扛不住传输过程中偶发的比特反转，加了CRC后接收端能识别并丢弃坏帧，实测丢包率能降低一个数量级。

3.3 任务调度与异常恢复

低功耗嵌入式产品的固件最怕死循环和资源泄漏。在nRF5 SDK时代，我习惯用app_scheduler把事件排到队列里慢慢处理，回调函数里只做快速操作。到了nRF Connect SDK，Zephyr的线程加消息队列是更自然的写法：定时器线程每1秒唤醒一次，读传感器、打包、更新广播数据，然后回sleep；BLE线程处理连接和配置请求；主线程负责运行状态统计。

异常恢复上要特别考虑看门狗。启动时初始化并喂狗，主循环超时未喂就复位。复位后检查ResetReason，如果是看门狗复位，则发一条诊断数据给接收端，同时降级运行——比如关掉气压传感器，只保留温湿度和定时广播，避免反复崩溃。探空仪升空后没人能干预，这种自愈机制能大大减少“白飞一趟”的概率。

4. 功耗优化：让一次性电池扛得住

4.1 功耗构成与平均电流估算

这类模块的功耗分四块：传感器采集、无线发送、系统空闲、以及瞬间启动。nRF52在System ON空闲模式电流在1.9uA左右，用RTC定时唤醒后，一次传感器采集加发送通常要15到30ms，期间平均电流大约10到12mA。假设每10秒发一条数据，平均电流就是20ms乘以11mA除以10秒，约22uA，加上空闲电流和传感器休眠电流，整体在25uA左右。这个量级下，一颗1200mAh的锂亚电池理论能跑5年以上，但实际要考虑电池自放电和低温容量衰减，按一半估算也有两年多。

不过探空仪不是长期运行设备，两三个小时飞行结束后就丢弃了，电池容量反而不用太大。选电池的逻辑是先算清楚总能量需求：平均电流25uA乘以3小时约0.075mAh，看似很小，但发射瞬间有几十mA的峰值，电池内阻不能太大，否则电压塌陷会触发brownout复位。实际中我用过ER14250锂亚电池，标称1200mAh，最大脉冲电流50mA，在-40℃下还能带得动模块，是很好的选择。

4.2 用Power Profiler Kit量化每一次唤醒

纸面计算再准，最后还是要实测。Nordic官方的nRF Power Profiler Kit II（PPK2）可以直接串在供电回路里，用软件记录电流波形和电荷消耗。我第一次测自己写的定时唤醒程序时，发现实际平均电流比预期高了四倍，后来看波形才发现是每次唤醒后I2C总线的上拉电阻把电平拉高的时间太长，白白多耗了2.2mA持续几个毫秒。改成唤醒后先等总线稳定再读取，立即降下来了。

PPK2还能测电池仿真曲线，模拟电池在脉冲负载下的动态响应，对排查电压塌陷问题尤其有用。建议每个工程阶段都跑一遍整机功耗测试，记录每个外设开启和关闭对应的电流台阶，形成一份功耗基线表。后面固件一改，通过对比基线就能快速定位是哪个改动引入了额外功耗。

4.3 低温环境下的电源与电池策略

探空仪要上到平流层，-60℃的低温是绕不开的坎。锂电池在低温下内阻急剧增大，容量可能只剩常温的30%。硬件上可以加一个保温层，把电池和电路板包在气凝胶或泡沫里，利用电路自身发热维持局部温度。软件上启动阶段不要立刻全速采集，先让系统以较低占空比运行，让电池温度稍微回暖再拉高功耗。此外所有传感器和晶振也要选工业级甚至汽车级型号，普通商用级在-40℃以下就可能不工作。

我踩过的坑是只低温测试了主板，忘了测电池本身，结果整机在-50℃冷启动时反复复位。后来把电池换成能支持-55℃到85℃的专用锂亚电池，并且在启动代码里加了一个“低温延时启动”流程，温度读数低于-30℃时先延时30秒再开始采集，问题才彻底解决。

5. DFU升级、调试与量产经验

5.1 用Buttonless DFU解决现场升级问题

探空仪这类设备很少被人拿回来，但地面监测节点或应急信标是要长期部署的，固件升级是刚需。对BLE设备来说，最省事的方案是Nordic的Secure DFU，分成四个区：Bootloader、SoftDevice、App、DFU Data。Bootloader在启动时检查DFU入口标志，如果被置位就进入接收固件模式，通过BLE服务收包、验签、写入Flash，完成后跳转到新固件。

应用层可以集成Buttonless DFU服务，手机App通过GATT把设备踢进DFU模式，不需要用户按复位键。这里有个容易犯的错：DFU分区大小要和实际固件匹配，尤其是SoftDevice和App之间的地址偏移，一旦写错，升级后直接起不来。量产前的整机升级测试必须覆盖“从旧版本升到新版本”和“从新版本降回旧版本”两条路径，还要测试升级中断电的恢复流程。如果设备没有外部Flash缓存完整固件，建议启用双区或者至少保留回滚镜像，否则升级一半断电，设备就变砖了。

5.2 调试三板斧：日志、抓包、射频测试

代码阶段主要靠RTT日志。SEGGER RTT可以在不占用UART引脚的情况下输出调试信息，而且速度远快于串口，至少在系统卡死时还能看到最后一条日志。正式版本里记得把日志等级调低，或者用宏直接去掉，省一大块Flash。

无线链路问题靠抓包。用nRF52840-DK刷成BLE Sniffer，配合Wireshark能解析广播包、连接请求、ATT操作等几乎全部空中报文。调试连接不上、连上就断这类问题时，抓包比看日志高效得多，因为能看到空中到底发生了什么，是广播没发出来，还是连接参数协商失败。

量产测试阶段要跑射频自动化测试。Nordic的芯片有DTM模式，上位机通过串口或USB发送标准命令，测试发射功率、频偏、接收灵敏度和杂散。我用过一个射频测试治具，把待测板子放进屏蔽箱，通过GPIO触发进入DTM模式，自动记录每个板子的发射功率和频偏，不合格的直接挑出来，省掉很多人工判断。频偏偏大多半是晶振匹配电容问题，可以做一个简单统计，指导贴片厂调整。

5.3 量产烧录与MAC管理

量产烧录不推荐用J-Link一个一个来，效率太低。建议贴片前用离线烧录器批量烧录Hex文件，或者在生产线上用SWD转接板统一烧录。蓝牙设备的MAC地址要么烧录到FICR寄存器（芯片出厂默认），要么单独放在一个安全存储区。探空仪这类设备用芯片默认的随机MAC就行，但地面基站系统如果要按MAC白名单管理设备，就要在生产时把MAC记录和产品序列号绑定，写入设备管理数据库。

烧录完还要做整机功能测试：供电后自动启动广播，用一台手机App连接并读取传感器数据，确认数据合理，再触发一次Buttonless DFU流程确认固件写保护正常。测试通过后打上序列号标签，记录测试数据。这个流程看着繁琐，但能避免大量售后问题，尤其当产品要在野外无人值守环境下长期运行的时候。

6. 常见问题与排查技巧实录

这里把我的调试记录整理成速查表，都是实际项目中遇到过的问题，不是从数据手册照搬的。

单独展开几个高发问题。第一，扫不到设备，我遇到最多的情况是晶振没起振，尤其是低温冷启动时32MHz晶振起振时间过长。排查方法是用示波器量HFXO引脚，或者让程序在启动早期把LED点亮，再通过GPIO翻转时间戳判断卡在哪个阶段。第二，平均电流偏高，八成是GPIO悬空加上外设没真正断电。很多数字传感器的断电引脚只是关了内部电源，但把SDA、SCL拉高还是会有漏电流，需要把总线也配置成高阻或者下拉。第三，DFU升级失败后设备反复重启，多半是Bootloader无法正确识别App有效标志。解决方法是每次升级完成后写一个明确的magic值到Flash固定地址，Bootloader启动时校验这个值，校验不过就自动进入DFU模式而不是傻等。

最后分享一个自己常用的排查小技巧：固件里保留一个出厂诊断功能，长按某个引脚3秒进入自检模式，依次点亮LED表示电源、晶振、传感器、无线电各模块是否正常。野外部署的设备如果出问题，现场人员不用拆机、不用串口线，只看LED就能判断故障方向。这个功能占用资源很少，带来的运维价值却很大。

7. 项目管理与经验教训

7.1 提前搭好功耗和射频测试环境

项目启动的第一周就应该把测试环境搭好，而不是等硬件回板再想。PPK2、屏蔽箱、频谱仪、Sniffer、示波器，该买的买，该借的借。我见过太多项目卡在最后阶段才发现功耗或者射频不过关，临时补设备、补测试，改板周期直接翻倍。功耗基线和射频指标在原理图评审阶段就定下来，后面所有改动都要对照基线回归。

文档要跟着开发走。每个设计决策，包括芯片选型理由、分区表版本、功耗测试数据，都记录在共享文档里。模块开发项目周期短、硬件牵涉面广，哪个环节资料断档，后面的人把分区表改错一个地址，就是整批板子的损失。

7.2 和天线厂、电池供应商提前沟通

做无线产品最忌所有事情都自己扛。陶瓷天线、弹簧天线的性能受外壳影响很大，建议在结构设计阶段就把3D模型发给天线厂，让仿真工程师帮着看净空区和匹配方案。电池同样要提前确认工作温度和脉冲电流能力，尤其是低温场景，不是所有锂亚电池都标称-55℃能放电，有些标称值只是存储温度，放电能力差很多。

和供应商沟通时一定要把“最大脉冲电流”、“最低工作温度下的容量保持率”写进规格确认单。我踩过供应商口头答应、实际到货性能不达标的坑，最后验收单写清楚了，退换货和索赔都有依据。做工程不是为了跟供应商扯皮，但规格书白纸黑字永远是保护自己的底线。

在这个项目上，我最大的体会是低功耗BLE产品的成败往往不在芯片本身，而在对场景的理解和细节的狠抠。芯片选型只占了20%的工作量，剩下的80%都在电源设计、射频匹配、软件调度、低温特性和生产测试这些地方。如果你正准备做类似的项目，第一步先把应用场景的所有约束写下来，工作温度、运行时长、数据率、电池容量、体积成本，一条条列清楚，再倒推硬件和软件方案，这样做出的模块才是真正能放飞的模块，而不是实验室里跑起来好看、一上真实场景就出各种问题的半成品。

另外，新项目建议直接上手nRF Connect SDK，虽然Zephyr的RTOS概念有一点学习成本，但长远看收益明显，以后的BLE、Thread、Matter扩展都在这个框架里。老SDK别再投入新开发，否则几年后又得迁移一遍。工程上的“省事”往往是最贵的选择，这个道理放在芯片平台选型上也一样。