前阵子做某个设备控制柜升级，要求不但要测控制板自身的板温，还要把风管送风温度和回水温度一起采集上报。刚开始我习惯性想用两路热敏电阻加运放，后来换了个思路，用 PJ85718DM 这颗本地/远程双通道温度芯片配合 STM32F423RH 主控，把整个温度链路统一成一路 I2C 处理。这个方案在嵌入式设备和 HVAC 控制器里都挺有代表性，分享出来给同样在捣鼓温度采集的朋友参考。

本文会把这个项目从芯片选型、硬件连接、软件配置到现场校准和问题排查完整拆开讲，重点说清楚“本地温度”和“远程温度”为什么不能简单当作同一个量来处理，以及双通道测温芯片怎么替我省掉一路模拟前端。适合正在做 HVAC 控制器、嵌入式设备监控或者想了解数字温度传感器方案的人。

1. 项目定位：为什么HVAC和嵌入式都绕不开本地/远程双通道测温

1.1 本地温度与远端探头温度的本质区别

很多人一开始觉得，温度嘛，不就是读个传感器值。但真正做项目就会发现，控制板自己所在位置的温度和被测环境或者管道的温度是两套逻辑。

本地温度指芯片、控制器、功率器件周围的温度，它体现的是设备自身工作状态。PCB 上局部过热可能意味着电源老化、Mos 管热阻超限、散热风道堵塞。这个温度必须紧贴热源测量，所以传感器要做在板子上，响应要快，尺寸要小。

远程温度指不在电路板上的温度点，比如 HVAC 系统的送风温度、回风温度、室外补偿温度，或者工业设备冷却液进出水温度。这类测点一般在风管、水箱、管道里，距离主控板可能从几厘米到几十米不等。它的变化主要由被控介质决定，跟控制板自己的工作状态没有直接关系。你不能因为板子温度正常就推断风管温度正常，反之也一样。这是我在项目里踩过最明显的坑：客户最初只在板子上放了一颗测温芯片，以为够用，结果整机测试时发现回风温度根本没法监测，又回去加探头。

嵌入式应用也有类似情况。比如变频器里，IGBT 模块温度和风扇出风温度是完全不同的监测目标，前者用来做功率降额保护，后者用来判断散热风路是否堵塞。这两种需求放在同一块板上时，就需要独立的本地通道和远端探头通道，两个量各走各的阈值和告警逻辑。

1.2 一颗双通道测温芯片替代两套采集电路

传统做法是板载一路 NTC 热敏电阻，外加一路远端 NTC 探头。NTC 本身是非线性的，每路都需要一个分压电阻和一个 ADC 通道，还得在软件里做查表或多项式校正。如果探头距离远，引线电阻也会引入误差，做工业级产品还得考虑开路检测，整体处理起来很麻烦。

PJ85718DM 这类本地/远程双通道数字温度芯片，把温度采集、模数转换、电压比较和开路检测全部集成到一颗小器件里。本地通道靠内置 PN 结传感器测量芯片自身温度，远程通道通过 D+、D- 引脚外接一个小信号三极管，三极管的 B、C 极短接当二极管用，温度变化会让 PN 结压降和电流比发生变化，芯片内部电路根据这个关系解算出远端温度。整个链路只需要一个外部探头元件，没有运放、没有 ADC 通道、没有分压电阻，温度值直接通过 I2C 读出来。

我对比过 NTC 方案和这个方案的物料成本。NTC 探头确实便宜，但分压电阻、滤波电容、ADC 引脚占用和软件线性化都是隐性成本，更麻烦的是每路都要单独标定。PJ85718DM 方案里昂贵的部分是芯片本身，但远程探头只要一颗贴片三极管，价格很低，坏了现场换一个几毛钱的元件就行，精度由芯片保证，一致性比自己做模拟调理电路好太多。对于 HVAC 这种需要长线缆、多批次生产、现场可维护性要求高的场景，这个方向明显更省心。

2. 硬件设计：STM32F423RH与PJ85718DM的连接与布局

