★ FEATURED ARTICLE 前阵子接了个环境监控的活儿要在一套暖通设备附近做温场监测节点分散、距离跨度大现场还有很多变频器和电动阀门。一开始我想得很简单温度嘛用个热敏电阻加ADC就能搞定。结果发现精度根本压不住、线路一长又容易被干扰最后折腾下来换成了 PJ85718DM 加 STM32F405RG 这套组合顺带把本地和远程温度监测的完整链路都跑通了。这篇文章就把整套方案从选型、硬件、固件到远程总线的实测经验原原本本写出来给做嵌入式和暖通设备监控的朋友做个参考。这套组合本质上解决的是两个问题一是把温度测量的精度和一致性提上去让数据可信二是把几十米甚至上百米外传感器节点的数据稳定地收回到主控端让数据可传。它的应用范围不局限于暖通空调像机房环境监控、仓储温湿度记录、医疗设备温度监测只要是需要“多点、分散、实时”采集温度的场景都可以借鉴这套思路。1. 为什么是 PJ85718DM 和 STM32F405RG选型背后的真实考量1.1 温度传感器的几种路线对比选传感器这件事看起来简单实际坑很多。现场最常见的三种路线是热敏电阻NTC、PT100铂电阻、以及数字温度传感器。每种路线都有它合适的位置但也有明显的短板。NTC 方案成本最低电路简单一个电阻加一只 ADC 通道就能采集。但 NTC 的非线性非常明显尤其在高低温两端需要做查表或多项式拟合才能勉强保证精度而且每只 NTC 的一致性一般批量更换时很容易出现同一批次温度偏差 0.5℃ 甚至更大的情况。在暖通这种需要长期稳定运行、后期维护可能由不同人经手的场景NTC 不算理想。PT100 精度很好但需要恒流源或电桥激励还必须有专用的模拟前端做调理电路复杂度和成本一下就上去了。对于常规环境温度监测来说有点“杀鸡用牛刀”。数字温度传感器是一条更省心的路。这次用的 PJ85718DM 就属于这一类的典型代表。它的优势很明显传感器和信号调理、模数转换做在了一颗芯片里直接输出数字量不依赖外部精密电路传感器本身对长线路的干扰免疫能力强不像模拟信号那样容易受衰减和共模噪声影响再加上器件内部带校准逻辑批量一致性好换料后不需要重新标定。1.2 F405RG 这颗 MCU 能顶什么角色STM32F405RG 是一颗基于 Cortex-M4 内核的 MCU主频可以干到 168MHz带硬件浮点单元内置 1MB Flash 和 192KB RAM。对于温度监测这种应用这个配置其实非常富裕但“大炮打蚊子”恰恰是有意的选择。富裕资源换来的是一整套系统的简洁性。F405RG 有多路 I2C 和多路 USART可以同时管理本地传感器和远程总线通信内置的 FPU 可以毫无压力地做浮点滤波算法不用像低端 MCU 那样担心算力不够大容量的 Flash 还可以保存校准参数、历史报警记录。更关键的是这颗芯片功耗并不高跑在较低主频时完全能够满足嵌入式设备对功耗的约束。选它还有一个实际原因开发环境成熟资料丰富固件库和底层代码可复用的东西很多。在工期紧、要求稳的项目里选一颗社区资料扎实的 MCU比选一颗性价比更高但资料稀缺的芯片要踏实得多。1.3 系统整体数据流整套系统的数据流可以分成三层来看。第一层是采集层由分布在各个位置的 PJ85718DM 负责把物理温度转成数字量。第二层是传输层本地传感器通过 I2C 与主控直接相连远程传感器节点则通过 RS485 总线汇聚到主控端。第三层是处理层STM32F405RG 把本地和远程的数据汇总后做滤波、阈值判断和告警逻辑最后通过显示屏、串口或以太网交给上层管理软件。这套架构的好处是本地采集和远程采集的接口统一收敛到主控端后续如果想把某个远程节点改成无线方案只需要替换对应的传输层模块采集层和处理层的代码几乎不用动。2. 硬件搭建从传感器贴装到总线布线的实战细节2.1 本地温度采集的接口设计先讲本地传感器的硬件接法。PJ85718DM 的数据手册里标注的是标准 I2C 接口典型供电电压 3.3V地址引脚至少支持 2 位地址选择理论上一条 I2C 总线上最多可以挂 4 颗同类芯片。这个数量对大多数本地采集需求来说已经足够了。实际电路设计时我保留了三点经验。一是 I2C 上拉电阻取值。标准的 10kΩ 上拉电阻在传感器距离 MCU 很近时没问题但只要连接线超过 30 厘米总线电容会明显增加此时建议换成 4.7kΩ。上位机监测波形的时候如果发现 SCL/SDA 上升沿明显变形优先降阻值不要一味缩短通信速率。二是电源退耦。每一颗 PJ85718DM 的供电引脚都要放一个 100nF 的旁路电容并且要尽量靠近芯片引线越短越好。温度传感器虽然不像射频电路对电源那么敏感但电源纹波会直接影响内部参考电压表现出来的就是温度读数在末位置跳动。三是传感器贴装位置。测量环境温度的时候传感器不要紧贴发热元件也不要放在通风死区。我第一版 PCB 把本地传感器放在了一个 DC-DC 降压电感的旁边结果温度读数始终比实际环境高 1℃到 2℃。后来把传感器挪到板边并远离电感读数一下就正常了。2.2 远程节点的硬件形态远程温度采集的硬件形态我做了两种方案实测下来各有适用场景。第一种方案是“远端传感器加裸露总线”的方式适用于距离较短、节点数量少的场景。直接把 PJ85718DM 通过 I2C 转 RS485 透传模块挂到总线上主控端用一条 RS485 轮询所有远端节点。但这个方案的缺点是每个远端节点不是一个完整的智能节点数据无法在远端做预处理一旦链路质量变差整个节点的数据都会受影响。第二种方案是“远端小型从机”的方式即每个远端节点用一颗低成本的 MCU 作为从机负责采集本地的 PJ85718DM把滤波后的温度数据通过 RS485 总线接口上报。我之前在某实验室的恒温箱监控项目里用的就是这种结构每年加起来有 32 个节点每个节点一根两芯屏蔽双绞线最远节点离主控超过 120 米数据依然稳定。如果项目需要在 50 米以上的距离布置温度点强烈建议采用第二种方案。从机端的 MCU 不需要很强只要能读传感器、能跑 Modbus 简单协议即可。2.3 电源与 EMIHVAC 现场最常见的两个坑暖通空调现场最让人头疼的两类干扰一种是电源纹波一种是变频设备带来的强电磁干扰。先说电源。远程节点的供电我之前用的是 24V 开关电源通过 DC-DC 降压到 3.3V。24V 到 3.3V 的压差较大如果选用耐压余量不足的 LDO发热会很明显。后来改成了凌特的超低功耗 LDO带使能控制的型号压差只有几百毫伏再搭配一颗 10µH 电感和 22µF 电容做后级滤波纹波控制在 30mV 以内。电源入口处必须加反接保护和 TVS 管防止现场接反线就烧设备。再说抗干扰。远程总线的通信介质是双绞屏蔽线屏蔽层单端接地接在主控端的信号地上不要两端都接地否则会形成地环路。布线时尽量避开变频器的高压电缆或者至少保持 30 厘米以上的间距。如果现场空间实在受限可以在 RS485 的 A/B 线上各加一只 5.6V 的 TVS 管再串 10Ω 的电阻能有效吸收瞬态干扰。3. 固件侧的采样、滤波与校准把原始数据变成可信温度3.1 PJ85718DM 驱动基础PJ85718DM 驱动起来比想象中简单。上电后主控通过标准 I2C 写配置寄存器把转换位数设置为 12 位具体寄存器地址以手上这颗料的数据手册为准不同批次可能略有差异然后用一条读命令就能拿到 16 位的原始温度数据。对于 12 位分辨率的配置原始数据的最高位是符号位剩下的位以 0.0625℃ 为 LSB。把原始值转换成实际温度的公式很简单温度值 原始值 × 0.0625。举个例子读取到的原始值是 0x0190十进制 400对应的温度就是 400 × 0.0625 25℃。驱动程序里有一点需要特别注意I2C 通信失败后不能当作读取失败直接丢弃更不能死循环重试。暖通现场的总线上偶尔会有一次长帧干扰导致响应超时合理做法是连续重试最多 3 次仍然失败就使用上一次的有效值并把故障计数器加一。这个计数值在超过阈值后将对应节点标记为故障节点在系统界面上显示报警。3.2 三种滤波算法的取舍直接读 PJ85718DM 的原始值在环境稳定的情况下读数已经很稳了但遇到压缩机启动或门开合的瞬间数据还是会有几个 LSB 的跳动。如果你直接用原始值去触发阈值报警很容易出现误报。这里就需要在软件层做滤波处理。我实测对比了三种常见的滤波算法。第一种是限幅滤波。思路是如果当前读数与上一次读数之差超过了设定的最大变化量比如 0.5℃则认为本次读数异常直接丢弃。这种算法适合抑制偶发的毛刺缺点是无法平滑缓慢的漂移。第二种是滑动平均滤波。维护一个长度为 N 的环形缓冲区每次取平均值作为滤波结果。N 越大平滑效果越明显但滞后也随之增大。实测下来环境温度监测用 N8 的滑动平均既能明显抑制噪声滞后也只有半秒不到完全够用。第三种是一阶低通滤波也就是大家常说的 RC 低通数字实现。公式是 Y(n) a × X(n) (1 - a) × Y(n-1)其中 a 越小滤波越强但响应越慢。在暖通场景里温度本身变化很慢我取样周期是 1 秒a 取 0.2 时数据响应大约 5 秒达到 95%舒适度体验正常不会让使用者觉得“温度半天不动”。实际工程项目里我通常会把三种方法组合起来用先限幅滤掉毛刺再滑动平均平滑输出最后的输出值基本就是一条非常稳定的曲线。如果你不希望温度显示“一动不动”可以把滑动平均的窗口调小一些或者在界面上直接显示一阶低通后的实时值视觉反馈会好很多。3.3 软件校准消除偏置和批量漂移传感器出厂标称精度通常是 ±0.5℃但实际元件、装配、贴装位置都会引入额外的偏置。系统正式投用前建议做一次软件校准把偏置补偿进最终结果。最常用的方法是两点校准。取两个稳定的温度点比如冰水混合物0℃和精密恒温槽的 50℃ 点分别记录传感器的实测值。然后按线性校正公式 y k × x b 算出 k 和 b把这两个参数存储到 MCU 的 Flash 配置区。举个例子实测在 0℃ 时读数为 0.8℃在 50℃ 时读数为 51.2℃则斜率 k (51.2 - 0.8) / (50 - 0) 1.008偏移量 b 0.8℃。校正后的温度值 原始读数 × 1.008 - 0.8。这样处理后40℃ 附近的读数误差能控制在 0.1℃ 以内对整个温场监测系统来说精度已经完全够用。4. 远程温度怎么传RS485 组网、Modbus 轮询与断线处理4.1 为什么远程用 RS485 而不直接拉长 I2C有人可能会问既然本地传感器用 I2C那远程直接两条线把 I2C 拉长行不行答案是几乎不行。I2C 是开漏极输出的总线结构要求上拉电阻才能工作。总线电容一大信号上升沿就严重变钝通信速率必须压低而且 I2C 本质上只适用于板级或短距离通信几十米距离几乎是禁区。就算你侥幸把速率压到 10kHz 通信成功现场一旦有变频器启动共模噪声就会把信号彻底淹没。RS485 是差分传输抗共模干扰能力强的多。标准 RS485 收发器的共模输入电压范围通常是 -7V 到 12V只要收发器两端处理得当1200 米的通信距离都有余量。更重要的是RS485 是多点总线结构一条总线上挂 32 个甚至更多节点都很方便只要给每个节点分配不同的地址即可。4.2 主从协议与地址编排远程通信协议我直接选了 Modbus RTU。原因很简单这套协议在工业设备里被广泛使用调试工具多市面上现成的触摸屏、上位机组态软件基本都原生支持 Modbus RTU节省开发量。主从架构里STM32F405RG 充当 Modbus Master每个远端节点是 Slave地址通过拨码开关或从机固件里的配置区设置。通信参数固定为 9600bps8 数据位、1 停止位、无校验。9600bps 虽然不快但远程节点数量多的时候更稳定调试也更方便。功能码主要用 03读保持寄存器和 06写单个寄存器。每台远端的温度值存放在保持寄存器地址 0x0001 处主控每隔 N 秒轮询一台从机读取它的温度值。随后解析报文把原始值除以 100 得到浮点温度远端发送整数型温度值保留两位小数显示在界面上正常存储到数据库也正常。Modbus RTU 的帧格式非常固定接收侧只需要按状态机解析空闲状态等待第一个字节收到后启动接收超时定时器按从机地址、功能码、数据区、CRC 校验的顺序处理最后核对 CRC 无误后再回传响应。4.3 断线和错帧处理远程通信最怕的不是慢而是出错。我实际调试中遇到过一个非常典型的故障某台从机的 RS485 端子松动总线处于半断开状态主控发一帧请求后从机不回但总线上又时不时出现偏置电压主控把这种噪声误当成应答帧的数据。这种情况处理起来有两条路可走。一是在主控端设置严格的接收超时比如从发送完最后一字节开始计时超过 100ms 没有收到合法帧头就判定本轮轮询失败直接放弃等下一轮再试。二是做连续失败计数如果同一节点连续 3 次轮询失败就直接上报“节点离线”告警不等到物理断线才发现。还有一个容易忽略的问题总线上只有一个主站时从机的发送方向使能一定要严格控制。如果某台从机的发送使能误触发会一直占住总线导致其他所有从机都没法应答。调试时如果发现“总线上只有一台从机掉线但其他从机也全部无响应”优先怀疑是不是那台掉线从机的串口 TX 电平异常把它的 485 芯片发送脚强制拉低再测试。5. HVAC 场景的工程化验证精度、稳定性和故障排查5.1 温度精度验证方法硬件的坑填完之后接下来就是系统投运前的精度验证。我的做法是把所有温度传感器放在同一个温场里参考标准用一个经过计量校准的水银温度计或恒温槽。验证步骤分两步。第一步做 0℃ 和 50℃ 的定点校准如果发现某一路传感器与其他路偏差超过 0.3℃ 以上就用前面提到的两点校准参数单独修正。第二步做全量程验证将传感器放入恒温槽从 0℃ 开始每隔 10℃ 记录一次实际读数和标准值连续记录 5 次取平均值。实测下来修正后的全部节点在 0℃ 到 60℃ 范围内最大偏差基本能控制在 0.2℃ 以内。这个精度在暖通空调的温控逻辑里已经绰绰有余毕竟普通空调温控器的回差本身就有 1℃。5.2 长期稳定性观察精度过了不代表系统可以马上交付。我会再做一次 24 小时连续运行试验每秒记录一次所有节点的温度用来观察是否有周期性漂移或者通信毛刺。长期稳定性的观察重点不是某一个时刻的读数而是曲线的趋势。如果某个节点在凌晨高速运行后温度读数突然跳高了 0.5℃然后又慢慢回落多半是电源在夜间压降增大后导致传感器供电不稳需要在电源侧加一级延迟恢复电路。如果某个节点的数据在每天固定时间出现偶发中断则可能是该时间段现场有大功率设备规律性启动需要调整 RS485 总线的终端电阻配置或屏蔽层接地方式。整体稳定的判断标准是连续 24 小时内的最大波动不超过设定精度的 1.5 倍。比如系统的目标是 ±0.5℃那么 24 小时内任何节点的温度波动都不应该超过 0.75℃ 才算合格。5.3 常见故障排查表项目落地后一线运维人员最需要的不是长篇代码分析而是一张能按图索骥的排查表。我整理了这次项目里遇到过的几类典型故障供各位参考。现象可能原因处理手段本地传感器读数固定不变传感器 I2C 通信失效或芯片损坏检查 I2C 地址配置、上拉电平换一个传感器验证远程某节点偶发超时总线距离过长、终端电阻未匹配在总线两端加 120Ω 终端电阻降低波特率远程所有节点同时无响应主控端 485 收发器损坏或总线短路用 USB 转 485 工具单独测试总线检查 A/B 线序温度读数整体偏高传感器贴近发热源或校准参数失效检查传感器位置重新校准读数跳变但通信正常电源纹波过大或 TVS 管损坏检查电源纹波更换 TVS 管这套排查表在实际项目中帮助很大尤其是给现场运维人员培训的时候建议把排查原则写进维护手册。做完整套系统之后我最大的体会是温度监测项目表面上是硬件和代码的堆叠本质上是对精度的把控和对稳定性的妥协。先决定传感器和主控再决定总线协议最后做滤波和校准按这个次序推进能少走很多弯路。PJ85718DM 加 STM32F405RG 这套组合已经把精度、成本、开发效率平衡得比较好了在暖通和嵌入式环境监控领域很值得一试。条件允许的话建议在样机阶段留出串口调试接口和一个本地状态指示灯现场出问题的时候能省大量时间。
阅读完成 · 觉得有帮助？
