做暖通空调控制的人大概都有过这种体会控制板放在配电柜或者电控箱里真正要监测的温度却在风管远端、室外机旁边或者冷库深处。温度传感器离主控太远模拟信号引过来容易衰减和受干扰就地放个小控制器又显得小题大做。我这次要分享的就是用 TM4C1294KCPDT 做主控、PJ85718DM 做远端探头的本地与远程温度监测方案兼顾嵌入式和 HVAC 两类场景。这套思路既不需要额外挂一块 PLC也不用把传感器信号拉得满场飞一条 I2C 总线、一颗带浮点运算的 MCU 就能把温度采集、校准、滤波、报警和通信全部收拢进来。整个项目做完我最深的感受是温度监测本身不难难的是把“本地温度”和“远程温度”这两路读数用对地方。下面从选型逻辑开始把硬件接入、驱动编写、校准滤波、实测数据和调试踩坑一条条讲透。适合正在做空调机组控制器、冷链监控节点或者嵌入式温控模块的朋友参考。1. 为什么拿“主控级 MCU”做测温节点TM4C1294KCPDT 的选型逻辑1.1 这颗芯片的底子到底有多厚TM4C1294KCPDT 属于 TM4C129x 系列Cortex-M4F 内核带硬件浮点单元最高主频能做到 120MHz。Flash 1MBSRAM 256KB外设资源非常齐全两路 12 位 ADC、多路 UART、I2C、SSI、USB还带定时器和 PWM。单看这些参数拿它做“一个测温节点”确实有点大材小用但这恰恰是很多人选型时容易走偏的地方。温度采集本身消耗的资源极小读一个寄存器的数据量还不到几十字节。真正的复杂度在别处数据怎么滤波、怎么校准、怎么和上位机通信、要不要挂 LCD 显示、报警输出怎么联动风机和压缩机。这一串需求堆下来8 位机往往写到最后四处挤资源而 Linux 板卡又是杀鸡用牛刀启动慢、功耗高、成本也压不住。TM4C1294KCPDT 正好站在中间位置算力足够跑各种滤波算法和协议解析功耗远低于板卡方案裸机开发也直接不依赖大型系统。1.2 温度监测任务比表面看起来复杂我在做这个项目之前也以为读温度嘛拿个传感器采一下然后算出来就完了。真正接手才明白工业现场和实验室最大的区别在于传感器本身有离散性同一批 PJ85718DM 探头之间的读数可能差出 1℃ 以上探头安装位置和实际关注点之间存在系统性温差远距离传输线上会有干扰偶发跳变数据会直接影响控制逻辑压缩机频繁启停对温度报警的迟滞要求极高没有回差的报警根本没法用。这些需求落到软件上就是滤波、校准死区、迟滞比较、故障诊断。用 8 位机写也不是不行但代码会写得非常局促。TM4C1294KCPDT 的浮点单元让滤波计算变得很轻松256KB SRAM 即使后面扩展记录历史温度曲线也绰绰有余。1.3 本地温度与远程温度的分工逻辑标题里的“本地”和“远程”容易让人误以为只是两个测点其实它们在系统里干的活完全不一样。我做的这套方案里本地温度指的是 MCU 电路板所在位置的温度主要用来做板卡过热保护、机柜散热判断偶尔也作为无远程数据时的兜底读数远程温度指的是 PJ85718DM 探头放在真实被测环境里的读数比如空调箱的出风口、制冷机组回气管路、冷库内部它才是控制逻辑真正依赖的主变量。这两路温度不能混用。如果拿本地机柜温度去控制风机整个逻辑会被板卡自热搞得一团糟反之拿远程温度去判断板卡是否过热等到报警时板卡可能已经热到降频了。所以从硬件设计开始就要把这两路分开规划。2. PJ85718DM 远端探头接入与本地传感器设计2.1 远端探头走 I2C 的接线细节PJ85718DM 这块传感器模块从用法上看是一个典型的 I2C 接口数字温度传感器四根线就能接跑VDD、GND、SDA、SCL。I2C 的好处在于信号是数字方波抗干扰能力远强于模拟电压传输探头放在几十米外读回来的值也不会因为线阻产生偏差。接线时有几个点需要特别注意。首先是上拉电阻I2C 总线的 SDA 和 SCL 必须接上拉。传感器模块自带上拉时主控端就不用再加模块没带上拉或者线上节点太多一般取 4.7kΩ。如果探头距离较远、总线电容偏大我会直接把上拉降到 2.2kΩ增大驱动能力代价是功耗略高一点。其次是线材远程探头我建议用双绞线屏蔽层单端接地不要两端都接地否则容易形成地环路反而引入新的干扰。2.2 驱动代码与温度换算流程写驱动之前先读数据手册确认寄存器地址。不同厂家的 I2C 数字温度传感器寄存器布局大同小异一般有一个配置寄存器、一个温度数据寄存器部分型号还有 EEPROM 用于校准。读取的流程固定为发起 I2C 写操作设置寄存器指针然后连续读两个字节拼接成 16 位数据后根据分辨率移位换算成摄氏度。下面这段代码是我在工程里实际用的简化版寄存器地址按该器件数据手册填进去即可#include tm4c1294_driver_i2c.h #define PJ85718DM_ADDR 0x48 // 根据A0/A1引脚电平确定 #define REG_CONFIG 0x01 #define REG_TEMP 0x00 float pj85718dm_read_temp(void) { uint8_t tx_data[1]; uint8_t rx_data[2]; uint16_t raw; float temp; // 设置寄存器指针指向温度寄存器 tx_data[0] REG_TEMP; i2c_write(PJ85718DM_ADDR, tx_data, 1); // 读取两个字节的温度数据 i2c_read(PJ85718DM_ADDR, rx_data, 2); // 拼接为16位原始值 raw ((uint16_t)rx_data[0] 8) | rx_data[1]; // 12位分辨率下每个LSB代表0.0625摄氏度 temp (float)((int16_t)raw 4) * 0.0625f; return temp; }这里有一个容易踩的坑温度寄存器的高字节是有符号的负温度时最高位为 1。如果直接当成无符号数换算零下温度会得到上百摄氏度的荒谬结果。所以代码里先把 16 位数据按 int16_t 解释再右移取有效位。右移时符号位会被保留低温才能正确计算。2.3 本地温度路NTC 分压与第二颗 I2C 传感器二选一本地温度我试过两种做法。第一种是板载 NTC 热敏电阻10kΩ 阻值、B 值 3950 的型号最常用搭配一个 10kΩ 精密电阻做分压输出接到 TM4C1294KCPDT 的 ADC 输入引脚用查表法或者 Steinhart-Hart 公式换算温度。好处是成本极低、不占总线资源坏处是 ADC 的噪声和参考电压波动会直接影响精度需要额外做滤波。第二种做法是直接再挂一颗同型号的 PJ85718DM 做本地温度采集代码几乎不用改精度和远程探头一致。因为 I2C 总线支持多设备只要把第二颗传感器的地址引脚设成不同电平就行。如果项目对成本不敏感我推荐第二种省去了标定 NTC 的麻烦两路温度的代码路径完全统一后续维护省心很多。2.4 供电与去耦看似小事实际很关键传感器的 VDD 建议直接用 TM4C1294KCPDT 输出的 3.3V但必须在模块附近放 0.1μF 陶瓷电容加 10μF 电解电容做去耦。远程探头如果走线超过 20cm最好在探头端也补一个 0.1μF 电容防止长线电感导致供电瞬间跌落。很多人忽略这一步结果温度数据时好时坏查了半天发现竟然是供电纹波把 I2C 时序搅乱了。3. 两路温度读数的校准、滤波与使用策略3.1 为什么传感器读数不能直接拿去用买回来的数字温度传感器数据手册上的精度指标是在标准条件下测的。实际装到设备里误差来源一下就变多了探头自身存在 offset 和 gain 误差探头位置和真正要测的风管中心温度有偏差传感器通电时自身发热会让读数偏高配电柜里的热风也会污染本地传感器的读数。所以我在每一版固件里都会做两件事校准和滤波。校准解决“读数不对”的问题滤波解决“读数不稳”的问题两个问题不分家缺一个都会让控制逻辑出乱子。3.2 两点校准法的具体操作校准不需要多高深的数学。我用的方法是找一个稳定的低温点冰水混合物0℃附近和一个稳定高温点用经过计量校准的精密温度计对比记录传感器原始读数和参考值。假设低温点传感器读数为 T1s参考值为 T1r高温点分别为 T2s 和 T2r那么增益系数和偏移量按下面公式算gain (T2r - T1r) / (T2s - T1s) offset T1r - gain * T1s把 gain 和 offset 存到 MCU 的 Flash 参数区每次读取后执行temp_calibrated raw_temp * gain offset;即可。下表是我某次实测的一组数据可以看到探头实际误差接近 0.5℃校准后基本压在 0.1℃ 以内。校准点传感器原始读数℃标准参考值℃误差℃低温点0.240.050.19高温点48.1247.620.50校准参数会随元器件老化缓慢漂移所以我在工程里预留了串口命令现场调试时可以随时查看原始值、重新校准而不需要重新烧录固件这个细节对售后很有价值。3.3 滤波策略HVAC 场景下的滑动平均加跳变剔除暖通场景的温度变化非常慢几秒钟之内温度几乎不会突变但 I2C 长线上偶发的干扰脉冲会让读数瞬间跳个好几度。这种毛刺如果直接进入控制逻辑轻则显示乱跳重则引发压缩机误动作。我采用的滤波方案是滑动平均加跳变剔除。先维护一个长度为 N 的环形缓冲区N 取 10 到 20 之间每来一个新值先和上一次有效值比较差值超过 3℃ 就认为是野值直接丢弃不参与平均正常值才写入缓冲区输出为缓冲区平均值。这样既平滑了传感器自身的微小抖动又不会让真正的温度快速上升被滤波掉。TM4C1294KCPDT 的浮点单元让这个计算量几乎可以忽略我甚至把滤波窗口长度做成了参数通过串口调试界面可以动态调节方便在不同热惯性场景下找到合适的平衡点。3.4 报警阈值的迟滞处理温度报警如果做成“超过阈值就报警低于阈值就恢复”在工程现场基本没法用因为压缩机启动后温度会快速波动频繁穿越阈值会让报警器响个不停。解决办法是给高报警和低报警分别设置迟滞回差。比如机组高温报警阈值设 70℃回差设 5℃那么只有温度升到 70℃ 才触发报警之后要降到 65℃ 以下才解除报警。这个区间避免了临界点附近的反复横跳也符合控制逻辑的工程习惯。代码实现上我用了一组结构体管理每个阈值点的状态typedef struct { float trigger_level; float hysteresis; uint8_t alarm_active; } temp_alarm_t; void temp_alarm_update(temp_alarm_t *alarm, float current) { if (!alarm-alarm_active current alarm-trigger_level) { alarm-alarm_active 1; } else if (alarm-alarm_active current alarm-trigger_level - alarm-hysteresis) { alarm-alarm_active 0; } }两路温度我各配了一套报警逻辑。远程温度的高报警用来联动压缩机降频保护本地温度的高报警则直接定位为 MCU 板卡故障级事件上报内容不同、处理策略也不同。4. HVAC 场景下的实测数据与调试踩坑记录4.1 实测环境与数据表现这个方案我在模拟空调箱送回风环境和冷库门频繁开关场景下各跑了一周。空调箱场景中远程探头绑在出风管内部本地探头放在控制器盒里冷库场景中远程探头放在库内货物附近本地探头放在电控箱内。下表是某段时间的稳定值对比。测点本地温度读数℃远程温度读数℃精密仪表参考℃偏差℃回风管26.7824.3324.290.04出风管26.8218.6718.520.15冷库内部28.31-3.22-3.310.09冷库电控箱34.1629.4429.320.12稳定状态下经过校准的远程温度与精密仪表偏差在 ±0.2℃ 以内完全满足一般 HVAC 控制需求。冷库门开关瞬间远程温度会出现一个短暂的抬升滑动平均窗口能很好地平抑这个波动不会造成压缩机误启停。4.2 踩坑一I2C 长线干扰导致的随机数据跳变这套方案第一次上了现场就遇到问题远程探头距离主控约 1.5 米读数大多数时候正常但每隔几分钟会突然蹦出一个离谱值比如 87℃ 或者 0xFF 上限。一开始怀疑是代码读时序有问题后来用示波器抓 SDA 线上的波形发现数据线上的下降沿明显变缓存在振铃和毛刺。排查过程是这样的先换短线测试确认代码没问题可以排除固件逻辑问题再量上拉电阻发现原设计用的 10kΩ 上拉在长线分布电容下驱动能力不足。把上拉换成 2.2kΩ 后波形明显改善再把普通平行线换成双绞屏蔽线数据跳变彻底消失。这个经历说明一个道理I2C 虽然抗干扰优于模拟信号但长线场景下上拉电阻选择、线缆类型都是影响可靠性的关键因素不能想当然。4.3 踩坑二本地温度随板卡负载波动另一个问题出在本地温度路。我原本以为板载温度传感器读数应该很稳定结果发现 MCU 跑满负载时本地温度会凭空升高 0.8℃ 左右。仔细排查两个因素叠加一是板卡功率变化引起 PCB 局部温升二是 ADC 参考电压在负载切换时发生微小波动被 NTC 分压网络放大。处理办法是分开看待本地温度如果真的关心板卡温度那么读数升高是真实物理现象不算错误使用时要留足余量但本地温度如果用来代表环境温度就必须把探头挪到远离发热器件的位置并加强滤波。我的结论是别指望一个传感器同时精确反映板卡温度和室温测温点的物理位置比算法更重要。4.4 调试心得先看裸数据再谈算法很多新手拿到开发板就急着调滤波和校准结果数据不对却不知道是通信问题还是换算问题。我的习惯是先用调试器把温度寄存器的原始十六进制值直接打出来对着数据手册人工换算一遍确认 I2C 通信和字节拼接没问题之后再加入滤波和校准层。这个习惯让我少走了大量弯路排查问题时也有清晰的证据链。5. 从测温节点到 HVAC 整机集成扩展思路与低功耗设计5.1 多探头轮询与地址扩展一套系统只测两路温度往往不够比如大型空调箱需要同时监测新风、回风、送风、盘管进出口多个位置。PJ85718DM 这类 I2C 传感器一般都有地址引脚通过 A0、A1 接高接低最多可以扩展出多个不同地址。轮询时只需要循环调用读取函数每路传感器之间留出几毫秒间隔即可。TM4C1294KCPDT 的 I2C 外设跑在标准模式下挂 5 到 8 个探头毫无压力。5.2 数据出口UART、Modbus 与 TCP 报文温度数据采集之后必须送出去才有意义。我在这一版工程里预留了三种出口UART 直接打印调试信息Modbus RTU 从机模式让上位机组态软件可以直接读取寄存器TCP 客户端模式定时把温度报文推到中央管理平台。报文格式很简单就是设备号加两路温度值加报警状态协议解析的工作量不大关键是这颗 MCU 同时跑传感轮询、滤波算法、协议栈和 LCD 刷新也不卡顿这正是当初选型时看中它的原因。5.3 低功耗与电池供电思路如果项目不是持续供电的空调机组而是冷链周转箱、移动监测节点这类电池供电设备可以启用 TM4C1294KCPDT 的休眠模式。温度缓变不需要连续采集我一般设置 1 到 5 分钟唤醒一次醒来后完成一轮采样、滤波、存储或上报然后重新睡去。由于 MCU 唤醒时间极短待机电流可以压到微安级一颗电池撑几个月不成问题。5.4 就地决策优先断网也能跑HVAC 系统里最怕的不是没数据而是通讯中断后设备失控。我在固件设计里把温度报警和机组保护逻辑放在了本地就算上位机断线、网络瘫痪MCU 依然能根据两路温度独立完成超温保护和风机联动。云端和上位机只承担监测和记录职能不参与核心控制决策。这个架构让整套系统的可靠性上了一个台阶也是这套方案能在工程现场站住脚的根本原因。最后再分享一个实操细节安装远程探头时一定要让探头尽量贴近真正需要控温的对象。冷库里探头悬在半空中和绑在货物包装表面读数能差出 1℃ 以上而控制逻辑只相信探头看到的世界。我后来在每一个探头上都标注了“测点位置说明”字段随报文一起上传方便现场做温度场分析时快速定位偏差来源。这套本地加远程的方案跑下来最大的收益不是省了一个控制器而是把温度数据从“看看而已”变成了真正可以用起来的安全控制参数。 
长河君 · 2026/10/22 1:09:46 · 阅读 1.2k 基于TM4C1294KCPDT与PJ85718DM的本地远程温度监测方案
做暖通空调控制的人大概都有过这种体会控制板放在配电柜或者电控箱里真正要监测的温度却在风管远端、室外机旁边或者冷库深处。温度传感器离主控太远模拟信号引过来容易衰减和受干扰就地放个小控制器又显得小题大做。我这次要分享的就是用 TM4C1294KCPDT 做主控、PJ85718DM 做远端探头的本地与远程温度监测方案兼顾嵌入式和 HVAC 两类场景。这套思路既不需要额外挂一块 PLC也不用把传感器信号拉得满场飞一条 I2C 总线、一颗带浮点运算的 MCU 就能把温度采集、校准、滤波、报警和通信全部收拢进来。整个项目做完我最深的感受是温度监测本身不难难的是把“本地温度”和“远程温度”这两路读数用对地方。下面从选型逻辑开始把硬件接入、驱动编写、校准滤波、实测数据和调试踩坑一条条讲透。适合正在做空调机组控制器、冷链监控节点或者嵌入式温控模块的朋友参考。1. 为什么拿“主控级 MCU”做测温节点TM4C1294KCPDT 的选型逻辑1.1 这颗芯片的底子到底有多厚TM4C1294KCPDT 属于 TM4C129x 系列Cortex-M4F 内核带硬件浮点单元最高主频能做到 120MHz。Flash 1MBSRAM 256KB外设资源非常齐全两路 12 位 ADC、多路 UART、I2C、SSI、USB还带定时器和 PWM。单看这些参数拿它做“一个测温节点”确实有点大材小用但这恰恰是很多人选型时容易走偏的地方。温度采集本身消耗的资源极小读一个寄存器的数据量还不到几十字节。真正的复杂度在别处数据怎么滤波、怎么校准、怎么和上位机通信、要不要挂 LCD 显示、报警输出怎么联动风机和压缩机。这一串需求堆下来8 位机往往写到最后四处挤资源而 Linux 板卡又是杀鸡用牛刀启动慢、功耗高、成本也压不住。TM4C1294KCPDT 正好站在中间位置算力足够跑各种滤波算法和协议解析功耗远低于板卡方案裸机开发也直接不依赖大型系统。1.2 温度监测任务比表面看起来复杂我在做这个项目之前也以为读温度嘛拿个传感器采一下然后算出来就完了。真正接手才明白工业现场和实验室最大的区别在于传感器本身有离散性同一批 PJ85718DM 探头之间的读数可能差出 1℃ 以上探头安装位置和实际关注点之间存在系统性温差远距离传输线上会有干扰偶发跳变数据会直接影响控制逻辑压缩机频繁启停对温度报警的迟滞要求极高没有回差的报警根本没法用。这些需求落到软件上就是滤波、校准死区、迟滞比较、故障诊断。用 8 位机写也不是不行但代码会写得非常局促。TM4C1294KCPDT 的浮点单元让滤波计算变得很轻松256KB SRAM 即使后面扩展记录历史温度曲线也绰绰有余。1.3 本地温度与远程温度的分工逻辑标题里的“本地”和“远程”容易让人误以为只是两个测点其实它们在系统里干的活完全不一样。我做的这套方案里本地温度指的是 MCU 电路板所在位置的温度主要用来做板卡过热保护、机柜散热判断偶尔也作为无远程数据时的兜底读数远程温度指的是 PJ85718DM 探头放在真实被测环境里的读数比如空调箱的出风口、制冷机组回气管路、冷库内部它才是控制逻辑真正依赖的主变量。这两路温度不能混用。如果拿本地机柜温度去控制风机整个逻辑会被板卡自热搞得一团糟反之拿远程温度去判断板卡是否过热等到报警时板卡可能已经热到降频了。所以从硬件设计开始就要把这两路分开规划。2. PJ85718DM 远端探头接入与本地传感器设计2.1 远端探头走 I2C 的接线细节PJ85718DM 这块传感器模块从用法上看是一个典型的 I2C 接口数字温度传感器四根线就能接跑VDD、GND、SDA、SCL。I2C 的好处在于信号是数字方波抗干扰能力远强于模拟电压传输探头放在几十米外读回来的值也不会因为线阻产生偏差。接线时有几个点需要特别注意。首先是上拉电阻I2C 总线的 SDA 和 SCL 必须接上拉。传感器模块自带上拉时主控端就不用再加模块没带上拉或者线上节点太多一般取 4.7kΩ。如果探头距离较远、总线电容偏大我会直接把上拉降到 2.2kΩ增大驱动能力代价是功耗略高一点。其次是线材远程探头我建议用双绞线屏蔽层单端接地不要两端都接地否则容易形成地环路反而引入新的干扰。2.2 驱动代码与温度换算流程写驱动之前先读数据手册确认寄存器地址。不同厂家的 I2C 数字温度传感器寄存器布局大同小异一般有一个配置寄存器、一个温度数据寄存器部分型号还有 EEPROM 用于校准。读取的流程固定为发起 I2C 写操作设置寄存器指针然后连续读两个字节拼接成 16 位数据后根据分辨率移位换算成摄氏度。下面这段代码是我在工程里实际用的简化版寄存器地址按该器件数据手册填进去即可#include tm4c1294_driver_i2c.h #define PJ85718DM_ADDR 0x48 // 根据A0/A1引脚电平确定 #define REG_CONFIG 0x01 #define REG_TEMP 0x00 float pj85718dm_read_temp(void) { uint8_t tx_data[1]; uint8_t rx_data[2]; uint16_t raw; float temp; // 设置寄存器指针指向温度寄存器 tx_data[0] REG_TEMP; i2c_write(PJ85718DM_ADDR, tx_data, 1); // 读取两个字节的温度数据 i2c_read(PJ85718DM_ADDR, rx_data, 2); // 拼接为16位原始值 raw ((uint16_t)rx_data[0] 8) | rx_data[1]; // 12位分辨率下每个LSB代表0.0625摄氏度 temp (float)((int16_t)raw 4) * 0.0625f; return temp; }这里有一个容易踩的坑温度寄存器的高字节是有符号的负温度时最高位为 1。如果直接当成无符号数换算零下温度会得到上百摄氏度的荒谬结果。所以代码里先把 16 位数据按 int16_t 解释再右移取有效位。右移时符号位会被保留低温才能正确计算。2.3 本地温度路NTC 分压与第二颗 I2C 传感器二选一本地温度我试过两种做法。第一种是板载 NTC 热敏电阻10kΩ 阻值、B 值 3950 的型号最常用搭配一个 10kΩ 精密电阻做分压输出接到 TM4C1294KCPDT 的 ADC 输入引脚用查表法或者 Steinhart-Hart 公式换算温度。好处是成本极低、不占总线资源坏处是 ADC 的噪声和参考电压波动会直接影响精度需要额外做滤波。第二种做法是直接再挂一颗同型号的 PJ85718DM 做本地温度采集代码几乎不用改精度和远程探头一致。因为 I2C 总线支持多设备只要把第二颗传感器的地址引脚设成不同电平就行。如果项目对成本不敏感我推荐第二种省去了标定 NTC 的麻烦两路温度的代码路径完全统一后续维护省心很多。2.4 供电与去耦看似小事实际很关键传感器的 VDD 建议直接用 TM4C1294KCPDT 输出的 3.3V但必须在模块附近放 0.1μF 陶瓷电容加 10μF 电解电容做去耦。远程探头如果走线超过 20cm最好在探头端也补一个 0.1μF 电容防止长线电感导致供电瞬间跌落。很多人忽略这一步结果温度数据时好时坏查了半天发现竟然是供电纹波把 I2C 时序搅乱了。3. 两路温度读数的校准、滤波与使用策略3.1 为什么传感器读数不能直接拿去用买回来的数字温度传感器数据手册上的精度指标是在标准条件下测的。实际装到设备里误差来源一下就变多了探头自身存在 offset 和 gain 误差探头位置和真正要测的风管中心温度有偏差传感器通电时自身发热会让读数偏高配电柜里的热风也会污染本地传感器的读数。所以我在每一版固件里都会做两件事校准和滤波。校准解决“读数不对”的问题滤波解决“读数不稳”的问题两个问题不分家缺一个都会让控制逻辑出乱子。3.2 两点校准法的具体操作校准不需要多高深的数学。我用的方法是找一个稳定的低温点冰水混合物0℃附近和一个稳定高温点用经过计量校准的精密温度计对比记录传感器原始读数和参考值。假设低温点传感器读数为 T1s参考值为 T1r高温点分别为 T2s 和 T2r那么增益系数和偏移量按下面公式算gain (T2r - T1r) / (T2s - T1s) offset T1r - gain * T1s把 gain 和 offset 存到 MCU 的 Flash 参数区每次读取后执行temp_calibrated raw_temp * gain offset;即可。下表是我某次实测的一组数据可以看到探头实际误差接近 0.5℃校准后基本压在 0.1℃ 以内。校准点传感器原始读数℃标准参考值℃误差℃低温点0.240.050.19高温点48.1247.620.50校准参数会随元器件老化缓慢漂移所以我在工程里预留了串口命令现场调试时可以随时查看原始值、重新校准而不需要重新烧录固件这个细节对售后很有价值。3.3 滤波策略HVAC 场景下的滑动平均加跳变剔除暖通场景的温度变化非常慢几秒钟之内温度几乎不会突变但 I2C 长线上偶发的干扰脉冲会让读数瞬间跳个好几度。这种毛刺如果直接进入控制逻辑轻则显示乱跳重则引发压缩机误动作。我采用的滤波方案是滑动平均加跳变剔除。先维护一个长度为 N 的环形缓冲区N 取 10 到 20 之间每来一个新值先和上一次有效值比较差值超过 3℃ 就认为是野值直接丢弃不参与平均正常值才写入缓冲区输出为缓冲区平均值。这样既平滑了传感器自身的微小抖动又不会让真正的温度快速上升被滤波掉。TM4C1294KCPDT 的浮点单元让这个计算量几乎可以忽略我甚至把滤波窗口长度做成了参数通过串口调试界面可以动态调节方便在不同热惯性场景下找到合适的平衡点。3.4 报警阈值的迟滞处理温度报警如果做成“超过阈值就报警低于阈值就恢复”在工程现场基本没法用因为压缩机启动后温度会快速波动频繁穿越阈值会让报警器响个不停。解决办法是给高报警和低报警分别设置迟滞回差。比如机组高温报警阈值设 70℃回差设 5℃那么只有温度升到 70℃ 才触发报警之后要降到 65℃ 以下才解除报警。这个区间避免了临界点附近的反复横跳也符合控制逻辑的工程习惯。代码实现上我用了一组结构体管理每个阈值点的状态typedef struct { float trigger_level; float hysteresis; uint8_t alarm_active; } temp_alarm_t; void temp_alarm_update(temp_alarm_t *alarm, float current) { if (!alarm-alarm_active current alarm-trigger_level) { alarm-alarm_active 1; } else if (alarm-alarm_active current alarm-trigger_level - alarm-hysteresis) { alarm-alarm_active 0; } }两路温度我各配了一套报警逻辑。远程温度的高报警用来联动压缩机降频保护本地温度的高报警则直接定位为 MCU 板卡故障级事件上报内容不同、处理策略也不同。4. HVAC 场景下的实测数据与调试踩坑记录4.1 实测环境与数据表现这个方案我在模拟空调箱送回风环境和冷库门频繁开关场景下各跑了一周。空调箱场景中远程探头绑在出风管内部本地探头放在控制器盒里冷库场景中远程探头放在库内货物附近本地探头放在电控箱内。下表是某段时间的稳定值对比。测点本地温度读数℃远程温度读数℃精密仪表参考℃偏差℃回风管26.7824.3324.290.04出风管26.8218.6718.520.15冷库内部28.31-3.22-3.310.09冷库电控箱34.1629.4429.320.12稳定状态下经过校准的远程温度与精密仪表偏差在 ±0.2℃ 以内完全满足一般 HVAC 控制需求。冷库门开关瞬间远程温度会出现一个短暂的抬升滑动平均窗口能很好地平抑这个波动不会造成压缩机误启停。4.2 踩坑一I2C 长线干扰导致的随机数据跳变这套方案第一次上了现场就遇到问题远程探头距离主控约 1.5 米读数大多数时候正常但每隔几分钟会突然蹦出一个离谱值比如 87℃ 或者 0xFF 上限。一开始怀疑是代码读时序有问题后来用示波器抓 SDA 线上的波形发现数据线上的下降沿明显变缓存在振铃和毛刺。排查过程是这样的先换短线测试确认代码没问题可以排除固件逻辑问题再量上拉电阻发现原设计用的 10kΩ 上拉在长线分布电容下驱动能力不足。把上拉换成 2.2kΩ 后波形明显改善再把普通平行线换成双绞屏蔽线数据跳变彻底消失。这个经历说明一个道理I2C 虽然抗干扰优于模拟信号但长线场景下上拉电阻选择、线缆类型都是影响可靠性的关键因素不能想当然。4.3 踩坑二本地温度随板卡负载波动另一个问题出在本地温度路。我原本以为板载温度传感器读数应该很稳定结果发现 MCU 跑满负载时本地温度会凭空升高 0.8℃ 左右。仔细排查两个因素叠加一是板卡功率变化引起 PCB 局部温升二是 ADC 参考电压在负载切换时发生微小波动被 NTC 分压网络放大。处理办法是分开看待本地温度如果真的关心板卡温度那么读数升高是真实物理现象不算错误使用时要留足余量但本地温度如果用来代表环境温度就必须把探头挪到远离发热器件的位置并加强滤波。我的结论是别指望一个传感器同时精确反映板卡温度和室温测温点的物理位置比算法更重要。4.4 调试心得先看裸数据再谈算法很多新手拿到开发板就急着调滤波和校准结果数据不对却不知道是通信问题还是换算问题。我的习惯是先用调试器把温度寄存器的原始十六进制值直接打出来对着数据手册人工换算一遍确认 I2C 通信和字节拼接没问题之后再加入滤波和校准层。这个习惯让我少走了大量弯路排查问题时也有清晰的证据链。5. 从测温节点到 HVAC 整机集成扩展思路与低功耗设计5.1 多探头轮询与地址扩展一套系统只测两路温度往往不够比如大型空调箱需要同时监测新风、回风、送风、盘管进出口多个位置。PJ85718DM 这类 I2C 传感器一般都有地址引脚通过 A0、A1 接高接低最多可以扩展出多个不同地址。轮询时只需要循环调用读取函数每路传感器之间留出几毫秒间隔即可。TM4C1294KCPDT 的 I2C 外设跑在标准模式下挂 5 到 8 个探头毫无压力。5.2 数据出口UART、Modbus 与 TCP 报文温度数据采集之后必须送出去才有意义。我在这一版工程里预留了三种出口UART 直接打印调试信息Modbus RTU 从机模式让上位机组态软件可以直接读取寄存器TCP 客户端模式定时把温度报文推到中央管理平台。报文格式很简单就是设备号加两路温度值加报警状态协议解析的工作量不大关键是这颗 MCU 同时跑传感轮询、滤波算法、协议栈和 LCD 刷新也不卡顿这正是当初选型时看中它的原因。5.3 低功耗与电池供电思路如果项目不是持续供电的空调机组而是冷链周转箱、移动监测节点这类电池供电设备可以启用 TM4C1294KCPDT 的休眠模式。温度缓变不需要连续采集我一般设置 1 到 5 分钟唤醒一次醒来后完成一轮采样、滤波、存储或上报然后重新睡去。由于 MCU 唤醒时间极短待机电流可以压到微安级一颗电池撑几个月不成问题。5.4 就地决策优先断网也能跑HVAC 系统里最怕的不是没数据而是通讯中断后设备失控。我在固件设计里把温度报警和机组保护逻辑放在了本地就算上位机断线、网络瘫痪MCU 依然能根据两路温度独立完成超温保护和风机联动。云端和上位机只承担监测和记录职能不参与核心控制决策。这个架构让整套系统的可靠性上了一个台阶也是这套方案能在工程现场站住脚的根本原因。最后再分享一个实操细节安装远程探头时一定要让探头尽量贴近真正需要控温的对象。冷库里探头悬在半空中和绑在货物包装表面读数能差出 1℃ 以上而控制逻辑只相信探头看到的世界。我后来在每一个探头上都标注了“测点位置说明”字段随报文一起上传方便现场做温度场分析时快速定位偏差来源。这套本地加远程的方案跑下来最大的收益不是省了一个控制器而是把温度数据从“看看而已”变成了真正可以用起来的安全控制参数。