企业官网建设流程全解析

我团队前阵子接了个医疗级体温监测贴片的预研需求，客户点名要用 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 基于 nRF52832，NINA-B3 基于 nRF52840，ANNA-B1/B2 也是基于 nRF52832 但封装更小。

我们项目最终选的 NINA-B1，核心考量三个维度：

第一是功耗。体温贴要用 CR2032 纽扣电池供电，目标续航至少 7 天。nRF52832 的峰值 RX 电流约 5.4 mA，TX 电流约 5.3 mA（0 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 的 SHT30，TMP117 更适合体温贴：

TMP117 在 -20 °C 到 50 °C 范围内典型精度 ±0.1 °C，I2C 数字接口直接输出 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 的参考设计里已经包含，照抄即可。

功耗预算方面，我做了一个粗略的表，供参考：

算下来如果广播间隔设成 1 秒、测量周期 5 秒，CR2032（标称 220 mAh）理论上能撑 30 天以上。但实际续航会打折，因为电池内阻会随放电增大，低温下容量也会下降，所以最终产品标称续航 10-14 天比较合理，留出足够的余量。

2.3 PCB 布局的黄金法则：射频、传感器、电源三分天下

把 NINA-B1 画进电路板，布局上最关键的是把三种功能区域物理隔离：

射频区：模块的天线区域要挖空铜皮，天线下方不要走任何信号线，净空区至少保证 10 mm 以上。U.FL 连接器到天线之间的微带线阻抗要控制在 50 Ω，线宽根据板厚和板材的介电常数计算（我们用的 1.6 mm FR4，50 Ω 微带线大概 0.35 mm 宽）。这个细节最容易被忽略，我见过有人把天线馈线走到 BLE 芯片底下还盖了地铜，信号直接被地吸收了，通信距离从 50 米缩到 5 米。

传感器区：TMP117 要尽量靠近被测物体，不要在它周围铺太多铜箔，避免导热导致测量偏差。热阻路径上也不要有大功耗器件——BLE 模块发信时虽然电流很小，但瞬间功耗会带来局部温升，传感器离模块至少 2 cm 以上才不影响测量。我们实际的柔性板设计里，传感器在末端，模块在硬板端，物理距离超过 3 cm，实测对体温精度的影响可以忽略。

电源区：电池座附近放主滤波电容，负载开关尽量靠近传感器侧，电源线和地线走星形拓扑，避免传感器和射频共享地回路引起的地弹干扰。

3. BLE 通信链路设计：广播包、GATT 服务和低功耗策略怎么配合温度数据的节奏

模块和硬件都定了，接下来是固件和协议层面的设计。这块不光是调通，还要把温度数据流和 BLE 的通信节奏对齐。

3.1 广播包设计：让网关和手机都能快速识别你的温控设备

温度监控器的数据发送有两条路径：一条是手机 App 直连读取（适合现场查看），另一条是 BLE 网关批量采集（适合医院病房、冷链仓库这种多设备场景）。

所以我们广播包里同时支持两种协议：设备信息和温湿度数据。

标准做法是配置 3 个广播/扫描响应字段：

1. Flags：标准 BLE 广播标志，决定广播类型和是否可连接。温度监控设备设置成可连接广播（General Discoverable Mode），因为需要支持手机主动配对。

2. Complete Local Name：放设备名。我们定义成 "TempTag-XXXX"，后四位是 MAC 地址末四位，方便在大量设备中区分。

3. 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 Service（HTS, 0x1809）和 Battery Service（BAS, 0x180F），再结合我们自己的私有需求，最终定义了三个 Service：

• Health Thermometer Service（HTS 0x1809）：温度测量特征（Temperature Measurement, UUID 0x2A1C），Notify 属性；温度类型特征（Temperature Type, UUID 0x2A1D），告知传感器放在哪（口腔/腋下/皮肤表面）。
• Battery Service（BAS 0x180F）：电量特征（Battery Level, UUID 0x2A19），Read/Notify。这个服务标准手机都能识别。
• Vendor Service（自定义 128-bit UUID）：放校准参数、设备序列号、固件版本、测量间隔配置等厂家特色数据。

这里有个设计陷阱：HTS 的 Temperature Measurement 特征按规范是 Notify-only 的，有些手机 App 框架第一次连接时一定要先 Read 一次才能订阅 Notify。如果固件把这个特征设置成了 Notify-only，App 端就无法在 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 ms（BLE 规范最小值）会非常耗电（每次广播约 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 等）。这意味着你可以在自己的产品上使用它的认证编号，前提是：

1. 你使用的天线类型必须在 U-blox 认证测试时覆盖的组合列表里（NINA-B1 的 datasheet 里会列出可搭配的天线型号）。
2. 你的产品结构不能对天线性能有明显劣化（FCC 认可的参考设计有一定的容忍度，但还是不建议走太偏）。
3. 你需要确认你使用的模块固件版本和认证时一致。

实际操作中，只要天线型号在认证列表内、模块供电满足规格，基本可以直接引用 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. 实测数据汇总与调优记录

最后把我们在开发过程中实测的一组关键数据放出来，给各位做基线参考。

调优过程中印象最深的一个坑是广播间隔的功耗非线性。从 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 模块本身不会给你添太多麻烦，真正的挑战永远在处理传感器和系统的边界问题上。希望这篇能帮你少踩几个我在项目里踩过的坑。