我团队前阵子接了个医疗级体温监测贴片的预研需求客户点名要用 U-blox 的 BLE 模块做核心通信方案整机做成一个可以连续监测体温并上报的 Temp Monitor。刚开始我觉得这事儿没那么复杂——BLE 模块集成度高协议栈现成电源和传感器一搭不就完事了真做起来才发现把一个 U-blox BLE 模块设计进去和把温控产品做好中间隔着至少两三个完全不同的工程阶段而且每一步都会踩到一些文档里不会写的坑。这篇就把整个从选型、电路设计到固件联调的过程完整拆一遍给正在做类似低功耗采集设备的朋友一个可复用的参考。标题里这句Designed into Temp Monitor是有讲究的它不是说模块能连上蓝牙就完事而是要把模块作为整个系统的通信基座围绕它去设计传感器采集链路、电源管理策略、天线布局和量产测试方案。这篇文章我会从为什么选 U-blox 而不是其他方案讲起然后是系统架构和硬件设计、BLE 通信链路和固件实现、工程化掉坑记录这四块都是我们实际项目中踩出来的经验。无论你是做可穿戴健康设备、冷链温度记录仪还是工业环境监测终端这套思路基本都能直接往你项目上套。1. 为什么选 U-blox BLE 模块而不是自研射频或国产替代先聊选型逻辑。市面上做 BLE 方案的路子大概有三条用 Nordic/TI 的 SoC 自己画射频电路、直接用 U-blox 这类射频模块、用国产透传模块。温度监控器这种产品我强烈建议走第二条路原因后面细细说。1.1 模块化设计省掉的不只是天线匹配很多人觉得用模块 交智商税一颗 nRF52832 芯片才十几块钱U-blox NINA-B1 模组要贵好几倍。这话对一半。芯片确实是模块的核心成本但模块里还包含了晶振、电容电感匹配网络、PCB 天线或天线引脚、屏蔽罩、甚至预烧录的协议栈固件。这些物料和工艺成本加在一起其实已经把模块的溢价稀释得差不多了。更重要的是时间成本。射频电路的设计难度不在原理图而在 PCB 布局和天线匹配。你自己画一颗 SoC 的参考设计第一次打板回来几乎必调天线你需要网络分析仪、屏蔽房、暗室测试这一套搞下来没一两周打底你想都不用想。U-blox 模块出厂前已经把天线匹配调好了内部做了屏蔽FCC/CE 认证的 Referenced Design 文档也都是现成的你在自己的板子上只要保证天线净空区和参考设计一致射频性能基本不会翻车。我还特地对比过温度监控这个场景对射频的特殊要求——它不像手机那样频繁通信而是长时间处于广播或低功耗连接状态每几秒甚至几分钟才传一次数据。模块的接收灵敏度、发射功率稳定性、休眠电流这些参数才是关键。U-blox NINA 系列的 -96 dBm 接收灵敏度取决于具体型号配合外部天线在室内穿一堵墙完全没问题实际测试我们在 30 米空旷距离下丢包率低于 1%这个表现足够撑起绝大多数温度监控应用。1.2 U-blox 产品线里哪颗更适合体温贴U-blox 的 BLE 模块目前主流是 NINA 和 ANNA 两个系列。NINA-B1 基于 nRF52832NINA-B3 基于 nRF52840ANNA-B1/B2 也是基于 nRF52832 但封装更小。我们项目最终选的 NINA-B1核心考量三个维度第一是功耗。体温贴要用 CR2032 纽扣电池供电目标续航至少 7 天。nRF52832 的峰值 RX 电流约 5.4 mATX 电流约 5.3 mA0 dBm 输出sleep 模式下 RTC 唤醒可以做到 1.9 µA 左右。NINA-B1 内部集成 DC/DC 转换器相比直接 LDO 供电能省掉 30% 左右的峰值电流这对电池寿命的贡献是实打实的。第二是尺寸和天线灵活性。NINA-B1 提供 PCB 天线、U.FL 连接器、天线引脚三种版本我们选了 U.FL 版本外接柔性天线因为体温贴要做成柔性电路与硬板结合的形式板载天线会被人体遮挡导致信号衰减外置天线可以布置到柔性区域远离人体。第三是软件生态兼容性。NINA-B1 内部跑的是 Nordic 的 SoftDevice 协议栈意味着你完全可以用 nRF5 SDK 进行开发U-blox 在上面加了一层 AT 指令固件也提供 mbed 和 Zephyr 的支持。这意味着我们既可以用 AT 指令快速验证硬件也可以完全绕开 U-blox 的封装直接拿 Nordic 的 SDK 做深度定制。1.3 没有选国产透传模块的真实原因不是崇洋媚外是工程风险问题。国产透传模块比如某些厂商的 QN9020/DA14580 方案确实便宜20 块钱以内能拿到带协议栈的完整模块但问题集中在三点一是文档质量参差不齐。有些模块手册连天线净空区要求都写得不清楚画板子全靠猜出了问题找 FAE 经常得到你再试试的回复。二是协议栈和 SDK 的延续性差。我们做的是产品不是 Demo需要考虑产品生命周期内的软件迭代。Nordic 的 SDK 有十几年积累示例代码丰富社区问题基本都是现成答案。某些国产物料的 SDK 连个像样的 Live 文档都没有出了问题只能靠现场 debug。三是批量供货的确定性。医疗体温贴通常是千万级的市场但单次起订量可能就几 K。U-blox 在大代理那里拿货周期稳定不会因为芯片缺货导致整个项目停摆。我去年就见过一个做温控记录仪的团队因为主控芯片被炒货整条产线停了两个月。当然如果你做的是消费级、低价走量、通信距离要求不高的产品国产透传模块完全可以考虑。但医疗级温度监控对可靠性和可追溯性要求很高U-blox 这种有完整认证体系和长期供货承诺的厂商才是稳妥选择。2. 温度采集链路与系统电源设计围绕 BLE 模块把外围撑起来硬件上BLE 模块只是通信引擎真正决定测温精度和续航的是传感器链路和电源部分。这一节按模块周围的两大系统拆开来聊。2.1 温度传感器选型NTC、TMP117 还是 SHT30温度监控器的核心指标就两个精度和响应速度。我们一开始用的是 NTC 热敏电阻 运放调理电路因为成本最低一个传感器几分钱。但做下来发现体温贴这种场景 NTC 有三个痛点温度-电阻曲线是高度非线性的需要在固件里做分段查表或 Steinhart-Hart 方程拟合标定数据每片都不一样量产时就得逐片校准。运放调理电路的漂移问题体温精度要求 ±0.1 °C运放的温漂和基准电压温漂叠加在一起很难在 -20 °C 到 50 °C 的工作范围内稳得住。响应速度慢NTC 本身热容大加上外围 RC 滤波温度突变后要十几秒才能稳定做快速测量场景体验很差。所以很快改成了数字温度传感器方案。对比过 TI 的 TMP117 和 Sensirion 的 SHT30TMP117 更适合体温贴TMP117 在 -20 °C 到 50 °C 范围内典型精度 ±0.1 °CI2C 数字接口直接输出 16 位温度值0.0078 °C 的分辨率内部自带 NIST 溯源校准量产时只要保证 PCB 焊接符合回流焊曲线几乎不需要逐片校准。SHT30 优势是温湿度一体但湿度测量对体温贴意义不大而且是 SMD 封装在柔性板上的凸点高度可能影响贴肤体验。实际设计中我把 TMP117 放在柔性板的末端接触皮肤区域I2C 总线从主控板走 FPC 连接过去。有一点要特别注意I2C 总线在柔性板上的走线必须做差分等长并且要在地线上加宽铜箔。因为柔性板在弯折时阻抗会变化等长差分可以减少信号时序偏移宽地线则能降低回路阻抗减少串扰。我们第一批样机就因为在 FPC 上把 I2C 拉到 20 cm 长且没处理好地导致 TMP117 经常读不到地址在总线上挂个 4.7 kΩ 上拉电阻才缓解。2.2 电源树设计从 CR2032 到 BLE 模块的每一路都要算账体温贴的电源树比想象中复杂大概是这样的思路电池正极先过一颗 10 µF 的陶瓷电容做去耦然后分三路第一路直连 NINA-B1 的 VCC 引脚模块内部有 LDO支持 1.7 V~3.6 V 输入CR2032 满电 3.0 V放完到 2.0 V 也能工作这点余量很关键。第二路经过一个负载开关Load Switch比如 TI 的 TPS22810给 TMP117 供电。为什么加负载开关因为 TMP117 虽然静态电流只有 3.5 µA但在测量模式下会瞬间拉到 135 µA如果用 GPIO 直接供电GPIO 的驱动能力不足会导致电压跌落影响传感器精度。负载开关还能在传感器不工作时彻底关断省掉那 3.5 µA 的漏电流。第三路是给模块内部的电平转换电路供电如果你用 AT 指令固件需要把 UART 的 TX/RX 电平映射到模块的 I/O 电平这部分 U-blox 的参考设计里已经包含照抄即可。功耗预算方面我做了一个粗略的表供参考模块状态电流消耗持续时间占比Sleep (RTC唤醒)2 µA95% 时间极低广播 (0 dBm, 100 ms间隔)10 mA每次10 ms中等连接事件 (7.5 ms间隔)8 mA每次3 ms中等TMP117 测量135 µA每次10 ms低算下来如果广播间隔设成 1 秒、测量周期 5 秒CR2032标称 220 mAh理论上能撑 30 天以上。但实际续航会打折因为电池内阻会随放电增大低温下容量也会下降所以最终产品标称续航 10-14 天比较合理留出足够的余量。2.3 PCB 布局的黄金法则射频、传感器、电源三分天下把 NINA-B1 画进电路板布局上最关键的是把三种功能区域物理隔离射频区模块的天线区域要挖空铜皮天线下方不要走任何信号线净空区至少保证 10 mm 以上。U.FL 连接器到天线之间的微带线阻抗要控制在 50 Ω线宽根据板厚和板材的介电常数计算我们用的 1.6 mm FR450 Ω 微带线大概 0.35 mm 宽。这个细节最容易被忽略我见过有人把天线馈线走到 BLE 芯片底下还盖了地铜信号直接被地吸收了通信距离从 50 米缩到 5 米。传感器区TMP117 要尽量靠近被测物体不要在它周围铺太多铜箔避免导热导致测量偏差。热阻路径上也不要有大功耗器件——BLE 模块发信时虽然电流很小但瞬间功耗会带来局部温升传感器离模块至少 2 cm 以上才不影响测量。我们实际的柔性板设计里传感器在末端模块在硬板端物理距离超过 3 cm实测对体温精度的影响可以忽略。电源区电池座附近放主滤波电容负载开关尽量靠近传感器侧电源线和地线走星形拓扑避免传感器和射频共享地回路引起的地弹干扰。3. BLE 通信链路设计广播包、GATT 服务和低功耗策略怎么配合温度数据的节奏模块和硬件都定了接下来是固件和协议层面的设计。这块不光是调通还要把温度数据流和 BLE 的通信节奏对齐。3.1 广播包设计让网关和手机都能快速识别你的温控设备温度监控器的数据发送有两条路径一条是手机 App 直连读取适合现场查看另一条是 BLE 网关批量采集适合医院病房、冷链仓库这种多设备场景。所以我们广播包里同时支持两种协议设备信息和温湿度数据。标准做法是配置 3 个广播/扫描响应字段Flags标准 BLE 广播标志决定广播类型和是否可连接。温度监控设备设置成可连接广播General Discoverable Mode因为需要支持手机主动配对。Complete Local Name放设备名。我们定义成 TempTag-XXXX后四位是 MAC 地址末四位方便在大量设备中区分。Manufacturer Specific Data自定义厂商数据段。这里放温度数据——这个设计能让网关不用连接设备直接抓广播包就能读取当前温度大大降低网关的功耗和并发压力。体温贴的广播数据格式可以包含温度值int16单位 0.01 °C、电池电量百分比uint8、状态标志位uint8比如校准完成、传感器故障。这里有个技巧广播包如果太长BLE 5.0 之前的协议规定单包最大 31 字节传统广播如果要做长广播需要扩展广播BLE 5.0 才支持。nRF52832 支持 BLE 5.0 的 2M PHY 和扩展广播但为了兼容老设备比如 iPhone 6s 之前的手机 BLE 4.2我们在广播包里只放最基本信息设备名厂商数据完整数据走 GATT 连接读取。3.2 GATT 服务定义温度读数、电池电量和设备信息怎么划分GATT 服务的设计直接影响 App 开发的复杂度和数据读取效率。参考标准 Health Thermometer ServiceHTS, 0x1809和 Battery ServiceBAS, 0x180F再结合我们自己的私有需求最终定义了三个 ServiceHealth Thermometer ServiceHTS 0x1809温度测量特征Temperature Measurement, UUID 0x2A1CNotify 属性温度类型特征Temperature Type, UUID 0x2A1D告知传感器放在哪口腔/腋下/皮肤表面。Battery ServiceBAS 0x180F电量特征Battery Level, UUID 0x2A19Read/Notify。这个服务标准手机都能识别。Vendor Service自定义 128-bit UUID放校准参数、设备序列号、固件版本、测量间隔配置等厂家特色数据。这里有个设计陷阱HTS 的 Temperature Measurement 特征按规范是 Notify-only 的有些手机 App 框架第一次连接时一定要先 Read 一次才能订阅 Notify。如果固件把这个特征设置成了 Notify-onlyApp 端就无法在 iOS 的 CoreBluetooth 里正确订阅因为 CoreBluetooth 要求先 discoverCharacteristics 再 setNotifyValue它不强制先 Read但有些第三方框架有 bug。稳妥做法是设置成 Read Notify读的时候返回上次测量的缓存值这样对 App 更友好。3.3 低功耗策略测量周期、连接间隔、广播间隔三者的权衡BLE 设备的功耗三分天下广播、连接、测量。每一块都要和实际应用场景对齐。测量周期体温贴不需要连续测量典型场景是每 10 秒测一次体温5 分钟上传一次到 App。TMP117 的转换时间默认是 15.5 ms最高精度模式也可以配置成 125 ms 模式降低功耗但精度会降到 ±0.25 °C。体温贴追求精度还是用 15.5 ms 的高精度模式反正每次测量只有 135 µA × 15.5 ms换算成平均电流才 0.2 µA影响可以忽略。广播间隔广播间隔直接影响设备被发现的速度和功耗。设成 20 msBLE 规范最小值会非常耗电每次广播约 10 mA × 几 ms意味着每秒 50 次广播平均电流可能到 2 mA 以上设成 1000 ms 则省电但网关扫描到设备要等 1 秒左右。温控设备在入门关用户首次配对时把广播间隔设成 100 ms 方便快速被发现配对完成后把广播间隔切到 1000 ms 省电。这需要在固件里做一个配对状态标志位App 端断开连接时也要能接受这种参数切换。连接间隔连接间隔决定连接事件频率体温数据是低频数据连接间隔设 30 ms 到 50 ms 就够用了。设得越小越费电每次连接事件都要唤醒 RX/TX设得太大则触发 Notify 时的延迟变大最坏情况要等一个连接间隔才能把数据发出去。我们最终设成 30 ms每次连接事件的实际工作时间只有 3 ms 左右对功耗影响很小数据延迟在几十毫秒内完全满足体温监控需求。还有一个细节从机 latency从设备延迟这个参数一定要用上。它允许从设备在连续几个连接事件里不响应主设备的包而不丢失连接可以大幅省电。我们把 connection latency 设成 4即每 5 个连接事件才响应一次这能让连接状态下的平均电流再降低 60% 左右。4. 从工程样板到量产天线调优、FCC 认证准备和生产测试的几道坎原理图、PCB、固件都通了之后还有一道比很多人想象中更长的路——把工程样板变成可量产的稳定产品。这节讲我们的实践过程。4.1 天线净空区微调为什么你的通信距离永远比厂商标称短NINA-B1 的 U.FL 版本外接柔性天线的标称效率在 2.4 GHz 频段大概 50% 左右但你把它放进壳体之后实际效率往往会掉到 30% 以下。原因是天线附近有塑料结构件、电池、排线、甚至 PCB 连接器的金属外壳都会吸收和反射电磁波。这个问题的排查方法是用频谱仪 近场探头测天线实际辐射效率。我们没有暗室就用了最土的办法在固定位置放一个蓝牙抓包器Ellisys BEX400然后慢慢调整天线在壳体内的位置看不同位置的 RSSI 变化。用 3D 打印了几个天线支架从水平到垂直试了几个角度最终把天线从紧贴电池的位置移到了壳体边缘悬空RSSI 提升了约 10 dB通信距离从 15 米提升到 30 米以上。这个探索过程虽然土但有效。给用 U.FL 外接天线的朋友一个建议打样时在 PCB 上留出天线座到壳体关键位置的调整空间用可拆卸的天线座连接器先测试最佳位置再决定柔性天线最终贴在壳体的哪个位置不要一上来就把天线焊死。4.2 认证那点事模块的预认证能省多少事U-blox NINA 系列最大的价值之一就是它有很多预认证FCC、CE、IC、MIC、KC 等。这意味着你可以在自己的产品上使用它的认证编号前提是你使用的天线类型必须在 U-blox 认证测试时覆盖的组合列表里NINA-B1 的 datasheet 里会列出可搭配的天线型号。你的产品结构不能对天线性能有明显劣化FCC 认可的参考设计有一定的容忍度但还是不建议走太偏。你需要确认你使用的模块固件版本和认证时一致。实际操作中只要天线型号在认证列表内、模块供电满足规格基本可以直接引用 FCC ID不用重新做射频认证这一项就能省下至少 8-10 万元的测试费用和 4-6 周的认证流程。不过你对产品的外壳、电池、排线这些做了大改最好还是做一次预扫确认辐射杂散没有超标。我们做过一次结果在 1 GHz 附近有个 -45 dBm 的杂散排查后是 FPC 排线在壳体里形成天线效应调整排线走向后就消掉了。4.3 批量测试的关键不是每个模块都要连手机测试量产时如果每台设备都拿手机 App 手动连一下测通信距离工作效率会低到啼笑皆非。正确做法是构建半自动测试工装我用树莓派 nRF52840 USB 适配器做了一个简单的 BLE 测试台测试脚本用 Python 的bleak库实现。每个待测设备上电后进入测试模式可以在广播包里加一个 test 标志位测试台自动扫描、连接、读取温度数据、控制 LED 闪几下然后把测试结果写入文件。整个过程每台设备大约 5 秒一条产线一小时能测 700 台。测试项包括广播 RSSI 是否在设定范围-60 dBm 到 -20 dBm视距离而定GATT 服务是否正确温度读数是否在环境温度 ±1 °C 范围内电池电压是否在正常范围如果 RSSI 远低于阈值很可能是天线焊接问题这时候需要补焊或换板。这套测试方案我们实际跑下来最明显的收益不光是产能而是能留下每台设备的完整出厂记录一旦市场上有批量问题可以回溯到具体某个批次、某台的测试数据排查起来方便太多。5. 实测数据汇总与调优记录最后把我们在开发过程中实测的一组关键数据放出来给各位做基线参考。项目测试条件实测结果说明广播距离空旷室外1.5 m 高度1 Mbps 传统广播80 m 可稳定发现使用 NINA 外置天线RSSI -85 dBm穿墙能力室内 24 cm 砖墙一道20 m 内连接稳定10 m 处 RSSI -62 dBm20 m 处 -78 dBm连接状态下电流连接间隔 30 mslatency 4平均 28 µA用功耗分析仪实测广播状态下电流广播间隔 250 ms0 dBm平均 96 µA含处理器唤醒开销休眠电流RTC 唤醒带 TMP117 关闭2.4 µACR2032 可续航 2 年以上纯休眠温度测量精度TMP117 高精度模式25 °C 恒温箱±0.06 °C与 Fluke 1524 参考温度计对比电池续航广播 250 ms 5 分钟连接一次 10 秒测温28 天实测测试用 240 mAh CR2032调优过程中印象最深的一个坑是广播间隔的功耗非线性。从 200 ms 调到 250 ms功耗居然只降了 10%但从 250 ms 调到 500 ms 突然降了 40%。原因是 nRF52 的广播事件功耗不只是射频开一下那么简单还包含协议栈的定时器唤醒、晶体起振如果用了外部 LFCLK 晶体等固定开销。所以评估广播功耗不要看数据手册的射频电流要实测整个系统特别是让你从 250 ms 想跳到 1 秒的时候先算一下用户体验能不能接受。另一个坑是温度传感器在 BLE 模块附近时的串扰。第一版 PCB 把 TMP117 放在了 NINA-B1 的背面中间隔了 0.8 mm 的板厚。结果模块在广播时温度读数跳了 0.3 °C一开始以为是电源噪声用示波器查了半天没找到问题后来才发现是射频能量直接耦合到了 I2C 信号线上导致传感器内部 ADC 参考被干扰。解决办法很简单把传感器挪到远离模块的位置I2C 走线包地处理测量值立刻恢复到 ±0.03 °C 以内的波动。如果你也在做类似的温度监控项目我的建议是前期多花点时间在功耗测量和环境适应性测试上这两项做好了后期量产才会顺。BLE 模块本身不会给你添太多麻烦真正的挑战永远在处理传感器和系统的边界问题上。希望这篇能帮你少踩几个我在项目里踩过的坑。