HVAC 和嵌入式控制系统打交道的人十有八九都被同一件事烦过本地温度好测远程温度却让人头疼。前阵子我搭了一套温度采集方案主控用 PIC18F86J55本地和远程探头统一用 PJ85718DM 这款 I2C 数字温度传感器覆盖的场景就是空调机组、风柜、洁净室这类嵌入式和 HVAC 控制。这套结构不算复杂但把本地实时读数和远端节点轮询放到一起之后很多边界问题才开始浮出来。这篇文章就把从选型、电路到通信协议和现场调试的完整过程拆开讲给准备做温度监测的同行提供一个可以直接抄作业的参考。1. 先弄清本地和远程温度分别难在哪1.1 HVAC 场景里的“本地”和“远程”到底指什么在暖通控制项目里“本地温度”和“远程温度”并不是简单的空间关系而是两类完全不同的采集需求。我们惯常说的本地温度指的是主控板附近、机身内部、或者机组进出口这些距离控制器很近的位置。比如空调箱的回风温度、板式换热器的一次侧供回水温度、控制柜内部的机柜温度这些点离单片机一般不超过一两米信号可以走板内走线或者短跳线干扰相对可控。远程温度就完全是另一回事了。风机盘管末端的回风温度、新风机组里距离控制器几十米的送风温度、或者办公楼不同楼层的室温采集点这些探头和主控之间往往隔着风管、吊顶、竖井和长长的电缆桥架。距离从十几米到两百米不等而且路径上全是变频器、接触器、风机电机这些强干扰源。这两种需求放在同一个系统里最直接的想法是“本地用板载传感器远程想办法把模拟信号拉长线”但实际做下来会遇到很多问题。真正的难点不是测不准而是“很多点都要测、且每个点都要长期稳定可靠”。所以这套方案的设计目标很明确本地多点用 I2C 总线挂接远程用 RS485 组网轮询主控统一处理并把数据转换成可用的工程温度值。1.2 为什么模拟信号长线传输在这个场景下会翻车很多老项目的远程温度采集采用的是 NTC 热敏电阻加长线直连的方式例如 10k NTC 配合控制器内置的分压电阻。原理上没有错但现场一旦跑起来问题就会暴露。首先是引线电阻。NTC 的阻值变化范围往往有几 kΩ 到几十 kΩ理论上线阻影响不大但普通铜线在 50 米距离上的电阻大约在 0.5Ω 左右看起来可以忽略。不过现场常用的不是纯铜屏蔽线而是普通多股软线接头多、端子氧化线阻会随温度和湿度漂移。更要命的是如果传感器线缆和变频器输出线走同一个桥架感应出的共模干扰会直接叠加在温度信号上读数会出现低频跳动甚至完全失真。其次是校准一致性问题。每一路 NTC 的温度-阻值曲线都有个体差异厂家出厂精度通常在 ±1% 左右换算成温度可能偏差几摄氏度。如果系统用软件查表修正必须给每一路单独做标定大量部署时工作量极其可观。这也是我最终决定改用数字温度传感器的原因。PJ85718DM 这类 I2C 数字传感器直接把温度转换和数字化做在探头端输出的已经是工程单位标定的数据长线传输的是数字信号而不是模拟电平线阻和干扰的影响被大幅削弱。本地用数字总线远程用差分总线整条链路的抗干扰基础就从源头建立起来了。2. 两颗芯片各自要干的活与选型逻辑2.1 PJ85718DM 作为测温核心的硬件特征PJ85718DM 是这颗方案里的测温探头本质是一颗带有 I2C 接口的数字温度传感器芯片。它的数据手册上常见的能力包括内部集成温度传感器和 ADC测温范围宽广分辨率和精度足够覆盖 HVAC 场景数据通过标准的 I2C 或者类似 SMBus 的接口输出。实际项目里比较常用的几个特征从机地址可以通过引脚配置。PJ85718DM 这类芯片一般有若干个地址引脚通过接线方式可以设置多个不同地址这样同一条 I2C 总线上就能挂多个探头每个地址对应一个测点。片上自带温度报警比较器。可以配置上限和下限阈值当温度越限时 ALERT 引脚电平发生变化。这个功能在做 HVAC 超温保护时很实用不需要主控一直轮询。转换结果直接是数字量而且支持连续转换和单次转换两种模式。在方案里本地探头直接贴片在主控板上或者通过短排线引出挂在 PIC18F86J55 的 I2C 外设上远程节点则把同一颗芯片做在小板子上配合 RS485 收发器挂在差分总线上。芯片选型统一的好处是备件简单、驱动代码可以复用全项目只维护一套温度读取逻辑。从寄存器层面看这类芯片通常会有几个核心寄存器温度值寄存器高字节和低字节、配置寄存器、上限报警寄存器和下限报警寄存器。软件读取时先配置好工作模式再周期性读取温度寄存器换算即可。不同厂家芯片的寄存器偏移和位定义略有差别但整体思路是通用的。2.2 PIC18F86J55 在这条链路里的定位PIC18F86J55 属于某半导体厂商的 PIC18 J 系列单片机核心优势是外设丰富、引脚多、工作电压适合与数字传感器直接接口。我选它当主控主要看重三点内置多个串行通信外设。至少具备可复用的 MSSP 模块可以跑 I2C 主模式同时还有 EUSART 串口可以驱动 RS485。一片芯片同时管本地传感器总线和远程通信总线不需要外加协议转换芯片。丰富的 GPIO 和中断输入。PJ85718DM 的 ALERT 引脚可以直接接主控的 INT 输入用边沿触发中断来感知超温事件CPU 不必在轮询和报警检测之间频繁切换。宽工作电压和低功耗特性。整板统一 3.3V 供电传感器和外设无需电平转换。在整条链路里PIC18F86J55 承担的角色是温度数据的汇聚与转发节点本地通过 I2C 读取多个 PJ85718DM 的温度值远程通过串口加 RS485 收发器轮询远端节点的温度值然后统一进行滤波、换算和逻辑判断。如果系统需要联网还可以通过这个主控把数据上传到上位机或者云网关形成完整的监控闭环。2.3 和其他测温方案的横向对比这里做一个直观对比方便后续项目快速做技术选型。方案采集形式布线成本抗干扰能力多探头支持校准复杂度适合场景NTC ADC模拟信号长线传输低弱每个探头占用一路 ADC通道有限每路单独标定短距离、点数少的控制柜单总线数字传感器如 DS18B20 一类单总线数字协议低中等但时序要求严格理论可多挂但寻址和冲突处理麻烦芯片出厂校准线缆较短、点数不多的场景PJ85718DM 主控 I2C 本地 / RS485 远程本地 I2C 数字 远程差分数字中强本地同一总线多地址远程多节点轮询芯片出厂校准为主个别点做偏移修正HVAC 多点本地 远程混合场景实际项目里“传感器本身准不准”和“测出来的数值能不能稳定传到主控”是两个维度的问题。PJ85718DM 解决的是前者RS485 和 I2C 的链路设计解决的是后者。只靠一颗高精度芯片而不关心传输链路系统依旧会跳数这是很多新手项目容易忽略的问题。3. 硬件设计从传感器外围到主控最小系统3.1 PJ85718DM 外围电路与地址分配数字温度传感器虽然用起来省心但外围电路仍有几个要点需要注意。第一个是电源去耦。PJ85718DM 的测量精度很大程度取决于参考电压的稳定性。芯片供电引脚附近必须就近放一个 0.1uF 陶瓷电容条件允许再并联一个 10uF 电解电容做低频滤波。如果传感器所在的 PCB 上还有继电器、接触器这类负载必须把负载电源和传感器电源分开走线否则触点动作瞬间的电压跌落会让温度读数出现毛刺。第二个是 I2C 上拉电阻。标准 I2C 总线的 SDA 和 SCL 需要外部上拉常见阻值为 4.7kΩ。总线上挂的器件越多、线缆越长总线上拉能力越弱这时候需要适当调低阻值比如 2.2kΩ 甚至 1kΩ以保证足够快的沿速率。但阻值太小会增加总线驱动电流在低功耗场景要特别注意。我的习惯是先按 4.7kΩ 设计实测波形边沿不达标再往下降。第三个是地址引脚。PJ85718DM 如果有多个地址引脚可以在 PCB 上预留 0Ω 电阻或跳线帽把一个传感器固定到某个地址。本地板上的三个探头我通常用 A0/A1 组合设置为三个不同地址避免冲突。远程节点板上则把地址焊死每个节点对应一个 ID。实际布局时传感器芯片应尽量靠近被测对象。比如测回风温度芯片可以放在风道壁的金属探头套管里再引线回控制板而不要把芯片放在主板上用长线去够。芯片位置和测温对象之间的热阻越小温度响应越快滞后越小。ALERT 引脚的处理也值得一提。这个引脚通常是开漏输出需要外接上拉电阻之后接主控中断引脚。上下限阈值在软件里配置一旦温度越限PJ85718DM 会自动拉低 ALERT主控进入中断处理。这比软件轮询判断阈值要及时得多而且不占额外的 I/O 扫描周期。3.2 PIC18F86J55 最小系统和电源架构PIC18F86J55 的最小系统相对简单但也需要认真处理电源和振荡器。J 系列单片机工作在较低电压范围典型值是 3.3V。整个系统如果还有 5V 外围器件必须做电平隔离或转换。我这套方案里所有数字器件统一选 3.3V 版本包括 RS485 收发器这样不需要任何电平转换芯片接口最简化。主控供电建议采用独立的 LDO输入侧加防反接保护和 TVS输出侧按数据手册要求放去耦电容。温度采集系统的电源纹波直接影响 ADC 和传感器精度所以不要在电源上省成本。实测过有些板子温度读数周期性波动 0.3 摄氏度左右最后发现就是开关电源纹波耦合进了传感器供电换成低噪声 LDO 后问题消失。振荡器方面如果只是做温度采集内部振荡器完全够用。但涉及 RS485 通信时波特率误差要控制在 2% 以内内部振荡器在不同温度和电压下的精度不一定满足要求。稳妥做法是外部接一个晶振频率选择单片机数据手册支持的范围常见的是 8MHz 或 16MHz再通过 PLL 倍频到系统时钟。晶振旁边要放两个负载电容走线尽量短不要和继电器输出线靠太近。复位电路用标准的复位芯片或者内部上电复位即可。编程调试接口预留出来因为后续固件调试会不断烧写。所有数字芯片的 VDD 引脚旁都放去耦电容这是板上最基本但最不能省的一步。3.3 本地 I2C 和远程 RS485 的布线与隔离思路这个方案里有两类信号链路布线上要区别对待。本地 I2C 链路长度控制在半米以内传感器以 PCB 走线或短排线形式连接到主控。排线建议使用地线夹在 SDA 和 SCL 之间的排列方式比如 SDA-地-SCL-地-电源这样能减小信号间的串扰。如果本地探头必须离开主控板一段距离可以在传感器侧和主控侧都加上串联电阻来抑制振铃配合总线电容不超过一定值的规则。远程 RS485 链路则完全是另一套设计。RS485 是差分信号A、B 两根线传输相反电平具有很强的共模抗干扰能力。总线上每个节点都需要把收发器的 A、B 端接到总线注意极性不要接反。在链路两端各端接一个 120Ω 电阻来匹配阻抗避免信号反射。如果节点数量多、距离远还要考虑失效保护偏置电阻的配置让总线在空闲期间保持确定电平防止接收端误判。远程节点板的电源和主控之间建议做隔离或者至少做共地设计。以 HVAC 现场为例远端探头可能在另一个配电回路供电地电位差会造成共模电压过高轻则通信误码重则损坏收发器。最简单的处理是用 DC-DC 隔离模块给远端节点供电或保证所有节点统一从同一个 24V 电源母线供电且共地可靠。电源和通信线都加 TVS 管保护总线接口免受浪涌冲击。4. 软件流程从寄存器数据到稳定的温度值4.1 初始化流程与工作模式配置硬件搭好之后软件的起点是主控外设初始化和传感器配置。主控的 I2C 工作在主机模式波特率设置为 100kHz 即可。温度传感器对通信速率要求不高100kHz 在这种点数不多的场景下轮询周期完全够用。太快反而容易受 PCB 寄生电容影响增加信号完整性风险。串口方面RS485 波特率我建议保守一点先用 9600bps 或者 19200bps。温度数据量不大不需要追求高速率低速率的抗干扰能力更强。传感器配置的关键寄存器是配置寄存器。常见选项包括连续转换模式传感器一直做温度转换主控随时读取都能得到较新的结果适合需要快速响应的场景单次转换模式主控发出指令后传感器完成一次转换适合低功耗和轮询周期固定的场景分辨率选择一般芯片支持 9 到 12 位分辨率。HVAC 温度变化本来就很缓慢12 位分辨率能提供较高的数值稳定性。我的做法是设成连续转换模式每次读取前等待转换完成标志或者固定延时几毫秒保证读到的是有效数据。分辨率选最高档这样在小数位处理时能保留更充分的精度。主控上电后还要做一次传感器探测检查 I2C 总线上每个预期地址是否有应答。这个启动自检看似简单却能在现场省下大量排查时间。某个探头掉线时主控可以直接给出“本地址无应答”的提示而不是报一个毫无意义的大负数。4.2 温度寄存器的拼接与负温处理读取温度寄存器是整个软件的核心动作也是最容易踩坑的地方。PJ85718DM 这类芯片通常返回两个字节高位字节和低位字节。高位字节通常是整数部分和符号位低位字节存放小数的分辨率数据。以 12 位分辨率为例芯片可能将转换结果左对齐存放在寄存器中也就是数据手册所说的 12 位数据占高 12 位、低 4 位为 0。读取时先把两个字节拼接成一个 16 位有符号数再根据数据手册的定义右移对应的位数丢掉无效的低位。右移的位数取决于分辨率9 位分辨率右移 7 位10 位右移 6 位11 位右移 5 位12 位右移 4 位。右移之后得到的整数就是实际的温度值单位是摄氏度。关键点是符号处理。如果环境温度低于零度高位字节的符号位为 1拼接后的 16 位数为负数。如果直接在无符号数上右移得到的会是一个巨大数字换算出的温度完全不正确。处理方式有两种一种是把拼接值先转成有符号 short 类型再做算术右移另一种是先判断符号位再对补码做转换。这里一定要查清楚自己用的编译器对有符号右移的规则避免出在迁移工具链时行为不一致。具体到 HVAC 场景温度范围大多数在零下 20 度到零上 80 度之间。负温处理不常用但冷库、新风预热段的前端测温就可能用到。测过一台位于北方的机组冬季新风温度确实会掉到零下提前把负温换算写好比现场发现问题再补丁要舒服得多。4.3 软件滤波与滑动平均的取舍温度传感器读回来的数值即使硬件一切正常也不可能是理想中的平滑曲线。HVAC 现场存在气流扰动、压缩机启停、风机振动等因素会让温度值带上一些随机波动。软件滤波在温度采集中虽然不是高技术含量的事情但直接影响控制逻辑的稳定性。我总结的滤波策略是结合场景选温度变化慢但是控制逻辑对波动又敏感的地方优先使用滑动平均。也就是保留最近 N 次采样值取平均值作为当前输出值。N 的选取要平衡响应速度和滤波效果。HVAC 场景 N 取 8 到 16 比较合理对应采样周期如果是一秒一次那么输出值大约有 8 到 16 秒的滞后。对于房间温度和风管温度这种惯性大的对象这点滞后完全无感知还能滤掉细微波动。遇到偶发尖峰时滑动平均容易被一个坏值拉偏。我的经验是加一道中值滤波或者限幅逻辑当前采样值和上一次输出值之差绝对值超过一定阈值时先判定为异常数据用上一次输出值替代连续多次超限才认为温度真的发生了剧变。这样既保留了快速响应的能力又避免单次干扰造成控制误动作。滤波本身并不能提高传感器的测量精度只能提高数据的稳定性。测量精度问题必须要靠硬件布局和必要的校准来解决这个边界要在项目设计初期就明确。4.4 报警阈值与滞后设计PJ85718DM 的报警功能是硬件级的比起纯软件判断有着不可替代的优势。配置寄存器里可以设置上限和下限报警温度两个阈值各带有迟滞值避免温度在阈值附近反复跳变导致报警状态抖动。以 AHU 的防冻报警为例新风温度下限通常设置在 5 摄氏度左右。如果不做迟滞温度在 4.9 和 5.1 之间波动时报警会反复触发和释放。硬件比较器允许配置一个 1 到 2 摄氏度的迟滞窗口比如低于 5 度触发高于 6 度才释放这样现场就不会出现频繁报警的尴尬。主控的中断服务程序里只需要读取报警状态、记录时间戳、把事件上报具体动作交给上层逻辑。如果需要远程报警RS485 链路保留一个状态位把本地报警状态一起广播到总线上远程上位机就能同步感知。这套机制整体上占用 CPU 资源极小可靠性又比纯软件轮询强。5. 远程节点的组网与协议RS485 到底怎么挂多台设备5.1 为什么远程要换成 RS485 而不是继续拉 I2C这是方案设计里一个绕不开的问题很多人不理解既然本地已经用 I2C 挂了多个 PJ85718DM为什么远程不继续拉一根长 I2C 总线把所有探头串起来答案是 I2C 的物理层并不适合长距离。I2C 总线标准设计时对电容负载有明确限制总线上每增加一段线缆电容值就会上升。线缆电容太大时上拉电阻无法在时序要求内完成电平充放电信号的上升沿就会变缓最终导致通信错误。几十米以上的线缆电容即使在低速率下也容易突破规范上限。I2C 缺乏差分传输能力抗干扰性远不如 RS485。经过变频器、电机电缆附近的长线 I2C几乎必然收到共模干扰。I2C 是漏极开路结构地线电位差会直接把总线拉出逻辑错误。相比之下RS485 使用双绞线差分传输信号是 A、B 两线之间的电压差对地电位差天然不敏感传输距离可到几百米抗干扰能力强太多。远程链路采用 RS485 是工程上稳妥的选择。5.2 主从轮询协议的设计要点RS485 本身只是物理层标准它不规定通信协议。实际项目中需要自己定义或者选用现成的应用层协议包括 Modbus RTU 这类公开协议。参考现成协议的好处是代码资料多、排错工具成熟。基本的通信流程是主从轮询主控PIC18F86J55作为总线主机周期性发出查询帧每个远程节点分配一个唯一地址查询帧中包含目标地址和功能码目标节点收到后返回温度数据和校验码其它节点保持静默不允许主动上报。帧格式建议采用地址、功能码、寄存器地址、数据域和 CRC16 校验的结构。CRC16 必须认真实现温度控制系统中一个误码可能导致错误的温度显示或误动作CRC 校验是底线防御。轮询周期要根据节点数量和实时性要求设定。节点数量少、温度变化慢时可以设 1 秒轮询一轮节点数量多时适当拉长到 2 到 5 秒。不要在温度采集这种场合追求高速实时HVAC 系统的热惯性决定了 1 秒和 5 秒的区别在实际效果上微乎其微但慢轮询给总线留了更充裕的空闲时间故障率会明显下降。还有一个容易忽略的点发送数据时一定要正确控制 RS485 收发器的方向引脚。发送数据前拉高发送使能发送完成后钳住或拉低使能让总线回到接收状态。如果使能控制不及时会出现自己发的帧把自己的接收端唤醒造成数据回环打乱通信流程。5.3 总线故障时的容错和恢复没有任何现场总线能做到百分之百稳定。温度采集系统真正需要的是故障时的优雅降级而不是彻底罢工。主控侧需要实现超时重试机制。每帧请求发出后等待应答的超时时间通常设置为 50 到 200 毫秒。超时后重发两次连续三次无应答就标记该节点离线并在本地状态缓存中保留最近一次有效温度值。后续温度变化时逻辑层把离线节点标记为数据无效防止用旧值做控制判断。节点侧则要在从机程序中加入看门狗。万一通信链路异常导致设备状态混乱看门狗可以让节点自动复位重新回到监听状态。RS485 总线需要考虑总线空闲期的电平状态当总线上所有节点都处于接收状态时如果没有偏置电阻A、B 之间的电压差可能处于不确定区间接收端会不断收到乱码。解决办法是在总线上加入必要的失效保护偏置让空闲状态稳定为一个确定电平。从物理层面讲每个 RS485 节点板应该把手拉手的接线端子引出保证总线上是菊花链结构而不是星型结构。星型接法会产生阻抗不连续点长距离下容易出反射很多“时不时掉线、换一台就好”的疑难杂症往往就是拓扑问题。6. HVAC 现场的调试验证与避坑实录6.1 温度读数跳变先回去查电源和地整机联调时最常见的现象就是温度值跳变原本稳定的 23.5 摄氏度突然跳到 25 或者 21过一会儿又恢复。很多人的第一反应是传感器坏了或者总线干扰。但我在实际调试中遇到的情况相当一部分根源在电源和地上。变频器、水泵电机、电动阀执行器是 HVAC 设备里的主要干扰源。这些设备启停时电流冲击会在电源线上产生明显反冲。如果传感器电源和负载电源之间隔离不足或者 PCB 地线环路面积过大干扰就会通过电源通道进入传感器芯片让 ADC 转换结果波动。排查方法简单直接先用示波器看传感器 VDD 引脚的纹波启动电机时纹波是否瞬间放大。如果纹波明显优先加强供电滤波比如在传感器电源入口增加磁珠和更大的电容。其次是检查地线布局传感器附近不要有继电器线包的地回路数字地尽量单点连接。屏蔽线缆也很关键。RS485 通信线使用屏蔽双绞线屏蔽层应该在主控侧单端接地不要两端都接否则会形成地环路反而引入更大的共模噪声。这根线的处理在 HVAC 机房里尤其重要因为机房里的地线网络往往并不是绝对等电位。6.2 温度整体偏差的校准处理如果读数稳定但和标准温度计相比始终差个零点几度就要考虑校准和系统误差的问题了。数字传感器出厂时做过校准但在具体板子上传感器周围元件的自热、通风条件、探头安装位置都会引入额外误差。所谓校准就是把整个“传感器安装位置走线”视为一个系统找出它和真实温度之间的系统偏差。对 HVAC 温度采集我一般做两点校准。第一点选冰水混合物或者恒温槽温度接近 0 摄氏度的位置第二点选 50 到 60 摄氏度的温水中稳定后记录。两点之间做线性插值得到一条偏移修正公式。计算出的偏移量写入主控 EEPROM 或者远程节点存储区读取温度时在软件里做一次修正。需要提醒的是校准时的稳定时间远比大多数人想象的要长。探头放进恒温介质后至少要等 5 到 10 分钟让整个探头和芯片完全达到温度平衡再进行读数记录。如果探头上包了防水套管时间还要更长。很多校准结果不理想往往不是计算问题而是介质还没稳定就急着重写数值。6.3 远程节点偶发掉线的排查链路节点掉线是 RS485 系统里最让人头疼的一类问题因为它往往不是完全不能用而是几分钟或者几小时偶尔丢一个节点。排查这类问题要有顺序我通常按照链路从物理层到应用层逐步验证。第一拿示波器看总线上 A、B 两脚的差分波形。空闲状态应该有稳定的失效保护电平数据帧时波形边沿应该清晰没有明显振铃和台阶。波形模糊首先要查终端电阻是否安装到位、位置是否正确。我见过不少“现场总线波形一团糟”的案例最后发现是终端电阻只装了一个甚至装在了中间节点上。第二检查节点供电。远端节点如果由独立电源供电要量一下该节点工作时的电源纹波和地线电位差。通信线和电源线的线径是否过细、接线端子是否拧紧这些物理细节在电控柜里很容易被忽略。第三看协议层的超时和重试。主控日志里如果掉线时间总是固定在某一段时间多半和现场设备的周期性启停相关。比如某台风机每天上午启动后十分钟内必掉一个节点重启后恢复这就很可能是电源电压跌落导致的节点复位。解决办法是强化节点电源设计而不是盲目调高重试次数。最后要提一下地址分配。RS485 总线上每个节点的地址必须唯一否则两个节点同时响应主控请求总线上就会发生数据冲突。调试时最忌讳用“测试地址”一类的临时配置偶尔换错一个跳线就会引发说不出原因的通信乱码。结尾最后说一点个人体会。温度监测项目做多了我发现真正决定系统寿命的往往不是芯片的标称精度而是那些不起眼的工程细节探头安装位置是否合理线缆屏蔽层接地是否规范RS485 终端电阻是否装对位置地址跳线是否被胶布封死防止误动。这套 PJ85718DM 加 PIC18F86J55 的方案跑下来最让我满意的就是维护成本低坏一个探头换一块小板、拨一下地址跳线就行不需要重新标定整个系统。做温度监测稳定比花哨重要得多。