做嵌入式的人都知道“温度”从来不是一个套公式掰指头就能算清楚的小变量。尤其最近两年做HVAC相关项目业主对能效和故障预警盯得越来越紧我手上这个项目需要在同一块板上同时拿到“本地温度”和“远程温度”两路数据本地指的是设备控制板周围的空气温度和主要发热元件表面温度远程指的则是风管、水管甚至室外机回风口的测点温度。权衡了一圈我最终采用了PJ85718DM这颗I2C数字温度传感器配合STM32L081CB这颗超低功耗MCU来兜底整个采集与上报逻辑。整套方案一条I2C总线读本地温度一个板载ADC配合NTC抓远程管道温度再通过Modbus-RTU把两路数据送到HVAC集中监控平台。结构看着不复杂但把它从选型一步步落地成能稳定跑几个月的节点中间有不少细节值得单独拿出来聊。如果你正在做温控器、风机盘管控制器或小型数据采集终端或者想把手头单点位温度检测模块升级成双点位、可远程上报的设计这篇内容会适合你。全文按照我的真实设计过程来写从选型逻辑、电路计算、固件写法一直讲到HVAC现场调试踩坑和低功耗实测数据。1. 方案选型为什么是“数字传感器 超低功耗MCU NTC”这一套1.1 这个项目到底要解决什么问题HVAC系统里的温度监测需求和实验室里测环境温度完全不是一回事。嵌入式控制板通常装在封闭电控箱里箱内温度受电源模块和驱动电路影响极大哪怕空气温度只有30°C功率器件附近可能已经到70°C以上。所以“本地温度”不能只看环境温度更得监测PCB上的热点。而HVAC主机的运行逻辑又需要知道“远端温度”比如送风温度、回风温度、冷冻水供回水温度这些测点距离主控板往往有几米到几十米远的物理距离。项目最初的需求描述只有一句话在同一台嵌入式控制器里实时监测本地温度和远程温度并要求整机在周期采样场景下保持低功耗。这句话背后隐藏的真实需求其实是三个第一本地测温要有足够的精度和一致性第二远程测温不能因为线缆长度和现场干扰导致数据漂移第三整个节点要能长期运行不能动不动就换电池或者发热失控。如果只放一颗数字温度传感器在板子上本地温度能解决但远端测点就必须额外拉线到I2C总线线稍长就会出现时序塌陷和抗扰问题。如果全部用NTC加ADC采集本地温度和远程温度倒是都能覆盖但NTC的非线性和无统一出厂校准会让批量产品的误差控制变得痛苦。所以最终方案定为本地温度交给PJ85718DM这颗数字传感器远程温度交给NTC加STM32L081CB内部ADC。PJ85718DM负责提供一个稳定、可校准、带告警输出的本地温度基准MCU的ADC负责廉价且灵活地扩展远端点位两者互补既保精度又保布线灵活度。1.2 MCU的选型逻辑STM32L081CB进入候选首先是因为它在低功耗和功能性之间平衡得比较稳。Cortex-M0内核在32MHz主频下处理温度换算和Modbus协议栈并不吃力Flash和RAM容量对这种中低复杂度的采集节点很充裕。真正让我看重的是它的停止模式表现RTC和部分IO可以继续保持工作静态功耗在微安级别。HVAC采集节点往往由24V或12V电源供电看似不缺电但当设备主体断电、只靠备用电池维持监控时微安级功耗就能把后备时间从小时级拉到天级。还需要顺便提一句为什么不用两颗PJ85718DM实现双通道。一是成本二颗加一路I2C地址配置和走线成本增加一倍不止二是工程上远端测点距离控制器通常超过30cmI2C标准模式在这种距离下已经不可靠更不用说面板上还要过连接器。用NTC把远端信号转换成电阻变化再通过屏蔽线缆接回ADC物理距离容忍度高得多。这是HVAC和嵌入式两种场景在一起时很典型的妥协方案关键基准点用数字传感器延展点用模拟传感器。2. 硬件电路设计把本地和远端测温通道做扎实2.1 PJ85718DM的电源与I2C接口电路PJ85718DM的手册指标里我主要抓住这几点I2C兼容接口、默认7位地址可通过地址引脚修改、典型转换精度±0.5°C、12位分辨率下温度步进0.0625°C、支持单次转换模式。它在3.3V供电下工作毫无问题但要注意一点它不是纯粹的“零功耗待机”器件虽然单次转换模式能大幅降低平均电流但I2C接口一旦挂在总线上并且上拉到VDD它就会始终从总线上取一点电流。因此在低功耗节点里我选择用一个GPIO来给传感器做电源控制MCU进入停止模式之前把这个GPIO拉低整个PJ85718DM完全断电既省电又避免了总线上的漏电流路径。具体电路上PJ85718DM的VDD接一个100nF和一个1μF电容靠近电源引脚放置SDA和SCL各接一个4.7kΩ上拉到3.3V。上拉电阻的值很关键太大会让总线边沿变缓太小则会增加总线空闲电流。我之前在一个项目里直接用1kΩ上拉结果整条I2C总线在待机时多出好几毫安电流这在常供电设备上无所谓但在电池备份节点上就明显不合适。PJ85718DM的ALERT/THERM引脚也很值得用起来。这个引脚可以设置为温度越限中断输出超过阈值就会拉低。我们把它接到MCU的一个EXTI引脚上硬件上就能实现“温度超限立刻唤醒MCU”而不需要MCU每时每刻轮询温度寄存器。这个设计在HVAC的过热保护场景里特别有价值比如功率管过温需要在10ms内响应靠软件周期采集是做不到的。2.2 远程NTC通道的分压与计算远程通道我选了最经典的10kΩ NTC热敏电阻B值为3435。选择这个参数的逻辑很朴实采购方便供货稳定温区在0到80°C范围内线性度够用后续要换更高精度的同类器件也不需要改电路结构。分压结构是参考电阻Rref放在VDD和采样点之间NTC放在采样点和GND之间这样ADC读数会随温度升高而增大方向更符合直觉。Rref同样取10kΩ温度25°C时NTC阻值约10kΩ分压点正好是1.65V落在ADC输入范围的中间附近。这里有一个容易忽略的计算细节ADC的参考电压直接用了VDD。当VDD实际不是精确3.3V时分压比本身不变但ADC读数对应关系会变。简单的做法是同时使用MCU内部VREFINT通道做参考电压校正或者干脆每次都把VDD当作100%满量程因为根据分压公式Rntc Rref × Vntc / (VDD - Vntc)只要ADC用的是线性转换VDD误差会被分子分母消掉最终求出来的Rntc只取决于ADC比例。所以直接求ADC比例更稳不要先把这个比例转换成“精确电压”再去算电阻。换算温度的工程做法我放在固件章节展开硬件上要做的只是把NTC信号引线接入MCU的ADC引脚前加一个100nF电容滤除高频干扰。但注意这个电容不能选太大。我见过有人为滤波给它加了1μF结果NTC温度响应变得非常迟钝原因是RC低通时间常数拉长到好几秒现场调试时又找不到原因最后把电容改小到10nF才恢复正常。2.3 低功耗场景下的供电和布局参考整个节点的供电拓扑很简单前端电源经过一个LDO降到3.3VLDO静态电流要选微安级别。MCU的VDD脚放100nF去耦两三个标准电容位就能解决绝大部分电源纹波问题。值得留意的是PJ85718DM如果像我上面说的那样由GPIO直接供电那么GPIO输出的高电平在传感器转换瞬间会有瞬态压降所以传感器电源脚旁边那1μF电容不能省不然转换期间电压跌落会导致读数偏低。布局上本地温度测点要尽量靠近项目中真正需要关注的热源。有一版PCB我最初把PJ85718DM摆在PCB角落离电源模块很远测出来的所谓“本地温度”和现场仪表差了6°C以上后来才意识到本地温度的本意是“器件发热监测”不是“电控箱环境温度”。重新把传感器移到电源管附近数据才真正有参考意义。远程NTC连接器要放在PCB边缘走线尽量粗短并用地线包围。因为NTC信号是模拟量哪怕只有几十毫伏的工频干扰串进去经过指数换算之后都会变成一两度的温度误差。这一点在风机变频器附近尤其明显后面我会专讲现场翻车案例。3. 固件实现从寄存器配置到双通道温度换算3.1 用硬件I2C读取PJ85718DMSTM32L081CB的硬件I2C做主模式读PJ85718DM代码量不大但有几个初始化顺序上的坑必须避开。第一个坑是引脚复用配置必须在I2C外设使能之前完成。GPIO的AFR寄存器没设置好I2C上电后SCL会被拉死总线直接瘫痪这个错误出现时现场没有示波器很难看出来只觉得读不到任何ACK。第二个坑是MCU从停止模式唤醒后I2C外设的时钟状态需要重新初始化。很多人习惯把I2C只初始化一次低功耗唤醒后直接继续用结果第一笔读操作永远卡在忙标志位。我建议的读取流程是这样唤醒后先给PJ85718DM供电的GPIO拉高延时约50ms等传感器上电稳定再调用I2C初始化函数然后发送器件地址做读操作。这里不直接把传感器配置成连续转换模式而是用单次转换模式每次需要读数时先写配置寄存器触发一次转换再等待转换完成标志最后读温度数据寄存器。转换时间按12位精度算预留100ms到150ms比较稳妥。虽然Cortex-M0速度不快但这个等待时间完全可以把NTC采样穿插进去让两路测温在时间上重叠系统整体延迟反而更低。读取温度数据的寄存器是高字节在前低字节在后12位有效数据里低4位是小数部分。解析的时候直接用((raw 4) 0x0FFF)就能得到实际温度值乘以16的结果再乘0.0625就能得到摄氏度数值。为了保证批量一致性我在工程里把温度值线性偏移量做成可配置项在出厂校准工位写入Flash末尾的保留区域这样每台设备的零点误差都能单独修正。// 读取PJ85718DM温度数据并返回摄氏度0.01°C分辨率 int16_t read_local_temp(void) { uint8_t reg[2]; uint16_t raw; int16_t temp; pj85718dm_power_on(); delay_ms(50); i2c_init(); pj85718dm_trigger_single_convert(); delay_ms(120); i2c_read_reg(0x00, reg, 2); // 地址0x00为温度数据寄存器 raw ((uint16_t)reg[0] 8) | reg[1]; raw 4; // 移除低4位 temp (int16_t)(raw * 10) calib_offset; // 结果单位0.1°C pj85718dm_power_off(); return temp; }3.2 NTC数据采集、滤波与查表换算NTC采样端的固件逻辑关键是不要在Cortex-M0上实时算指数函数。B值公式本身没什么问题Rntc R0 × exp(B × (1/T - 1/T0))但连续做浮点指数运算在这种内核上会占用大量时间而且NTC参数存在批次离散公式再精确也只是理论值。所以我采用“查表加线性插值”的方式把0到80°C范围内对应的ADC码值提前算好做成一个常量表运行时根据当前ADC值找到所在的相邻区间按比例线性插值出温度。查表法在工程上还有额外好处就是可以把传感器实测校准直接合并到表里比如生产时发现某个批次NTC偏2%直接单独生成一套ADC表代码不用改任何逻辑。ADC采集时要开足够长的采样时间我用的是采样时间84个周期配合100nF输入电容能最大程度降低前级阻抗带来的采样误差。软件上再加一次中值滤波每轮采集先连续采7次排序后取中间值再参与温度换算。这个滤波对抑制一次性的毛刺非常有效同时几乎不引入额外延迟。具体换算流程可以这样写从ADC寄存器取出12位原始值计算分压比例用这个比例算出当前NTC阻值然后遍历温度表找到对应区间做插值。下面这段代码是我在实际工程里用的核心片段表省略了部分值但结构是完整的。// 温度表索引为温度(°C)值为TADC下的分压比(千分比) const uint16_t ntc_adc_table[] { 0, // -5°C 10, // 0°C 25, // 5°C ... 500, // 25°C ... 950, // 80°C }; int16_t calc_remote_temp(uint16_t adc_raw) { uint16_t ratio adc_raw * 1000ul / 4095; // 0~1000对应0~VDD uint8_t i; for (i 1; i TABLE_SIZE; i) { if (ratio ntc_adc_table[i]) { int32_t t (i - 1) * 10; int32_t diff (ratio - ntc_adc_table[i - 1]) * 10; diff / (ntc_adc_table[i] - ntc_adc_table[i - 1] 1); return (int16_t)(t diff); // 返回0.1°C } } return TABLE_MAX_TEMP * 10; }这份表怎么生成很多人直接拿B值公式算但我更推荐用实际器件在恒温槽里实测几个点再拟合。因为同一个型号的NTC不同批次B值可能差几十K表是按理论B值生成的生产时把偏差写进配置参数即可。如果不想引入复杂校准也可以在代码里加一个全局温度偏移量把远程通道的系统性偏差直接消掉。3.3 温度值如何进入HVAC远程监控链路本地和远程两路温度最终都要变成HVAC监控系统能识别的数据。这个项目里我选择了最通用的Modbus-RTU协议通过STM32L081CB的低功耗UART外接RS-485收发器实现。模块作为从机设备地址支持0到15拨码设置寄存器地址安排如下寄存器内容说明40001本地温度有符号数单位0.1°C40002远程温度有符号数单位0.1°C40003状态字bit0手动模式bit1本地告警bit2远程告警40004设备自检0正常非0表示传感器或通信异常Modbus-RTU的报文处理里最容易出问题的就是CRC16的计算。Cortex-M0软算CRC并不慢但要确保接收中断里别把CRC校验逻辑拖得太久否则下一个字节到来时会丢数据。我的做法是开一个环形缓冲区接收UART收到一帧完整数据后再在主循环里做校验和响应中断里只做字节搬运。上报周期也需要结合HVAC实际刷新率来设。一般楼宇自控系统对温度点位的刷新要求就是1到5秒一次太快没意义太慢会让集控平台显示的数据看起来“很钝”。我用的是3秒周期RTC定时唤醒MCU完成两路温度采集、写寄存器缓存如果主站恰好在本周期内发来请求就顺手返回最新数据。没有请求时MCU重新进入停止模式整个节点大多数时间处于极低功耗状态。4. HVAC现场落地控制逻辑、现场干扰不能想当然4.1 温度告警与联动控制的阈值设计温度数据采集上来之后真正的项目价值体现在和HVAC控制逻辑的联动上。本地高温告警我设置在70°C迟滞5°C。为什么用迟滞因为功率器件和开关电源表面温度在正常工作时会有波动如果阈值上下沿完全一致温度在阈值附近抖动时告警继电器会频繁吸合断开短则一天长则一晚就能把继电器触点烧黑。设置迟滞之后正常状态和告警状态的切换路径不同继电器动作被限制在有限次数内。远程通道的告警逻辑不太一样。HVAC中基于水温差的控制通常用回风温度和送风温度之差来判断热交换效率这个差值不是固定值而是随工况变化。所以固件里我做了两个模式固定阈值模式和温差模式。固定阈值模式适合直接做高温保护比如冷冻水超温报警温差模式则把两路温度相减后与设定值比较更适合风管温湿度联动。在状态字的bit1和bit2上分别给出告警标志上位机可以根据标志去做弹窗或者联动启停。ALERT脚硬件中断在这套设计里承担了“最后一道防线”。即使MCU软件跑飞或者停止模式异常只要PJ85718DM检测到温度越限它也能通过ALERT脚直接拉低唤醒MCUMCU在中断服务里读取温度后决定是否切断负载。这套机制在实验室测试时看起来多余但在现场经历过一次电源模块失效后我把它升级为每台设备出厂前必须验证的功能项。4.2 现场安装和接线最容易翻车的几个点远程NTC的现场接线是我在这个项目里踩坑最多的地方。首先是线缆问题最开始施工队拿普通平行软线拉了几十米到风阀执行器旁边结果主站读到温度每隔几分钟就跳变一次。排查半天发现平行线在靠近变频器时感应出很大的共模干扰NTC阻值被叠加了交流成分ADC值在换算后呈现几度的波动。最后把引线全部换成屏蔽双绞线屏蔽层单端接地现象立刻消失。施工规范上写的是“不能与强电同槽布线”但实际安装里工人经常把信号线和220V捆在一起走这个必须盯。其次是NTC探头的固定方式。很多现场测的是水管表面温度施工人员图省事直接用扎带绑上就不管了。这样测的其实是探头附近空气和水的混合温度空调水系统里这个误差能到3到4°C。我后来要求所有水管温度测点必须加导热硅脂并且用保温棉把探头完全包住让探头和水管、保温棉形成一个稳定的热平衡区域读数才真正可信。RS-485总线在HVAC现场的终端电阻配置也经常被忽略。一条总线上挂十来个温度节点首端和末端各加120Ω终端电阻这是通信稳定的前提。但问题是总线末端往往和最后一个节点在一起而很多采集板上并没有设计好这个电阻现场只能临时外接。我把端子排上预留了一个120Ω的焊盘位置现场调试时用跳线帽就能选择要不要装上这对长距离通信帮助很大。4.3 常见问题速查表现象可能原因排查与解决本地温度读数明显偏高传感器靠近大功率发热器件或电源干扰影响转换精度重新确认测点用途必要时把传感器移到环境温度代表位远程温度数值跳变NTC接头氧化、线缆屏蔽层浮空、ADC参考不稳重新压接端子单端接地改用更长ADC采样时间I2C读取偶发无应答PCB走线过长上拉电阻太强或太弱I2C速率降到100kHz上拉改为4.7kΩ后再次确认波形停止模式整机电流偏高PJ85718DM未断电、I2C上拉电阻灌电、外部上下拉消耗检查GPIO输出状态确认传感器电源控制脚已拉低远程温度响应特别慢NTC输入滤波电容太大RC时间常数过长把电容从几百nF降到10nF级别Modbus请求无响应主站从站地址不一致、CRC计算错误、RS-485 A/B接反用串口助手抓报文确认地址和CRC反向调整485端子这张表里的每一条都是从实际调试记录里抽出来的不是凭空的教科书答案。尤其是I2C速率和上拉电阻的匹配很多人不重视等到现场出现间歇性找不到设备时才后悔没有提前测试。5. 实测数据与调优记录5.1 低功耗表现我专门搭了一套测试环境验证低功耗设计3.3V供电MCU停止模式RTC定时3秒唤醒一次每次唤醒完成两路温度采集并更新寄存器然后继续进入停止模式。用精密万用表串联测平均电流最终结果是平均功耗在85µA左右。相比“常供电连续转换”的做法这个数字低了不止一个数量级。如果再把3秒周期放大到10秒平均电流还能降到40µA以下。这个电流水平下用两节18650电池并联供电理论后备时间可以到一两个月给HVAC设备做断电监控完全够用。功耗最大的三个来源分别是PJ85718DM转换期间的传感器供电电流、I2C总线上拉电阻在通信过程中的灌电流、以及UART空闲时的偏置。因此固件在完成温度采集后立即关闭传感器电源并且把串口发送和接收引脚在空闲时配置为高阻输入而不是保持推挽输出这样能省下不少漏电路径。5.2 测温精度对比本地通道我用一个经过计量的标准铂电阻温度计做比对。在25°C恒温箱里PJ85718DM读数的重复性在±0.2°C以内和标准表相差约0.3°C这个量级对HVAC控制完全够用。校准偏移量写入Flash后批量设备的一致性误差可以控制在±0.5°C内。远程NTC通道的精度完全取决于探头本身和现场安装工艺。同一个探头在冰水混合和沸水里分别做两点校准后0到80°C范围内误差大约在±1.2°C内。对风管温度监控来说这个精度足够如果用它做高精度的供回水温差计量建议换更高B值精度的探头并且在做两点校准时覆盖实际运行温度区间而不是只做0°C和100°C两个端点。5.3 给后来者的几条心得第一个心得是不要迷信数字传感器的“出厂校准”。PJ85718DM这类器件出厂精度确实不错但它在PCB上的位置、周围的铜箔、风道走向都会带来额外的环境偏差。所以在项目定型前一定要先在最坏布局下做一轮温度对比测试确认偏差方向后再决定是否要加校准流程。第二个心得是HVAC现场和实验室完全是两回事。实验室里一根屏蔽线、一个干净地平面就解决的问题在现场要同时面对变频器、接触器、线缆捆扎槽、施工工人的随意发挥。所以硬件上能加的保护尽量加软件上能做的滤波尽量做不要指望现场人员会按测试规范来操作。第三个心得是这套“本地数字温度传感器 远程NTC”的组合虽然简单但扩展性非常好。后续想加湿度检测就在原I2C总线上再挂一个湿度传感器想增加一路远程测点就再引一路ADC通道。MCU的硬件资源剩余还很多不需要为了升级重新选型。最后再分享一个小技巧现场调试时我习惯随身带一个USB转I2C的小工具。遇到传感器读取异常先把PJ85718DM从主板上摘下来用工具单独读它的寄存器能快速判断是芯片坏了、虚焊了还是主板的I2C时序配置有问题。这套排查动作帮我省掉了无数次在电控柜前抓头发的痛苦也推荐你试试。 
长河君 · 2026/10/22 1:03:43 · 阅读 1.2k 嵌入式双温度采集方案：数字传感器+NTC+低功耗MCU实战解析
做嵌入式的人都知道“温度”从来不是一个套公式掰指头就能算清楚的小变量。尤其最近两年做HVAC相关项目业主对能效和故障预警盯得越来越紧我手上这个项目需要在同一块板上同时拿到“本地温度”和“远程温度”两路数据本地指的是设备控制板周围的空气温度和主要发热元件表面温度远程指的则是风管、水管甚至室外机回风口的测点温度。权衡了一圈我最终采用了PJ85718DM这颗I2C数字温度传感器配合STM32L081CB这颗超低功耗MCU来兜底整个采集与上报逻辑。整套方案一条I2C总线读本地温度一个板载ADC配合NTC抓远程管道温度再通过Modbus-RTU把两路数据送到HVAC集中监控平台。结构看着不复杂但把它从选型一步步落地成能稳定跑几个月的节点中间有不少细节值得单独拿出来聊。如果你正在做温控器、风机盘管控制器或小型数据采集终端或者想把手头单点位温度检测模块升级成双点位、可远程上报的设计这篇内容会适合你。全文按照我的真实设计过程来写从选型逻辑、电路计算、固件写法一直讲到HVAC现场调试踩坑和低功耗实测数据。1. 方案选型为什么是“数字传感器 超低功耗MCU NTC”这一套1.1 这个项目到底要解决什么问题HVAC系统里的温度监测需求和实验室里测环境温度完全不是一回事。嵌入式控制板通常装在封闭电控箱里箱内温度受电源模块和驱动电路影响极大哪怕空气温度只有30°C功率器件附近可能已经到70°C以上。所以“本地温度”不能只看环境温度更得监测PCB上的热点。而HVAC主机的运行逻辑又需要知道“远端温度”比如送风温度、回风温度、冷冻水供回水温度这些测点距离主控板往往有几米到几十米远的物理距离。项目最初的需求描述只有一句话在同一台嵌入式控制器里实时监测本地温度和远程温度并要求整机在周期采样场景下保持低功耗。这句话背后隐藏的真实需求其实是三个第一本地测温要有足够的精度和一致性第二远程测温不能因为线缆长度和现场干扰导致数据漂移第三整个节点要能长期运行不能动不动就换电池或者发热失控。如果只放一颗数字温度传感器在板子上本地温度能解决但远端测点就必须额外拉线到I2C总线线稍长就会出现时序塌陷和抗扰问题。如果全部用NTC加ADC采集本地温度和远程温度倒是都能覆盖但NTC的非线性和无统一出厂校准会让批量产品的误差控制变得痛苦。所以最终方案定为本地温度交给PJ85718DM这颗数字传感器远程温度交给NTC加STM32L081CB内部ADC。PJ85718DM负责提供一个稳定、可校准、带告警输出的本地温度基准MCU的ADC负责廉价且灵活地扩展远端点位两者互补既保精度又保布线灵活度。1.2 MCU的选型逻辑STM32L081CB进入候选首先是因为它在低功耗和功能性之间平衡得比较稳。Cortex-M0内核在32MHz主频下处理温度换算和Modbus协议栈并不吃力Flash和RAM容量对这种中低复杂度的采集节点很充裕。真正让我看重的是它的停止模式表现RTC和部分IO可以继续保持工作静态功耗在微安级别。HVAC采集节点往往由24V或12V电源供电看似不缺电但当设备主体断电、只靠备用电池维持监控时微安级功耗就能把后备时间从小时级拉到天级。还需要顺便提一句为什么不用两颗PJ85718DM实现双通道。一是成本二颗加一路I2C地址配置和走线成本增加一倍不止二是工程上远端测点距离控制器通常超过30cmI2C标准模式在这种距离下已经不可靠更不用说面板上还要过连接器。用NTC把远端信号转换成电阻变化再通过屏蔽线缆接回ADC物理距离容忍度高得多。这是HVAC和嵌入式两种场景在一起时很典型的妥协方案关键基准点用数字传感器延展点用模拟传感器。2. 硬件电路设计把本地和远端测温通道做扎实2.1 PJ85718DM的电源与I2C接口电路PJ85718DM的手册指标里我主要抓住这几点I2C兼容接口、默认7位地址可通过地址引脚修改、典型转换精度±0.5°C、12位分辨率下温度步进0.0625°C、支持单次转换模式。它在3.3V供电下工作毫无问题但要注意一点它不是纯粹的“零功耗待机”器件虽然单次转换模式能大幅降低平均电流但I2C接口一旦挂在总线上并且上拉到VDD它就会始终从总线上取一点电流。因此在低功耗节点里我选择用一个GPIO来给传感器做电源控制MCU进入停止模式之前把这个GPIO拉低整个PJ85718DM完全断电既省电又避免了总线上的漏电流路径。具体电路上PJ85718DM的VDD接一个100nF和一个1μF电容靠近电源引脚放置SDA和SCL各接一个4.7kΩ上拉到3.3V。上拉电阻的值很关键太大会让总线边沿变缓太小则会增加总线空闲电流。我之前在一个项目里直接用1kΩ上拉结果整条I2C总线在待机时多出好几毫安电流这在常供电设备上无所谓但在电池备份节点上就明显不合适。PJ85718DM的ALERT/THERM引脚也很值得用起来。这个引脚可以设置为温度越限中断输出超过阈值就会拉低。我们把它接到MCU的一个EXTI引脚上硬件上就能实现“温度超限立刻唤醒MCU”而不需要MCU每时每刻轮询温度寄存器。这个设计在HVAC的过热保护场景里特别有价值比如功率管过温需要在10ms内响应靠软件周期采集是做不到的。2.2 远程NTC通道的分压与计算远程通道我选了最经典的10kΩ NTC热敏电阻B值为3435。选择这个参数的逻辑很朴实采购方便供货稳定温区在0到80°C范围内线性度够用后续要换更高精度的同类器件也不需要改电路结构。分压结构是参考电阻Rref放在VDD和采样点之间NTC放在采样点和GND之间这样ADC读数会随温度升高而增大方向更符合直觉。Rref同样取10kΩ温度25°C时NTC阻值约10kΩ分压点正好是1.65V落在ADC输入范围的中间附近。这里有一个容易忽略的计算细节ADC的参考电压直接用了VDD。当VDD实际不是精确3.3V时分压比本身不变但ADC读数对应关系会变。简单的做法是同时使用MCU内部VREFINT通道做参考电压校正或者干脆每次都把VDD当作100%满量程因为根据分压公式Rntc Rref × Vntc / (VDD - Vntc)只要ADC用的是线性转换VDD误差会被分子分母消掉最终求出来的Rntc只取决于ADC比例。所以直接求ADC比例更稳不要先把这个比例转换成“精确电压”再去算电阻。换算温度的工程做法我放在固件章节展开硬件上要做的只是把NTC信号引线接入MCU的ADC引脚前加一个100nF电容滤除高频干扰。但注意这个电容不能选太大。我见过有人为滤波给它加了1μF结果NTC温度响应变得非常迟钝原因是RC低通时间常数拉长到好几秒现场调试时又找不到原因最后把电容改小到10nF才恢复正常。2.3 低功耗场景下的供电和布局参考整个节点的供电拓扑很简单前端电源经过一个LDO降到3.3VLDO静态电流要选微安级别。MCU的VDD脚放100nF去耦两三个标准电容位就能解决绝大部分电源纹波问题。值得留意的是PJ85718DM如果像我上面说的那样由GPIO直接供电那么GPIO输出的高电平在传感器转换瞬间会有瞬态压降所以传感器电源脚旁边那1μF电容不能省不然转换期间电压跌落会导致读数偏低。布局上本地温度测点要尽量靠近项目中真正需要关注的热源。有一版PCB我最初把PJ85718DM摆在PCB角落离电源模块很远测出来的所谓“本地温度”和现场仪表差了6°C以上后来才意识到本地温度的本意是“器件发热监测”不是“电控箱环境温度”。重新把传感器移到电源管附近数据才真正有参考意义。远程NTC连接器要放在PCB边缘走线尽量粗短并用地线包围。因为NTC信号是模拟量哪怕只有几十毫伏的工频干扰串进去经过指数换算之后都会变成一两度的温度误差。这一点在风机变频器附近尤其明显后面我会专讲现场翻车案例。3. 固件实现从寄存器配置到双通道温度换算3.1 用硬件I2C读取PJ85718DMSTM32L081CB的硬件I2C做主模式读PJ85718DM代码量不大但有几个初始化顺序上的坑必须避开。第一个坑是引脚复用配置必须在I2C外设使能之前完成。GPIO的AFR寄存器没设置好I2C上电后SCL会被拉死总线直接瘫痪这个错误出现时现场没有示波器很难看出来只觉得读不到任何ACK。第二个坑是MCU从停止模式唤醒后I2C外设的时钟状态需要重新初始化。很多人习惯把I2C只初始化一次低功耗唤醒后直接继续用结果第一笔读操作永远卡在忙标志位。我建议的读取流程是这样唤醒后先给PJ85718DM供电的GPIO拉高延时约50ms等传感器上电稳定再调用I2C初始化函数然后发送器件地址做读操作。这里不直接把传感器配置成连续转换模式而是用单次转换模式每次需要读数时先写配置寄存器触发一次转换再等待转换完成标志最后读温度数据寄存器。转换时间按12位精度算预留100ms到150ms比较稳妥。虽然Cortex-M0速度不快但这个等待时间完全可以把NTC采样穿插进去让两路测温在时间上重叠系统整体延迟反而更低。读取温度数据的寄存器是高字节在前低字节在后12位有效数据里低4位是小数部分。解析的时候直接用((raw 4) 0x0FFF)就能得到实际温度值乘以16的结果再乘0.0625就能得到摄氏度数值。为了保证批量一致性我在工程里把温度值线性偏移量做成可配置项在出厂校准工位写入Flash末尾的保留区域这样每台设备的零点误差都能单独修正。// 读取PJ85718DM温度数据并返回摄氏度0.01°C分辨率 int16_t read_local_temp(void) { uint8_t reg[2]; uint16_t raw; int16_t temp; pj85718dm_power_on(); delay_ms(50); i2c_init(); pj85718dm_trigger_single_convert(); delay_ms(120); i2c_read_reg(0x00, reg, 2); // 地址0x00为温度数据寄存器 raw ((uint16_t)reg[0] 8) | reg[1]; raw 4; // 移除低4位 temp (int16_t)(raw * 10) calib_offset; // 结果单位0.1°C pj85718dm_power_off(); return temp; }3.2 NTC数据采集、滤波与查表换算NTC采样端的固件逻辑关键是不要在Cortex-M0上实时算指数函数。B值公式本身没什么问题Rntc R0 × exp(B × (1/T - 1/T0))但连续做浮点指数运算在这种内核上会占用大量时间而且NTC参数存在批次离散公式再精确也只是理论值。所以我采用“查表加线性插值”的方式把0到80°C范围内对应的ADC码值提前算好做成一个常量表运行时根据当前ADC值找到所在的相邻区间按比例线性插值出温度。查表法在工程上还有额外好处就是可以把传感器实测校准直接合并到表里比如生产时发现某个批次NTC偏2%直接单独生成一套ADC表代码不用改任何逻辑。ADC采集时要开足够长的采样时间我用的是采样时间84个周期配合100nF输入电容能最大程度降低前级阻抗带来的采样误差。软件上再加一次中值滤波每轮采集先连续采7次排序后取中间值再参与温度换算。这个滤波对抑制一次性的毛刺非常有效同时几乎不引入额外延迟。具体换算流程可以这样写从ADC寄存器取出12位原始值计算分压比例用这个比例算出当前NTC阻值然后遍历温度表找到对应区间做插值。下面这段代码是我在实际工程里用的核心片段表省略了部分值但结构是完整的。// 温度表索引为温度(°C)值为TADC下的分压比(千分比) const uint16_t ntc_adc_table[] { 0, // -5°C 10, // 0°C 25, // 5°C ... 500, // 25°C ... 950, // 80°C }; int16_t calc_remote_temp(uint16_t adc_raw) { uint16_t ratio adc_raw * 1000ul / 4095; // 0~1000对应0~VDD uint8_t i; for (i 1; i TABLE_SIZE; i) { if (ratio ntc_adc_table[i]) { int32_t t (i - 1) * 10; int32_t diff (ratio - ntc_adc_table[i - 1]) * 10; diff / (ntc_adc_table[i] - ntc_adc_table[i - 1] 1); return (int16_t)(t diff); // 返回0.1°C } } return TABLE_MAX_TEMP * 10; }这份表怎么生成很多人直接拿B值公式算但我更推荐用实际器件在恒温槽里实测几个点再拟合。因为同一个型号的NTC不同批次B值可能差几十K表是按理论B值生成的生产时把偏差写进配置参数即可。如果不想引入复杂校准也可以在代码里加一个全局温度偏移量把远程通道的系统性偏差直接消掉。3.3 温度值如何进入HVAC远程监控链路本地和远程两路温度最终都要变成HVAC监控系统能识别的数据。这个项目里我选择了最通用的Modbus-RTU协议通过STM32L081CB的低功耗UART外接RS-485收发器实现。模块作为从机设备地址支持0到15拨码设置寄存器地址安排如下寄存器内容说明40001本地温度有符号数单位0.1°C40002远程温度有符号数单位0.1°C40003状态字bit0手动模式bit1本地告警bit2远程告警40004设备自检0正常非0表示传感器或通信异常Modbus-RTU的报文处理里最容易出问题的就是CRC16的计算。Cortex-M0软算CRC并不慢但要确保接收中断里别把CRC校验逻辑拖得太久否则下一个字节到来时会丢数据。我的做法是开一个环形缓冲区接收UART收到一帧完整数据后再在主循环里做校验和响应中断里只做字节搬运。上报周期也需要结合HVAC实际刷新率来设。一般楼宇自控系统对温度点位的刷新要求就是1到5秒一次太快没意义太慢会让集控平台显示的数据看起来“很钝”。我用的是3秒周期RTC定时唤醒MCU完成两路温度采集、写寄存器缓存如果主站恰好在本周期内发来请求就顺手返回最新数据。没有请求时MCU重新进入停止模式整个节点大多数时间处于极低功耗状态。4. HVAC现场落地控制逻辑、现场干扰不能想当然4.1 温度告警与联动控制的阈值设计温度数据采集上来之后真正的项目价值体现在和HVAC控制逻辑的联动上。本地高温告警我设置在70°C迟滞5°C。为什么用迟滞因为功率器件和开关电源表面温度在正常工作时会有波动如果阈值上下沿完全一致温度在阈值附近抖动时告警继电器会频繁吸合断开短则一天长则一晚就能把继电器触点烧黑。设置迟滞之后正常状态和告警状态的切换路径不同继电器动作被限制在有限次数内。远程通道的告警逻辑不太一样。HVAC中基于水温差的控制通常用回风温度和送风温度之差来判断热交换效率这个差值不是固定值而是随工况变化。所以固件里我做了两个模式固定阈值模式和温差模式。固定阈值模式适合直接做高温保护比如冷冻水超温报警温差模式则把两路温度相减后与设定值比较更适合风管温湿度联动。在状态字的bit1和bit2上分别给出告警标志上位机可以根据标志去做弹窗或者联动启停。ALERT脚硬件中断在这套设计里承担了“最后一道防线”。即使MCU软件跑飞或者停止模式异常只要PJ85718DM检测到温度越限它也能通过ALERT脚直接拉低唤醒MCUMCU在中断服务里读取温度后决定是否切断负载。这套机制在实验室测试时看起来多余但在现场经历过一次电源模块失效后我把它升级为每台设备出厂前必须验证的功能项。4.2 现场安装和接线最容易翻车的几个点远程NTC的现场接线是我在这个项目里踩坑最多的地方。首先是线缆问题最开始施工队拿普通平行软线拉了几十米到风阀执行器旁边结果主站读到温度每隔几分钟就跳变一次。排查半天发现平行线在靠近变频器时感应出很大的共模干扰NTC阻值被叠加了交流成分ADC值在换算后呈现几度的波动。最后把引线全部换成屏蔽双绞线屏蔽层单端接地现象立刻消失。施工规范上写的是“不能与强电同槽布线”但实际安装里工人经常把信号线和220V捆在一起走这个必须盯。其次是NTC探头的固定方式。很多现场测的是水管表面温度施工人员图省事直接用扎带绑上就不管了。这样测的其实是探头附近空气和水的混合温度空调水系统里这个误差能到3到4°C。我后来要求所有水管温度测点必须加导热硅脂并且用保温棉把探头完全包住让探头和水管、保温棉形成一个稳定的热平衡区域读数才真正可信。RS-485总线在HVAC现场的终端电阻配置也经常被忽略。一条总线上挂十来个温度节点首端和末端各加120Ω终端电阻这是通信稳定的前提。但问题是总线末端往往和最后一个节点在一起而很多采集板上并没有设计好这个电阻现场只能临时外接。我把端子排上预留了一个120Ω的焊盘位置现场调试时用跳线帽就能选择要不要装上这对长距离通信帮助很大。4.3 常见问题速查表现象可能原因排查与解决本地温度读数明显偏高传感器靠近大功率发热器件或电源干扰影响转换精度重新确认测点用途必要时把传感器移到环境温度代表位远程温度数值跳变NTC接头氧化、线缆屏蔽层浮空、ADC参考不稳重新压接端子单端接地改用更长ADC采样时间I2C读取偶发无应答PCB走线过长上拉电阻太强或太弱I2C速率降到100kHz上拉改为4.7kΩ后再次确认波形停止模式整机电流偏高PJ85718DM未断电、I2C上拉电阻灌电、外部上下拉消耗检查GPIO输出状态确认传感器电源控制脚已拉低远程温度响应特别慢NTC输入滤波电容太大RC时间常数过长把电容从几百nF降到10nF级别Modbus请求无响应主站从站地址不一致、CRC计算错误、RS-485 A/B接反用串口助手抓报文确认地址和CRC反向调整485端子这张表里的每一条都是从实际调试记录里抽出来的不是凭空的教科书答案。尤其是I2C速率和上拉电阻的匹配很多人不重视等到现场出现间歇性找不到设备时才后悔没有提前测试。5. 实测数据与调优记录5.1 低功耗表现我专门搭了一套测试环境验证低功耗设计3.3V供电MCU停止模式RTC定时3秒唤醒一次每次唤醒完成两路温度采集并更新寄存器然后继续进入停止模式。用精密万用表串联测平均电流最终结果是平均功耗在85µA左右。相比“常供电连续转换”的做法这个数字低了不止一个数量级。如果再把3秒周期放大到10秒平均电流还能降到40µA以下。这个电流水平下用两节18650电池并联供电理论后备时间可以到一两个月给HVAC设备做断电监控完全够用。功耗最大的三个来源分别是PJ85718DM转换期间的传感器供电电流、I2C总线上拉电阻在通信过程中的灌电流、以及UART空闲时的偏置。因此固件在完成温度采集后立即关闭传感器电源并且把串口发送和接收引脚在空闲时配置为高阻输入而不是保持推挽输出这样能省下不少漏电路径。5.2 测温精度对比本地通道我用一个经过计量的标准铂电阻温度计做比对。在25°C恒温箱里PJ85718DM读数的重复性在±0.2°C以内和标准表相差约0.3°C这个量级对HVAC控制完全够用。校准偏移量写入Flash后批量设备的一致性误差可以控制在±0.5°C内。远程NTC通道的精度完全取决于探头本身和现场安装工艺。同一个探头在冰水混合和沸水里分别做两点校准后0到80°C范围内误差大约在±1.2°C内。对风管温度监控来说这个精度足够如果用它做高精度的供回水温差计量建议换更高B值精度的探头并且在做两点校准时覆盖实际运行温度区间而不是只做0°C和100°C两个端点。5.3 给后来者的几条心得第一个心得是不要迷信数字传感器的“出厂校准”。PJ85718DM这类器件出厂精度确实不错但它在PCB上的位置、周围的铜箔、风道走向都会带来额外的环境偏差。所以在项目定型前一定要先在最坏布局下做一轮温度对比测试确认偏差方向后再决定是否要加校准流程。第二个心得是HVAC现场和实验室完全是两回事。实验室里一根屏蔽线、一个干净地平面就解决的问题在现场要同时面对变频器、接触器、线缆捆扎槽、施工工人的随意发挥。所以硬件上能加的保护尽量加软件上能做的滤波尽量做不要指望现场人员会按测试规范来操作。第三个心得是这套“本地数字温度传感器 远程NTC”的组合虽然简单但扩展性非常好。后续想加湿度检测就在原I2C总线上再挂一个湿度传感器想增加一路远程测点就再引一路ADC通道。MCU的硬件资源剩余还很多不需要为了升级重新选型。最后再分享一个小技巧现场调试时我习惯随身带一个USB转I2C的小工具。遇到传感器读取异常先把PJ85718DM从主板上摘下来用工具单独读它的寄存器能快速判断是芯片坏了、虚焊了还是主板的I2C时序配置有问题。这套排查动作帮我省掉了无数次在电控柜前抓头发的痛苦也推荐你试试。