2.1 为什么选STM32F423RH这颗主控

温度监测本身对单片机的要求并不高，任何带 I2C 的单片机都能做。但这个项目不是单纯做测温，还要承担显示、通信、数据记录、报警输出这些任务。我选择 STM32F423RH 的原因很直接：LQFP64 封装，板子面积不会很大，Cortex-M4F 内核跑到 100MHz 应付后续更复杂的控制算法也够用，外设覆盖了 I2C、UART、定时器、RTC、加密模块，几乎不用给测温功能单独配任何辅助器件。

具体到测温链路，STM32F423RH 上其实只占用了三类资源：一路 I2C 接口，一个外部中断引脚接收 ALERT，一个基本定时器做采样节拍。剩余的大把外设可以留给触摸屏、RS485 通信、PWM 风机调速或者无线模块。这种“少占用、多预留”的选型思路更适合量产产品。如果只盯着“读温度”这个单一功能挑 MCU，后面加功能时往往会发现引脚不够或者内部资源不足，改动波及整个硬件设计。

还有一点是这个系列的低功耗模式做得比较完整。HVAC 现场经常要求设备在待机时低功耗运行，STOP 模式下能通过 RTC 定时唤醒或 ALERT 引脚中断唤醒，PJ85718DM 的ALERT输出可以直接作为外部唤醒源，这样待机功耗能压得比较低，同时温度超限时又能立刻把整个系统从休眠里拉起来，不需要软件轮询。

2.2 PJ85718DM引脚功能与外围电路搭法

PJ85718DM 的常规引脚包括 SDA、SCL、A0、A1、ALERT、D+、D-、VDD、GND。A0 和 A1 用来设置 I2C 地址，在同一条总线上多挂几颗传感器时很有用。比如 A0=0、A1=0 是一个地址，A0=1、A1=0 是另一个地址，通过引脚上下拉电平组合，最多能区分四个地址。

SDA 和 SCL 需要接上拉电阻，我习惯用一个 4.7kΩ 的上拉电阻连到 3.3V 电源，然后接到 STM32F423RH 对应的 I2C 引脚上。芯片工作在 2.7V~5.5V 范围，为了方便逻辑电平匹配，我把传感器供电直接用主控侧的 3.3V，避免电平不匹配导致通信不稳定。

D+ 和 D- 是远程探头接口。远程探头不是接热敏电阻，而是接一颗三极管，比如 2N3904 这种小信号 NPN 管，把基极和集电极短接，形成一个二极管结构，发射极接芯片的 D+，基极-集电极短接点接 D-。注意具体极性要以 PJ85718DM 手册为准，接反的话远程温度读到的基本就是固定偏移或者完全不对。为了降低线缆上的噪声耦合，我还在 D+、D- 之间加了一颗几十 pF 的瓷片电容，位置尽量靠近传感器芯片侧，对现场高频干扰有一定抑制作用。

VDD 和 GND 之间我放了 100nF 加 10μF 两颗电容，小电容滤高频，大电容吸收瞬态电流波动。如果传感器离主控电源稍远，这个组合基本能保证参考电压稳定。整体看外围电路非常简洁，这是双通道数字传感器相比模拟方案最大的优势。

2.3 远程探头的走线与端接工艺

远程温度探头经过长线缆连接到 HVAC 风管内部时，走线方式直接决定读数能不能用。

我试过用普通两芯线拉三米，结果远程温度在小数点后一位跳动，严重时整数值都会漂。后来换成屏蔽双绞线，把屏蔽层在控制板这一端单点接地，问题明显改善。双绞线的两根差分信号线上感应的共模噪声基本一致，传感器芯片对 D+、D- 之间的压差做差分测量，共模噪声会被抵消大部分。屏蔽层单端接地则可以避免屏蔽层上形成地环路电流，防止把噪声进一步耦合进信号线。

探头端的焊接也要注意。小信号三极管引脚直接焊到双绞线上，最好套热缩管固定并做应力释放，避免现场的振动导致金属疲劳断裂。我在某个项目里遇到过温度读数每隔几分钟跳一下，后来发现就是探头引脚在风管振动下产生了微小的接触电阻变化。

