一个探空仪项目做完我对“卫星发射机模块”这类设备有了新的理解。客户要的是一个巴掌大的无线发射模块用Nordic nRF52832做主控采集气压、温度、湿度通过BLE链路实时把数据发回地面接收站还要在低温、高湿度、剧烈振动环境里连续工作十几个小时。探空仪本身不指望回收电池用完就报废成本和功耗必须压到极致。这类设备不是普通蓝牙外设而是资源极度受限、可靠性要求极高的无线数据前端。这篇文章会从需求拆解、硬件设计、固件架构、功耗优化、DFU升级到量产调试完整走一遍这个模块的开发过程。重点放在Nordic BLE SoCnRF52系列的实际工程经验上适合正在做电池供电无线传感器、探空仪、应急信标或者其他低功耗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口可以考虑nRF52840Flash和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.44d以米为单位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 RTOSBLE协议栈、驱动、应用都编译成一个镜像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 SDKZephyr的线程加消息队列是更自然的写法定时器线程每1秒唤醒一次读传感器、打包、更新广播数据然后回sleepBLE线程处理连接和配置请求主线程负责运行状态统计。异常恢复上要特别考虑看门狗。启动时初始化并喂狗主循环超时未喂就复位。复位后检查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 IIPPK2可以直接串在供电回路里用软件记录电流波形和电荷消耗。我第一次测自己写的定时唤醒程序时发现实际平均电流比预期高了四倍后来看波形才发现是每次唤醒后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. 常见问题与排查技巧实录这里把我的调试记录整理成速查表都是实际项目中遇到过的问题不是从数据手册照搬的。现象可能原因排查和解决办法设备无法被扫描到广播未启动、天线损坏、软件死机看门狗循环复位用逻辑分析仪看GPIO电平变化抓复位波形确认广播参数检查晶振是否起振连接后设备反复断开连接间隔太短、协议栈处理不过来、通信丢包严重抓包看LL层错误原因把连接参数改成更宽松的间隔检查射频匹配发射距离突然变短天线馈点断线、外壳金属遮挡、静电损伤用VNA或频谱仪测回波损耗确认天线净空静电测试后复测平均电流远高于设计值外设没真正休眠、GPIO悬空、传感器上拉电阻常通用PPK2逐外设开关节能定位异常电流台阶GPIO统一配置为下拉输出低温时系统反复复位电池低温内阻大、LDO压差不足、晶振停振换低温电池确认最低工作电压启动代码加低温延时选工业级晶振DFU升级后无法启动SoftDevice和App地址错位、固件签名不对、升级过程断电核对分区表确认Bootloader跳转地址打开回滚功能并实测断电恢复接收端解出的数据校验失败数据包CRC错误、传感器异常值、链路噪声干扰查看接收端时序是否重叠广播数据加CRC传感器做滑动平均滤波同频干扰严重2.4GHz频段有WiFi或其他BLE设备改广播信道切换策略缩短广播间隔优化接收端时序过滤单独展开几个高发问题。第一扫不到设备我遇到最多的情况是晶振没起振尤其是低温冷启动时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别再投入新开发否则几年后又得迁移一遍。工程上的“省事”往往是最贵的选择这个道理放在芯片平台选型上也一样。