★ FEATURED ARTICLE 从暖通现场摸爬滚打过来的工程师几乎都遇到过同一个尴尬一边是控制器旁需要快速响应的本地温度用来做防冻、做闭环调节另一边是风管、水管、室外机组的远端测点要集中送到监控中心看趋势、跑能效。两路温度要是各拉各的线、各写各的代码系统准乱成一锅粥。这篇文章要聊的就是一套很典型的嵌入式温度监测方案用 PJ85718DM 做远端温度采集用 MK60DN512VLQ10 做主控把本地和远程测温统一进一个系统。你可能是刚接触嵌入式的学生也可能是做暖通自控项目的开发工程师甚至是现场做调试的技术员。只要你在搞 HVAC 或者类似的工业现场测温这篇内容都有参考价值。我会从需求分析、硬件选型、固件实现到现场调试按一条完整的项目主线讲清楚重点说为什么选这两个器件、怎么把它们的配合做到位。1. 从 HVAC 现场需求谈起一个系统为什么同时要“本地”和“远程”两路温度1.1 本地温度到底在解决什么控制问题暖通系统里的“本地温度”通常指的是控制器所在位置、或者紧挨着控制器机箱的那几个测点。很多人以为本地温度就是给人在面板上看个数字实际上它的核心价值是两个字闭环。比如新风机组冬天室外温度低表冷器里走热水一旦水温不够或者风量不足盘管就有冻裂风险。这时候控制器必须快速读取送风温度在极短时间内判断是否要停风机、关风阀、开足热水。这种实时性要求下数据不能依赖远程网络必须在现场就地完成采集和判断。MCU 自带的 ADC 或者板载数字传感器走的就是这条路径延迟低、可靠性高不依赖任何外部链路。另一个典型场景是变频风机柜。柜内温度如果过高功率器件会降额甚至炸机这里的本地温度通常用来触发超温告警和风扇调速。本地测温和远程测温在这套系统里的定位完全不同本地负责快、负责安全远程负责全、负责管理。搞明白这个区别再去选器件和写逻辑才不会把需求做拧巴。1.2 远程温度的数据价值比你想的要大远程温度在 HVAC 里一般指分布在各处的水管、风管、回风管、室外温湿度测点它们离控制器可能有几十米甚至几百米。这部分数据的主要用途不是直接闭环而是能效分析、趋势预警和集中管理。举个例子一个冷站有多台冷水机组各回水温度如果只看本地运维人员在值班室根本看不到全貌。把远程温度统一采集回来才能看出哪台机组负载偏高、哪条管路回水温差异常。这种数据虽然实时性要求不高秒级甚至分钟级都能接受但点位数量多、分布散单一传感器拉线成本很高这时候数字传感器的优势就体现出来了。另外远程温度还是故障诊断的“前哨”。管道温度如果出现规律性陡升陡降往往暗示水泵故障或者阀门卡滞。没有远程测点这些隐患要等设备坏了才会被发现。就这套方案而言PJ85718DM 承担的任务就是把这些远端测点低成本、稳定地接入主控让 MK60DN512VLQ10 既管本地闭环又管远程汇集。1.3 两类温度的工程特征差异把需求理清楚之后你会发现本地和远程测温在工程特征上完全不一样对比着看特别明显对比维度本地温度远程温度测点位置控制器机箱附近、PCB 板内管道、风道、室外机组实时性要求毫秒级到百毫秒级秒级到分钟级即可线缆长度几厘米到几米几十米到几百米抗干扰压力小主控内置采样即可大易受电机启停和电源波动影响故障后果直接影响安全控制和设备保护主要影响监控和运维效率这两种测温如果用同一套模拟采集电路去做远程长线传输容易引入压降和噪声成本还压不下来。所以业界比较成熟的做法就是把它拆成两条技术路线本地走 MCU 内置传感器或板载短距离数字传感器远程走类似 PJ85718DM 这样的数字接口远传器件。下面我要说的这套方案正是按这个思路搭的。2. 核心器件的分工逻辑PJ85718DM 管远端MK60DN512VLQ10 管全局2.1 为什么主控选了 MK60DN512VLQ10MK60DN512VLQ10 是一颗 ARM Cortex-M4 内核的微控制器主频 100MHz带 512KB Flash 和 128KB RAM封装是 LQFP100。在 HVAC 控制器这个场景里这个配置属于很合适的水准不算顶配但足够把显示、按键、通信、IO 控制、温度采集这些活儿同时扛起来留出的性能余量还能跑一些轻量的滤波和诊断算法。真正让我在项目里选它的原因主要是外设的完备度。一个暖通控制器通常需要的通信接口它基本都集成了多路 UART 可以接 RS485 做 Modbus、接调试口I2C 可以挂 LCD 驱动或者板载传感器SPI 可以带外部 Flash 或扩展 IO更重要的是它内置以太网 MAC加上一颗 PHY 芯片就能直接上以太网远程数据通道的选择一下子宽了。还有一点容易被忽略这芯片的引脚带 5V 容限能力在混合电平的 HVAC 控制板上设计起来会从容很多。很多现场传感器和外部模块还是 5V 逻辑如果 MCU 管脚不兼容就得加电平转换成本和故障点都会增加。MK60DN512VLQ10 在这方面给了我不少方便板子上少了好几个转换芯片调试也省事。2.2 远端测点交给 PJ85718DM 的原因PJ85718DM 这颗器件从命名和功能定位来看属于数字温度传感器这一类职责很明确在远端把温度变成数字信号通过接口送给主控。这类器件在暖通现场之所以受欢迎是因为它和模拟传感器比如 NTC、PT100有本质区别信号在传感器端就完成数字化传输的是数字电平而不是微弱模拟量。数字传输带来的直接好处有两个。一是抗干扰能力强只要保证接口电平不受破坏读到的数据就不会因为线缆耦合噪声而漂移二是一致性极佳出厂校准好的精度换一个传感器上去读数基本一致不像 NTC 那样每路都要单独标定。这对现场维护太重要了备件随便换不用重新校准。在具体接法上PJ85718DM 这类器件通常支持类似单总线或者两线制的数字接口几根线就能完成供电和通信。长线传输时注意在总线端加上拉电阻和适当的保护器件几百米的布线场景也能稳定跑。这里不展开太多硬件细节下一节会专门说。2.3 为什么不干脆全用模拟传感器这是个经常被问的问题。有些工程师会说NTC 多便宜ADC 又是 MCU 自带的干嘛要额外加数字传感器答案很简单现场环境不允许你把事情想得太理想。首先几十米到几百米的模拟信号线在 HVAC 现场往往和动力电缆走同一个线槽。电机启动瞬间动力线上的大电流会在模拟回路里感应出几十毫伏甚至更高的噪声而 NTC 的典型信号变化率可能只有几毫伏每度噪声直接就把测量精度干掉了。其次多路模拟采集要做一致性标定。每一路 NTC 的精度分散性、分压电阻的误差、ADC 的增益误差叠起来很可能超过正负 1 摄氏度。对于暖通能效分析来说这个误差范围是没法接受的尤其算温差的时候误差会翻倍。而数字传感器在出厂时已经把误差校准好了读数直接就是摄氏度省掉了所有标定工序。所以我这套系统的原则就是本地能用 MCU 内部或者板载数字传感器就不额外拉模拟线远端点位一律用 PJ85718DM 这类数字接口器件让数据一出传感器就是干净的“数字值”。这套组合既不牺牲精度又把现场布线和维护成本控制住了。3. 硬件实现细节电源、接口、隔离与传感器布局的取舍3.1 现场供电拓扑怎么搭HVAC 控制器的供电环境比较粗暴最常见的是 24V AC/DC 现场电源。我一般习惯先把现场电源经过整流滤波处理再用一颗 DC-DC 降到 5V然后通过 LDO 得到 3.3V 给 MCU 和数字传感器用。这个两级结构是多花了一点成本但能换来稳定的纹波表现。高压电机和变频器附近的电压波动非常剧烈DC-DC 的输入范围宽、效率高后级的 LDO 又能把高频噪声滤干净对 ADC 参考电压和传感器供电都友好。这里要特别提一个容易犯的错数字温度传感器看起来功耗很小就几毫安很多人就直接从 MCU 的 3.3V 引脚上拉一根线过去。这在短距离没问题但如果远端线缆有几十米线路压降和瞬时电流冲击会导致传感器供电跌落读数间歇性出错。正确做法是从主电源端单独引一路并在传感器端或者总线接入点就近放一个 100nF 陶瓷电容和 10uF 电解电容保证供电在长线上依然稳。还有一种极端但真实的场景传感器供电和通信共用一根屏蔽线远端设备断电之后总线还能正常工作。这种设计更省线但对协议有时序要求而且排查故障会麻烦一些。新项目我不太推荐直接上这种拓扑线缆省下来的钱往往不够填调试时间的坑。3.2 远程传感器接线与总线保护PJ85718DM 这类数字传感器在长线接法上有四个细节决定了稳定性上拉电阻阻值、线缆类型、末端保护、接地方式。上拉电阻是第一个关键。总线等效电容和线缆长度会拉低信号边沿的上升速率阻值太小会让总线驱动能力不足阻值太大又会让边沿变缓。常见做法是线长 10 米以内用 4.7kΩ 上拉线长到 50 米左右换成 2.2kΩ再长可以尝试 1kΩ但要注意驱动器的灌电流能力。实际项目中我习惯用 2.2kΩ 起步再根据示波器观察到的波形边沿微调。线缆方面我优先选双绞屏蔽线屏蔽层单端接地。一定不要两端都接地否则会在地电位差下形成环路电流反而把干扰引进总线。如果现场不得不和动力电缆共槽至少要保持 20 厘米以上的间距实在避不开就用铠装屏蔽线并做好屏蔽层的可靠接地。末端保护上我会在总线接入点放一颗 TVS 管和一颗小容量电容。暖通现场经常发生静电放电和感性负载启停的浪涌这两颗小元件能挡住绝大多数瞬时冲击。别省这个成本它一年能帮你少跑十趟现场。3.3 本地温度测量的两条实现路径回到控制器内部本地温度我通常同时做两条路。一条是用 MCU 内部自带的温度传感器它虽然不是为绝对精度设计的但用来监测 PCB 附近的环境温度、做机箱过热保护完全够用。读取方便不用额外接线缺点是误差比较大而且受芯片自身功耗发热影响绝对温度读数会偏高一些。另一条是在板载放置一颗数字温度传感器靠近可能发热的功率器件或者接线端子。这颗传感器离 MCU 有几厘米到十几厘米用于监测柜内局部热点。它的优势是精度高、读数接近真实空气温度而且和远端用的是同类型接口固件里可以复用一套驱动代码减少维护成本。在实际布局时有个经验传感器要远离变压器和稳压芯片这类热源否则测到的就是器件温度而不是空气温度。我在一块板子上吃过亏传感器贴着 DC-DC 电感放读数比旁边水银温度计高了五六度后来重新布局才解决。做样机阶段一定要用参考温度计实测对比一遍不能只看相对变化趋势。3.4 隔离设计上踩过的教训HVAC 系统里最容易被忽视的是通信隔离。现场总线 RS485 一旦和其他设备共地地电位差引起的共模电压会直接烧毁收发器甚至 MCU。我在早期版本吃过亏一块板子的 RS485 芯片在雷雨天气后损坏查了半天才发现是远端设备的地电位抬升通过屏蔽线倒灌进来的。所以新设计里我坚持三点原则。第一RS485 收发器必须用隔离电源和信号隔离芯片隔离耐压至少 2500V。第二总线 A、B 两端对地并接偏置电阻保证总线空闲时电平确定避免接收乱码。第三屏蔽层只在主控端单点接地远端设备端悬空或者通过 1MΩ 电阻接地。这套组合在多个项目里验证过故障率明显下降。以太网口的设计也是同样思路。用带隔离的 RJ45 连接器网线里的脉冲变压器本身就提供了电气隔离但要注意 PCB 布线上把变压器下方的铜皮挖空避免跨接电容耦合噪声。这些细节看起来小影响的却是整机的可靠性。4. 固件侧的工程化写法采集、滤波、校准与通信状态机4.1 温度采样的任务调度设计MCU 的主循环如果只服务温度采样事情就简单了。但在实际暖通控制器里还要处理按键、显示刷新、通信收发、IO 输出温度采集必须放进一个可调度的框架里。我常用的是一个简单的协作式调度用一个 1ms 的定时器做时基到对应的时间片就执行对应的任务。本地温度需要高实时性我放在 100ms 周期执行用于闭环控制远端温度采集速度受传感器转换时间和总线带宽限制我放在 1 秒周期执行满足监控需求即可。任务执行的先后顺序也很关键先采集温度再做控制运算最后刷新输出和通信缓冲区。这个顺序保证控制量永远基于最新的温度快照不会出现一拍延迟。代码上我会把每一个温度通道抽象成一个统一的结构体存放原始值、滤波值、状态和上次更新时刻。不管数据来自 MCU 内部传感器还是 PJ85718DM 远端总线都往这套结构里填后续控制逻辑只看这个结构体隔离了底层差异。typedef struct { float raw_value; float filtered_value; uint8_t fault_code; uint32_t last_update_ms; } temp_channel_t; #define TEMP_CH_LOCAL_BOARD 0 #define TEMP_CH_REMOTE_BUS1 1 #define TEMP_CH_REMOTE_BUS2 2这个抽象带来的好处在后期维护时特别明显加一个新的测点不需要动控制逻辑只要在采集层增加一路通道就行。4.2 滤波算法不是越复杂越好温度信号的特点是变化慢、但偶尔会有尖刺干扰。尖刺的来源很多继电器吸合释放、变频器开关、通信总线冲突都会在传感器接口上耦入瞬时噪声。针对这类信号我用的组合是“中值滤波 一阶惯性滤波”成本极低效果却很好。中值滤波专门打尖刺连续取五次采样排序后取中间值。这样即便是两三个点被干扰拉偏最终输出也不受影响。一阶惯性滤波则是用来平滑真实温度变化公式就一行filtered (uint16_t)((alpha * raw) ((100 - alpha) * filtered_prev));这里 alpha 取 20 到 50 之间较为平衡太大会跟随噪声太小会让系统对真实温度变化反应太慢。暖通管道温度不会突变我一般取 30。另外有一个细节值得说道温度变化率限幅。我会算本次滤波值和上次滤波值的差值如果每秒变化超过一个合理上限比如 2 摄氏度/秒就判定这次数据可疑维持上一次的输出。这个逻辑对传感器脱落、短路这类故障非常有效能避免控制系统被异常数据带偏。4.3 故障诊断与数据兜底可靠系统必须把故障当作正常状态来设计。我在每个温度通道里都定义了故障码覆盖了几种主要情况传感器无响应、数据超上下限、数据跳变率异常、总线通信超时。每类故障有不同的处理动作不是一律锁死输出。远端传感器如果连续几次读取失败我首先做重试重试 3 次仍然失败才判定故障。判定故障后系统不会让控制逻辑再用这个通道的旧值而是提醒现场人员检查接线。如果这个通道参与了重要的防冻保护我还会自动把对应风机或水阀打到安全状态宁可误动作也不能漏动作。故障记录我建议非易失保存。MCU 的 Flash 里留一段区域写环形日志记录故障发生时间、通道号、故障码和恢复时间。现场排查故障时这份日志能救命。我在好几个项目里就是靠日志里的时间戳反推出是哪个电机启停导致的干扰这种信息在现场靠肉眼是看不出来的。4.4 通信状态机的正确姿势主控和远程设备之间通信最容易出的问题是一方卡死导致另一方无限等待。我采用带超时的状态机来管理通信流程核心状态就五个空闲、发送请求、等待应答、校验处理、错误重试。每个状态都有明确的超时时间比如等待应答超时 200ms超时后进入错误重试状态。重试计数超过设定值就标记通道故障而不是无限循环。这套机制保证了单个传感器故障不会拖累整条总线上其他设备的轮询。typedef enum { COMM_IDLE, COMM_REQUEST, COMM_WAIT_REPLY, COMM_PROCESS, COMM_RETRY } comm_state_t;如果你用的是 Modbus RTU 这类现成协议状态机可以直接套在协议栈外面如果是自定义协议也要保证每一帧都有帧起始、地址、功能码、数据和 CRC 校验。我见过太多系统因为协议里少了 CRC等着现场出问题了才追悔莫及。5. 数据怎么到“远程”板级接口、协议封装与上位机对接思路5.1 远程通道选 RS485 还是以太网这取决于现场已有的基础设施。旧楼改造项目里现场已经敷设了 485 总线那就直接用 RS485走 Modbus RTU和原有的楼宇自控系统对接最省事。新建项目如果现场有交换机布线条件以太网是更好的选择带宽大、问题隔离容易、调试工具也多。MK60DN512VLQ10 两种接口都方便RS485 只需要外接一个隔离收发器以太网则需要一颗 PHY 芯片和网络变压器。我的习惯是主板把两个接口都预留出来用跳线选择工作模式。虽然多占了一点面积和成本但现场灵活性高也方便后期扩展。485 总线要注意节点数量限制和终端电阻。一般建议总线两端各接一个 120Ω 终端电阻匹配特性阻抗。节点数量多的时候收发器要选带 1/8 或 1/4 单位负载的型号保证能挂 32 个以上设备。总之别把楼宇里几十台控制器一股脑挂一条总线分几条支路出故障也好隔离。5.2 数据帧设计与寄存器映射远程数据传输最怕“自定义一切”。除非有特殊需求我强烈建议走 Modbus 协议把温度数据映射成保持寄存器这样任何上位机组态软件都能直接读不用开发专用协议解析。寄存器映射的规划原则是稳定和可扩展。我把每个温度通道分配一个固定的寄存器地址存放放大十倍的整数温度值这样既能保留一位小数又避免了浮点传输带来的字节序歧义。同时用一个状态寄存器集中反映每个通道的故障状态上位机读温度的同时顺手把故障位一并收走。寄存器地址 0x0000通道 0 温度值有符号整数单位 0.1 摄氏度 寄存器地址 0x0001通道 1 温度值同上 寄存器地址 0x0002总线状态字Bit0-Bit7 对应各通道故障码这里有一个很实用的细节设备地址要支持拨码设置或软件设定并保证掉电保存。车间里几十台控制器如果地址都是烧死的一个值现场维护会非常痛苦。5.3 上位机解析层与可视化对接上位机这边不管你是用现成的组态软件还是自己写一个小工具核心就三件事周期轮询、数据入库、异常推送。周期轮询的频率结合远端传感器的更新时间来定一般 1 到 5 秒一次足够了没必要 500ms 死轮又加重总线负担又没价值。数据入库推荐上时序数据库比如常见的 InfluxDB 这类轻量方案。温度数据本质上是带时间戳的序列时序数据库查询历史趋势和聚合统计都很顺手比塞进传统关系型数据库省心。可视化方面简单的趋势曲线加颜色告警基本能满足 90% 的暖通监控需求。还有一个很多人忽略的点要对“无故障但不更新”的数据做识别。某些传感器明明在线但数据一直维持在一个死值这大概率是传感器内部晶振停振或者总线地址冲突。在上位机做一次数据新鲜度检查一旦发现最后更新时间超过阈值就报警能避免很多模拟量“假正常”的坑。5.4 精度验证与校准方法系统联调时必须做一次全链路的精度验证。我的做法是用精密水银温度计或者已经送检过的标准温度计做参考把传感器和参考温度计放在同一个恒温环境中读取主控上报的温度值和参考值对比。加热和降温两个方向都测一遍记录滞回偏差。如果偏差超了预期而且每个通道偏差规律一致可以考虑在固件里加一个软件偏移量。这个偏移量通过配置参数下发而不是写死在代码里方便现场用调试工具调整。但要记住软件校准只能修正固定偏差不能解决传感器本身的非线性和长期漂移对精度要求高的场合还是得选更高精度等级的传感器。实测中我发现长线传输带来的延迟对读数精度几乎没有影响因为温度本来就变化慢真正影响精度的是传感器端的供电质量。只要供电纹波控制在 50mV 以内数字传感器的报告值就很稳定这也再次验证了前面强调的供电设计。6. 现场调试踩过的坑与经验清单6.1 上拉电阻引起的间歇性掉线第一次做远端传感器长线调试时我按习惯用了 4.7kΩ 上拉几十米的线缆接上之后传感器能读到数据但每隔几分钟就出现一次 CRC 校验错误。当时怀疑过传感器质量问题、也怀疑过时序配置问题折腾了小半天。后来用示波器看总线波形才恍然大悟上升沿变成了明显的斜坡在长线电容的影响下信号到达逻辑高电平阈值的时间已经接近甚至超过时序允许的窗口。把上拉电阻换成 2.2kΩ 之后波形边沿明显变陡CRC 错误完全消失。这个案例给我的教训是总线参数必须根据实际线缆长度调整不能抱着开发板上那套参数直接上现场。示波器是调试总线最有效的工具不要省这个时间。6.2 “机柜温度比现场高”的布局教训另一个反复出现的怪问题控制器报的本地温度总是比现场实测高四五度但显示值又非常稳定。一开始以为是 MCU 内部传感器偏差后来把传感器挪出机箱对比发现读数立刻恢复正常。问题根源就是传感器位置紧挨着 DC-DC 电感电感工作时的高频损耗和磁芯发热把局部环境温度抬高了。重新布局之后把传感器放在了出风口附近和功率器件保持了至少 5 厘米距离读数终于符合实际。这个案例让我养成了一个习惯任何温度采样点在定型前都要用热成像仪扫一遍板子确认没有潜在热源在旁边。6.3 强电启停导致读数跳变的综合处理暖通现场最恶劣的干扰源是大功率风机和水泵的启停。几次实测中电机一启动传感器读到的温度瞬间跳了十几度又恢复控制逻辑差点误动作。这个问题的根源是感性负载拉弧和浪涌电流在总线上感应出共模干扰。我采取的方案是多层级的硬件上总线接口加 TVS 和共模电感把传入的共模干扰先削掉一截软件上中值滤波把残留尖刺过滤掉逻辑上变化率限幅把最终的异常输挡在控制计算之外。三层下来再也没出现过误动作。现场干扰从来不是某一道防线能完全解决的必须硬件、软件、算法组合着来。6.4 全系统压力测试不可跳过还有一次项目交付前的教训单机调试时一切正常几十块控制器联网之后某些从站的温度数据开始出现偶发缺失。排查发现是总线上从站太多主站的轮询周期设置得太短导致响应超时重试进一步加重了总线负载。这个问题的本质是容量规划没做好而不是单个设备的问题。所以在项目出厂前我一定会做一次全系统压力测试所有节点全部在线按照现场真实的轮询周期连续跑 72 小时同时记录每个通道的更新成功率和故障码数量。低于 99.9% 更新成功率的系统不上现场。这个标准看起来严格但它能挡掉绝大多数“现场偶发问题”。6.5 一份可以直接抄的项目自查清单根据我这些年的经验整理了一份温度监测系统交付前的自查清单每次做类似项目我都会逐项过一遍检查项操作说明是否为关键项传感器供电纹波示波器测远端供电端纹波小于 50mV是总线波形边沿观察上升沿在时序窗口内是拉距测试按最长线缆规格做远端联调是各通道精度对比与标准参考温度计对比记录偏差是故障注入测试拔掉传感器、短路总线确认系统行为正确是连续 72 小时稳定性统计更新成功率不低于 99.9%是强电启停干扰测试现场大功率设备启停观察读数波动是备件更换测试更换一颗传感器确认免校准直接可用是这份清单帮我少走了很多弯路。你照着做至少能避开八成现场才暴露的坑。7. 一点个人体会做这套温度监测系统最大的体会是方案本身并不复杂真正决定成败的反而是那些看起来不起眼的工程细节。供电、隔离、滤波、故障兜底每一项单独拿出来都不难但你必须在一开始就当成正式需求去设计而不是等出了问题再补。最后再分享一个小技巧。调试远端传感器总线时不要急着上最终产品我习惯先用一块现成的开发板配合最小电路搭一个测试环境把线缆按照现场最恶劣的情况拉长再做一轮完整的时序和抗干扰测试。这个“最恶劣情况预演”能提前暴露绝大多数隐患比到现场再排查省太多时间。等这个测试环境跑稳了再移植到正式板子上基本上一次就能点亮。
阅读完成 · 觉得有帮助？