线缆长度方面，这种双通道传感器方案通常能支持 1~3 米的远程探头线，再长就要看芯片具体能力。HVAC 风管测点离控制柜一般在这个距离以内，所以非常适合。如果是几十上百米的测温需求，更聪明的做法是就近放一个小变送器，再通过 RS485 总线把数据传回来，硬拉一条十几米的模拟探头线未必划算。

3. 软件实现：I2C读取、数据换算与报警逻辑

3.1 I2C初始化与寄存器配置要点

STM32F423RH 的 I2C 外设初始化不算复杂，但有几个细节会影响稳定性。GPIO 要配置为开漏输出，复用功能选 I2C；然后在 I2C 初始化结构体里设置时钟频率，我通常设置 100kHz 标准模式而不是 400kHz 快速模式。

原因也很实际：远程探头线缆哪怕只有三米，线间电容也会拖慢信号边沿，快速模式下上升沿变缓，通信可靠性会下降。温度数据本身的更新速率并不高，100kHz 已经完全够用，换取的是更强的抗干扰能力和更长的线缆容差。现场环境变频器多、干扰大的时候，慢一点反而是最优选择。

PJ85718DM 上电后一般需要做几件事：

• 设置转换模式，让芯片按固定周期自动转换。
• 设置转换速率，根据现场对温度响应速度的要求来定。
• 设置本地和远程温度的上下限阈值寄存器。
• 打开 ALERT 输出和状态位，启用中断感知。

这些配置全部通过写配置寄存器完成。注意每写一次寄存器后，最好读回来验证一下，防止通信传输过程中被干扰吃掉。我在批量调试时发现过 I2C 写操作偶发失败，加一个寄存器回读校验能迅速暴露问题。

3.2 双通道温度读回与数据处理

每次读温度，通常是从对应温度寄存器读两个字节。PJ85718DM 的温度数据格式一般是 12 位分辨率，数据位左对齐，最低四位为 0，分辨率为 0.0625℃。读回原始值之后要做两步：先做符号位扩展，再把原始值乘以 0.0625 转成实际温度。

下面是读取远程温度的一段示意代码：

float read_chip_temperature(uint8_t sensor_dev_addr, uint8_t temp_msb_reg) { uint8_t msb = 0; uint8_t lsb = 0; int16_t raw = 0; i2c_write_byte(sensor_dev_addr, temp_msb_reg); msb = i2c_read_byte(sensor_dev_addr); lsb = i2c_read_byte(sensor_dev_addr); // 温度数据为12位，低4位无效 raw = (int16_t)((msb << 8) | lsb); raw = (raw >> 4) & 0x0FFF; // 12位有符号数做符号扩展 if (raw & 0x0800) { raw = raw - 0x1000; } return raw * 0.0625f; }

这类代码在逻辑上不同芯片的寄存器偏移会不一样，但处理思想是通用的。拿到温度原始值后，我还会做两级滤波：第一级是中值滤波，连续采 5 个原始值排序取中间值，用来剔除偶尔的尖峰干扰；第二级是滑动平均，把最近 5 个中值滤波结果做均值，用来平滑风管里温度的自然波动。

HVAC 应用里温度变化本来就慢，采样周期不需要太激进。我的做法是每秒读一次传感器，中值滤波窗口取 5 秒，滑动平均取 5 个点，这样输出给上位机的温度既不会抖动，也不会延迟太多。如果把采样周期压缩到 100ms，表面上看数据更新更快，但因为现场噪声存在，滤波窗口稍一去掉，读数反而跳来跳去，用户体验很差。

3.3 告警输出与故障诊断机制

PJ85718DM 的 ALERT 引脚是开漏输出。我把这个引脚接到 STM32F423RH 的一个 EXTI 外部中断引脚上，并接一个上拉电阻。正常时引脚为高电平，一旦温度越限或者传感器内部检测到故障，芯片会把 ALERT 拉低，MCU 在中断里读取状态寄存器，再判断具体原因。

这样做的好处是主控不需要一直轮询传感器，可以继续跑显示、通信、控制任务。我把状态寄存器里的“远程探头开路”和“远程探头短路”两种状态也单独解析出来。远程探头开路时，温度寄存器通常会读到很离谱的数值；有故障判断标志，就能在屏幕上提示“探头故障”，而不是显示一个明显错误的温度让运维人员困惑。

阈值设置不宜太激进。比如控温目标 25℃，高报警阈值直接设到 25.5℃ 会导致设备经常误报警。我一般把高报警阈值设为实测正常运行温度的上限再留 3~5℃ 余量，同时报警触发条件做成连续 3 次越限才报警，等于又加了一层软滤波。这样既保留了芯片硬件报警的实时性，又不会被单个异常周期误导。

4. 系统联调、校准与现场实测

4.1 远程探头校准流程

双通道芯片用 PN 结原理测温度，理论上很线性，但实际器件还存在零点偏置和增益误差。HVAC 产品不像实验室仪表那样要求极高精度，但现场比对时偏差大了客户也会不满意。所以校准最好还是做一步，重点是远程通道。

远程三极管探头虽然有“一致性由芯片保证”的说法，但不同批次、不同封装的三极管自身特性会有细微差异，探头线缆的阻抗也有一点影响。我的校准流程比较实用：把远程探头放进恒温槽或者冰水混合液里，用一个高精度温度计做参考，等读数稳定后读取芯片的远程温度值和高精度温度计的差值，然后把这个差值写进芯片的偏移校正寄存器。

校准水温我习惯选两个点，一个在 0℃ 附近，一个在满量程中间，比如 50℃。两个点都做一次修正，能同时校正零点和增益误差。如果现场条件不允许，只做单点修正也够用，毕竟芯片本身一致性比热敏电阻好很多。要注意的是校准过程中探头不能接触容器壁，探头插入液体后至少等 3 分钟让热传导充分稳定，否则你修正的其实是液体还没稳定的临时差值。

本地通道的校准相对简单，但要等控制板自身温度完全稳定。开机到稳定可能需要十几分钟，这期间板子上电源芯片产生的热量会慢慢扩散到传感器周围。手摸芯片、靠近热风枪都会引起读数漂移，校准前保持环境稳定即可。

4.2 一组实测数据与误差分析

用恒温槽和数字温度计做了一组比对测试，把 PJ85718DM 的本地通道和远程通道读数记录下来，大致数据如下：

远程通道在温水槽那组偏差接近 0.7℃，原因有两个：一是探头在液体里的位置和参考温度计的探头位置没完全并排，液体存在微小温度分层；二是传感器内部的偏差矫正算法在大跨度后又经过一轮温度循环，数值还没有完全稳定下来。回头看，如果测温点覆盖这个量程，确实需要做两个点以上的修正，单点校准会在量程两端放大误差。

分析误差来源时，一个容易被忽略的是探头自热效应。三极管探头通着固定的测量电流，电流会对探针本身产生微小自热，导致它比被测介质高零点几度。传感器芯片的测量电流已经优化得很小了，但如果探头封装隔热效果好、介质流速慢，这部分误差还是会存在。风管高速气流下自热影响小，静水槽里影响略大，所以实测偏差分布并不均匀。

4.3 常见问题排查速查表

联调阶段总会遇到一些典型问题，我整理成一张速查表，基本覆盖了项目里碰到过的情况：

这里面最容易栽跟头的就是远程探头接反。我遇到过几次，现场人员把三极管当热敏电阻随意焊，觉得“接反接正差不多”，结果远程温度读出来非常离谱。用万用表二极管档可以快速验证：测量 D+、D- 之间的电压降应该有大约 0.5V 左右的正向导通值，方向接反电压就是无穷大。

5. 经验总结：温度监测项目里最容易踩的坑

5.1 远程晶体管的选型坑

远程探头看似只要一个三极管，但这里其实有严格讲究。最好使用小信号 NPN 三极管，像 2N3904 这类，而不是功率三极管或者 MOS 管。

原因在于传感器芯片内部的偏置电流和放大器是针对小信号三极管的特性设计的。功率管的 PN 结面积大，结电容和等效电阻跟小信号管差别明显，测出来的温度可能差好几度。MOS 管如果不接成寄生二极管形式，很多型号根本不导通，温度读数直接异常。

最稳妥的做法是整个项目固定用同一品牌、同一封装、同一批次的三极管。不同封装里的引线长度和模具材料会影响热传递，新批次更换后最好重新做一次校准。这个细节我在量产阶段印象很深：第一批设备全部正常，第二批换了供应商的三极管后，远程通道普遍偏高 1℃左右，找了好久才发现是探头器件换了型号。

5.2 采样周期与滤波参数的平衡

HVAC 系统温度响应慢，采样太快反而让数字滤波变成了负担。我在调试时把采样周期从 100ms 调到 1s，对外上报的数据稳定性反而变好了。原因很简单：现场变频器、接触器动作等干扰在时域上是宽频带的，采样间隔太短时，干扰脉冲很容易混进温度序列；拉长采样间隔后，干扰脉冲本身已经衰减，再用中值滤波和滑动平均，效果就很明显。

报警的响应时间也要和滤波周期一起考虑。如果你做了 5 秒滑动平均，那报警判断至少要在滤波之后进行，不能拿原始值直接做阈值比较。HVAC 中温度变化是慢过程，5~10 秒的报警延迟完全可接受。如果把采样周期拉长到 5 秒，报警延迟长达 20 秒，就有点影响安全性了。建议采样 1 秒、滤波 5 点、连续 3 次越限报警，这个组合在多数现场比较稳妥。

5.3 软件标定别过度拟合

温度校准很容易走向另一个极端：追求每个点都跟参考温度计完全一致，于是做了密密麻麻的多点修正表。实测下来，这种做法在温度传感器项目里往往是画蛇添足。

PJ85718DM 本身的输出非常线性，真正需要修正的是零点偏移和轻微增益偏差。用两个校准点修正完偏移和增益之后，中间的读数通常已经很平滑了。如果再引入多点查表修正，不同温度点之间会出现微小的台阶，滤波器反而无法平滑掉。我在某次调试中用了 7 点标定表，结果在相邻两个标定点之间出现 0.2℃ 的跳变，看起来就像传感器故障，后来改回两点校准才恢复稳定。

5.4 一路传感器变多路的扩展思路

PJ85718DM 是单远程通道芯片，但很多 HVAC 设备需要测不止两个温度点。解决办法也很直接：I2C 总线上可以挂多颗 PJ85718DM，通过 A0、A1 引脚组合不同地址。

例如需要测送风温度、回风温度、冷凝器进风温度和控制板本地温度，就可以放三颗芯片，只占用同一路 I2C 接口。每颗芯片的本地通道测离它最近的 PCB 温度，远程通道接到风管探头或水管道探头。软件里每个地址对应一组阈值、滤波和校准值，结构上非常清晰。多芯片挂接时要注意总线总电容，每组传感器电源和上拉之间留一点退耦空间，线缆太长时可以把 I2C 速率降到 100kHz 以下，仍然能稳定工作。

在后续产品迭代里，还可以顺着这个思路做远程采集节点：每个节点一颗 PJ85718DM 加一颗小单片机和 RS485 收发器，温度数据打成 Modbus 帧上传。主控 STM32F423RH 只跑业务逻辑和数据汇聚，整个分布式测温系统会比现在做线缆直连更灵活，远距离测点也能轻松覆盖。

测温这个功能说起来简单，但真正把误差、抗干扰、告警和可维护性全部兼顾到位，每个环节都有它自己的讲究。这个项目之后我再遇到“加个温度监测”的需求，会先停下来想清楚，测的是设备自己的体温，还是设备周围环境的气温，再把探头选型和软件策略定下来，而不是急着画原理图。