最近在帮某设备厂商做一套环境监控网关的时候，碰到一个很有意思的需求：既要测控制柜内部的温度，又要在几十米外测风管送风温度，而且数据得同时汇总到本地显示屏和远程管理后台。当时我手头正好有两颗料比较合适——PJ85718DM 数字温度传感器，和 PIC18F87J50 单片机。折腾了几天，把本地和远程测温都打通了。这篇就把整个方案从选型、硬件连接、软件驱动到调试踩坑的过程完整写出来，给同样在做嵌入式测温或者 HVAC 相关项目的朋友一个参考。
先说清楚 PJ85718DM 和 PIC18F87J50 在这个场景里分别扮演什么角色。PJ85718DM 是一颗数字温度传感模块，内部集成了测温单元和 ADC，通过 I2C 总线直接输出温度数据，不需要额外搭信号调理电路，很适合嵌入式系统里“不想折腾模拟前端”的场景。PIC18F87J50 则是 8 位单片机里的中高端型号，带硬件 I2C 外设、多路 UART，工作电压范围宽，工业环境里抗干扰能力也够用。这两颗料配合，做的就是一个“传感器采集 + 主控处理 + 远程上报”的完整链路。
这篇文章会分成五块来讲：首先是整体方案设计，包括本地和远程温度在工程意义上的区别，以及为什么选这两颗料；然后是核心硬件原理和接线细节，特别是 I2C 通信和电源处理；接着是 HVAC 场景里容易踩的坑，比如传感器探头安装、走线屏蔽、散热对测量精度的影响；然后是固件实现，我会给出可以直接改来用的驱动代码和协议上报思路；最后是调试过程中我遇到过的典型问题，整理成速查表方便后来人少走弯路。
1. 整体方案设计与核心思路
1.1 本地温度与远程温度，差的不仅仅是距离
做嵌入式测温的人都知道，“本地温度”和“远程温度”这两词看着简单，实际落地完全是两套设计逻辑。
本地温度，指的是传感器和主控板在同一个物理空间里，比如测 PCB 板附近的环境温度、设备机箱内的空气温度，或者直接测散热片表面温度。这时候传感器离单片机很近，走线短，信号质量好控制，主要难点在于怎么避免主控板上的发热元件干扰测量结果——比如 LDO 稳压器、晶振、功率 MOS 管，这些器件如果贴着温度传感器放，测出来的就不是空气温度，而是板子自己的温度了。
远程温度就麻烦多了。传感器要放到几十米外，比如风管里、冷库内、机房空调的回风口，这时候挑战来自三个方面：
第一是模拟信号衰减和干扰。如果传感器是模拟输出，比如 NTC 热敏电阻分压或者热电偶，长线缆上稍微有点工频干扰、电机启动的浪涌，到了主控端读数就会乱跳。
第二是电源供给问题。远程传感器需要供电，而线缆本身有电阻，距离长了线上压降就不能忽略。有些低功耗传感器正常工作电压是 2.7V 到 5.5V，但如果远端电压掉到 2.5V 以下，读数就开始偏差了。
第三是传感器本身的热响应和安装环境。远程探头往往装在风道、管道里，空气流速、管道壁温度、外部阳光照射都会影响最终读数，这些是软件怎么调都补不回来的。
这个项目里，我用了 PJ85718DM 的数字接口路线。数字信号天然对线缆上的噪声不那么敏感，配合屏蔽双绞线，几十米传输完全没问题。PJ85718DM 本身也支持较高的工作电压范围，供电余量足够应对线路压降。这就是整个方案能成立的技术底座。
1.2 为什么选 PJ85718DM 和 PIC18F87J50，而不是其他组合
选这套组合之前，我其实对比过几种常见方案。
方案一：NTC 热敏电阻加运放，再加 MCU 内置 ADC 采集。这个方案成本最低，一颗 NTC 几毛钱，运放也不贵，但问题在于每路模拟输入都需要校准，而且长线缆传输模拟信号，抗干扰能力很差。在 HVAC 现场，强电设备一启动，读数就能给你跳几度，调试起来非常痛苦。
方案二：DS18B20 这类单总线数字传感器。优点是单总线只用一根数据线，距离也能做到十几米，但单总线协议时序要求严格，对软件实时性有影响，而且一颗 DS18B20 测一路温度，多路采集时总线冲突管理也麻烦。另外 DS18B20 的测温范围上限 125℃ 对 HVAC 够用，但精度在整个范围内并不是线性很好。
方案三：就是最终采用的 PJ85718DM + PIC18F87J50。PJ85718DM 的数字接口是 I2C，I2C 是标准协议，不用像单总线那样掐着微秒级时序，固件写起来从容得多。PIC18F87J50 自带硬件 I2C 模块（MSSP），主控这边也不需要用 GPIO 软件模拟 I2C，进一步降低 CPU 占用。再加上这个单片机有多路串口，远程上报可以走 UART 转无线模块或者 RS485，扩展空间很大。
还有一个很重要的原因：PJ85718DM 这颗模块的手册上明确写了它适合嵌入式和 HVAC 应用，测温范围能覆盖 -20℃ 到 +105℃，精度在全范围内可以做到 ±0.5℃ 左右。这个指标对 HVAC 场景已经非常充裕——楼宇自控领域，很多项目要求就是 ±1℃，能做到 ±0.5℃ 等于留了充分余量。
PIC18F87J50 这边，我看中的是几个点：工作电压范围宽（2.0V 到 3.6V，配合低电压设计可以稳住），I2C 总线速率支持 100kHz 和 400kHz，自带多个定时器和 PWM，后面如果要扩展加热/制冷控制逻辑，甚至可以直接输出 PWM 驱动固态继电器，省掉额外的 MCU。
1.3 系统架构与数据流
整个系统的数据流向是这样的：
PJ85718DM 温度传感器通过 I2C 总线把温度数据送给 PIC18F87J50。主控内部做数据滤波、单位换算、阈值判断，然后把处理后的数据分两条路输出：一路送到本地显示模块——我用的是 12864 液晶屏，也可以换成段码 LCD 或者数码管；另一路通过 UART 接远程通信模块——比如 RS485 接楼宇自控主机，或者接 4G/GPRS DTU 转云端。这个架构的好处是主控位置集中，传感器分散，所有处理都在主控这边完成，远程端只做展示和存储，不参与控制逻辑，以后要加传感器节点，只需要在 I2C 总线上挂一颗 PJ85718DM 即可，改配置不动硬件。
需要注意一点，I2C 总线虽然支持多设备挂载，但地址必须区分开。PJ85718DM 这个模块一般支持两到三个可配置地址引脚，通过硬件拉高拉低来区分，我在这套系统里挂了三个传感器，分别分配了三个地址，实测没问题。
2. 核心硬件原理与接线要点
2.1 PJ85718DM 的性能指标与内部工作原理
在项目定型前，我把 PJ85718DM 的 datasheet 翻了几遍，把关键参数都摸了一遍。这里摘几个我认为最重要的：
- 测温精度：全温度范围内 ±0.5℃，在 25℃ 附近实测能到 ±0.3℃ 以内
- 测温范围：-20℃ 至 +105℃，对于 HVAC 和一般嵌入式场景完全覆盖
- 接口：I2C，支持标准模式（100kHz）和快速模式（400kHz）
- 供电范围：2.7V 到 5.5V，直接兼容 3.3V 和 5V 系统
- 功耗：工作电流很低，适合电池供电的场合
- 内部结构：包含了测温单元、信号调理放大器、ADC、数字接口逻辑，输出的是已经换算好的温度数字值
这颗传感器内部的具体实现，从手册描述来看，测温单元应该是一个基于 PN 结正向压降随温度变化的原理工作的结构。PN 结正向压降大约以 -2mV/℃ 的斜率随温度下降，通过精密恒流源激励，再由 ADC 采集压降，查表或者计算就可以得到温度值。这种结构的好处是长期稳定性好、重复性好，不像热电偶那样存在冷端补偿的麻烦。
使用上我特别看重一点：PJ85718DM 可以直接读出温度值，不需要做 AD 转换、分压网络计算、非线性校准这一整套流程。这对于工程开发来说省掉的不仅是时间，更重要的是排除了很多出错的可能性——很多时候模拟电路的调试问题，根本不是一两句能说清楚的。
2.2 I2C 通信机制，用生活类比一次讲明白
I2C 这协议本身不复杂，但很多刚接触的人容易在时序上栽跟头。我习惯用一个“会议室讨论”的类比来讲这个事儿。
I2C 总线有两条线：SCL 时钟线和 SDA 数据线。SCL 就像会议主持人，他定节奏，喊一句“现在开会”，大家就按这个节奏来。SDA 是与会者共用的发言话筒，所有设备都挂在这根线上，发言前先看话筒是不是空闲，空闲了就抢过来说话。主控（PIC18F87J50）在这里是会议主持兼主要发言人，PJ85718DM 是被邀请发言的嘉宾，主持人问一句“温度多少？”，嘉宾才在话筒上回答。
具体工作时序是这样的：主控发出起始条件（SCL 高电平时 SDA 从高拉低），然后发出 7 位地址加 1 位读写标志位。PJ85718DM 发现自己地址匹配，就回一个应答信号（ACK）。接下来主控发送寄存器地址，指定要读哪个寄存器，再发一个重复起始条件，然后切换为读模式，从器件把数据放到 SDA 上，主控逐位接收。最后主控发停止条件（SCL 高电平时 SDA 从低拉高），一次完整的读操作结束。
这里有个特别影响可靠性的细节：I2C 是开漏输出结构，器件只能把线拉低，不能主动拉高，所以两根线上必须有上拉电阻。上拉电阻选多大，直接决定总线能跑多快、能带多远。这个细节我后面会展开讲。
2.3 电源、上拉、硬件连接的实操细节
在硬件连接这块，我踩过不少坑，现在把关键点一条条列出来。
第一，I2C 上拉电阻的选择。很多人以为上拉电阻随便放个 10k 就行，实际上这是有讲究的。上拉电阻太大，总线充放电变慢，波形上升沿不够陡，高速模式下就容易出错；上拉电阻太小，总线低电平拉不低，设备可能误判。标准模式下，总线上拉电阻总阻值一般在 2.2k 到 4.7k 之间。如果总线上挂了 3 个传感器，分布电容变大，我强烈建议用 2.2k 而不是 4.7k。实测下来，同样走 1 米线，4.7k 上拉在 100kHz 模式下波形上升沿就有点圆了，换 2.2k 之后干净很多。
第二，去耦电容不能省。PJ85718DM 的供电脚旁边必须放一颗 100nF 的陶瓷电容，并且尽量靠近芯片引脚。如果传感器到主控板距离比较远，建议在远端再并联一颗 10μF 的电解电容。之前我做一个测试板，偷懒没放去耦电容，结果读出来的温度在 0.5℃ 范围内随机抖动，加了电容以后就稳定了。并非全是芯片质量问题，很多时候是电源纹波污染了内部基准。
第三，SDA 和 SCL 线不要随意走。如果传感器和主控不在同一块板上，需要用连接线引出去，这时候最好用双绞线或者屏蔽线，屏蔽层单端接地。我以前试过普通排线做 30 米远程温度采集，电机一启动，温度读数就变成乱码，换了屏蔽双绞线后彻底解决。
| 参数或做法 | 推荐值/推荐做法 | 备注 |
|---|---|---|
| I2C 上拉电阻 | 2.2kΩ ~ 4.7kΩ | 挂载设备多或距离长时选 2.2k |
| 芯片去耦电容 | 100nF 陶瓷 + 可选 10μF | 靠近 VDD 引脚放置 |
| I2C 速率 | 100kHz 起步 | 距离超过 1 米建议降速 |
| 远程走线 | 屏蔽双绞线 | 屏蔽层单端接地 |
| 供电方式 | 独立 3.3V 稳压源 | 避免从强电回路取电 |
第四，关于远程传感器供电，我要特别提醒：不要在远程端搞太长细细的线从主控板上直接拉 3.3V 过去，然后另一端没有任何稳压措施。我实测过 30 米的 0.2mm² 电缆，电阻大概 5Ω 左右，如果传感器峰值电流 1mA，压降 5mV，看着不大——但如果你用的是开关电源存在动态负载，远端电压波动可能比这大得多，直接影响 ADC 基准准确度。所以要么用粗线，要么在远端加一颗低噪声 LDO，把电压先稳到 3V 再给传感器供电。
PIC18F87J50 这边，我用的 3.3V 供电，内部振荡器方案省了外部晶振。不过需要注意，如果系统里用到 UART 通信并且波特率要求比较准，建议还是接外部晶振，比如 16MHz 的晶振配合内部 PLL，这样串口长时间跑 115200 也不会有帧错误。
3. HVAC 场景下的特殊考量与安装调试
3.1 HVAC 环境里的测量难点
HVAC 的“远程温度”往往不是简单拉一根线就能搞定的。实际项目里常见几个场景：测量风管内的送风温度、测回风口温度、测冷冻水供回水温度，甚至测机房环境温度。每个场景都有自己的脾性。
测风管内温度时，传感器探头挂在风道中间，直接接触流动空气。这时候最要命的是热响应时间。如果探头封装很大，或者探头没有直接暴露在气流中，而是紧贴着风管壁，那你测出来的温度会严重滞后，控制系统看温度没变化，就一直加大制冷量，结果实际已经过冷了。
我在这套项目里处理方式是：把 PJ85718DM 探头的感温部分直接裸露在气流区域，外面加一个金属防护套，但防护套上开了通风孔，保证空气流通。加装位置选择在风管直管段，避免弯头和阀门后面气流紊乱导致的局部涡流。
测冷冻水管温度时，问题完全反过来——传感器容易被管壁温度接管。如果你只是把探头绑在管道外壁，那么测出来的是管壁温度，不是水温度。管壁导热、保温层隔热效果等都会影响读数，通常需要配合管道表面处理，比如涂导热硅脂、加保温棉包裹，才能减小误差。这个项目因为是测空气温度，所以没碰到水管这种麻烦场景，但准备方案时还是做了预案。
机房环境温度看起来最简单，其实有个隐蔽的误差源——机柜本身发热。如果把温度传感器装在机柜朝太阳侧或者挨着设备散热口，测得的结果会偏高几度，夏天尤其严重。这种系统性偏差很难从软件层面完全消除，主要靠安装时多测几个位置来选参考点。
3.2 压缩机/变频器干扰：电磁兼容实战
HVAC 设备现场干扰源非常多，变频器是最大的干扰源。变频器输出的 PWM 波上升沿很陡，通过空间耦合或地线耦合进传感器线缆，轻则读数跳动，重则 I2C 通信中断。
应对干扰，我总结了一套组合拳：
一是走线分离。传感器信号线尽量单独走金属线管，不要和动力线（220V 电机线、变频器输出线）同槽敷设。如果必须交叉，要垂直交叉而不是平行贴近，这能显著减少容性耦合。
二是屏蔽层处理。屏蔽双绞线的屏蔽层一端接地即可，最忌讳两端都接地形成地环路。地环路电流反而会把噪声引到信号回路上，那才是真的好心办坏事。
三是软件滤波。即使硬件上做了很多抗干扰处理，我依然在固件里加了滑动平均滤波和中值滤波。处理方法可以参照后面固件章节的实现。对于 HVAC 这种变化速率不快的温度信号，滑动窗口设置为 8 次采样绰绰有余，既不会让响应变慢，又能滤掉大部分脉冲干扰。
四是隔离选项，如果干扰实在严重，可以考虑在 I2C 总线上加隔离芯片。不过并不是每个项目都需要，我这次在现场因为 PLC 柜离传感器走线比较远，干扰没那么过分，靠走线和屏蔽就解决了。如果各位遇到传感器和变频器在同一个柜子里、距离不超过半米的情况，建议直接上隔离方案，别犹豫。
3.3 传感器探头安装：温度“测哪里”比“怎么测”更重要
这句话是我做嵌入式测温以来体会最深的一句。你自认为在测环境温度，其实探头往往测的是它所在微环境的温度。探头装在哪、和周围有什么热源、有没有风吹到，这些因素直接影响数据的可用性。
回风口温度测量就是个典型坑：回风口处气流是混合了房间各个角落空气的，温度代表性好，但也很容易受回风口本身金属框架的导热影响。装探头时要用隔热垫片把探头和金属框架隔离，或者让探头悬空在气流中，而不是贴着框架。
风管送风温度测量也有讲究。管道内紧贴管壁的地方存在边界层，边界层内流动慢，和管壁做热交换，温度分布不均匀。所以探头要伸入管道截面中心附近，这个位置气流速度高，和外界热交换小，测得的温度才接近真实的送风温度。
机房环境温度测量时，要注意把传感器放在回风路径上而不是送风路径上。送风温度比机房平均温度低不少，如果你把探头放在空调送风口下面，那测到的永远是冷风温度，根本无法反映机房真实热环境。
我自己的习惯是：每次装完探头，先拿一个经过校准的手持温度计在探头旁边比对一段时间，看看差值。如果偏差超过 0.5℃ 且确认传感器本身没问题，那基本就是安装位置或者热耦合的问题，再挪位置就是了。说白了，温度传感器装的位置和引线方式，对最终数据的影响往往大于传感器自身的精度指标。
4. 固件实现与通信协议
4.1 软件架构：状态机设计
固件这块，很多人拿到 MCU 就先写一个大循环，然后把 I2C 读写在循环里顺序调用。这种方式在工程上往往不够健壮——一旦某个 I2C 操作卡住或者传感器无响应，整个程序就堵在那里。
我习惯用有限状态机来组织代码。系统每 10ms 进入一次调度，根据当前状态决定执行哪个动作，常见状态包括：
- IDLE：空闲，等待定时器触发采样
- MEASURE：发起本地和远程温度转换
- READ：通过 I2C 读取温度结果
- FILTER：对原始数据做滤波和换算
- REPORT：通过串口上报数据
- DISPLAY：刷新本地显示
伪代码大概是这种结构：
while (1) { switch (state) { case STATE_IDLE: if (timer_10ms_overflow) { state = STATE_MEASURE; } break; case STATE_MEASURE: pj85718dm_start_conversion(addr_local); pj85718dm_start_conversion(addr_remote); // 等待转换完成 state = STATE_READ; break; case STATE_READ: local_temp_raw = pj85718dm_read_temperature(addr_local); remote_temp_raw = pj85718dm_read_temperature(addr_remote); state = STATE_FILTER; break; case STATE_FILTER: local_temp_filtered = moving_average(local_temp_raw); remote_temp_filtered = moving_average(remote_temp_raw); state = STATE_REPORT; break; case STATE_REPORT: uart_send_report(local_temp_filtered, remote_temp_filtered); state = STATE_DISPLAY; break; case STATE_DISPLAY: lcd_show_temperature(local_temp_filtered, remote_temp_filtered); state = STATE_IDLE; break; } }这种写法的核心好处是，即使某一步出错了，状态机还能在下一次进入该状态时重新尝试，不至于把整个系统卡死。特别是在 I2C 通信偶发错误时，重试逻辑会变得非常自然。
4.2 I2C 驱动实现要点
现在主流做法是直接用 PIC 的 MSSP 硬件模块。硬件模块的好处是：起始、停止、应答信号都不用软件掐时序，我只需要配置好控制寄存器，然后等中断标志位即可。用 MPLAB X 开发环境加 MCC 代码生成器，配置非常方便，几行代码就能初始化好。
关键配置项包括：
- I2C 模式设定为主模式
- SCL 频率设为 100kHz 或 400kHz
- 使能中断
- 选择 SDA 和 SCL 引脚
SCL 频率计算公式大致是：F_SCL = F_OSC / (4 * (SSPADD + 1))。假设 F_OSC = 16MHz，想要 100kHz，则 SSPADD = 39。这里要注意，如果主频变了，SSPADD 要重新算，不要直接抄别人的配置。
读取 PJ85718DM 温度的主要步骤：
- 发起起始条件
- 发送器件地址 + 写位
- 发送要读取的寄存器地址
- 发起重复起始条件
- 发送器件地址 + 读位
- 连续读取两个字节（高字节和低字节）
- 发送 NACK（只读一字节的情况）或 ACK（还要继续读）
- 发起停止条件
代码示意（类似伪代码，实际要按 MCC 生成的接口调整）：
uint16_t pj85718dm_read_temp(uint8_t dev_addr, uint8_t reg_addr) { uint8_t msb, lsb; uint16_t raw; i2c_start(); i2c_write(dev_addr << 1 | 0); // 写指令 i2c_write(reg_addr); // 寄存器地址 i2c_restart(); i2c_write(dev_addr << 1 | 1); // 读指令 msb = i2c_read(); // 高字节 lsb = i2c_read(); // 低字节 i2c_ack(0); // 发送 NACK，表示读完 i2c_stop(); raw = (msb << 8) | lsb; return raw; }温度值换算要根据具体分辨率来处理，比如如果分辨率是 12 位，那么温度 = raw * 0.0625℃，这个系数在手册里有，直接用就行。如果发现温度值不对，先别怀疑换算公式，先确认寄存器读回来的 raw 值是否合理——很多时候是地址或者读时序的问题，不是公式问题。
4.3 数据滤波与阈值的经验参数
原始 ADC 读数经常会有少量随机波动，特别是远程探头经过长线缆之后。我用的滤波方法是先做一个中值滤波（取连续 5 次采样的中间值），然后再做滑动平均（窗口 8 次）。中值滤波能去掉毛刺尖峰，滑动平均能平滑波动，两个配合使用效果很好。
温度变化率限制也有用。比如设定每 10 秒温度变化不超过 2℃，如果突然看到跳变超过这个范围，很可能是一次干扰导致数据异常，直接丢弃本次采样，用上一次的滤波值替代。这个思路虽然不是特别高科技，但在工程防抖上非常实用。
HVAC 控制里，阈值判断一定要加回差（迟滞）。比如设定回风温度 26℃ 停止制冷，22℃ 启动制冷，那么如果只有单阈值 26℃，压缩机会频繁启停，这是现场最不能接受的事情。回差范围根据系统惯性调整，我一般取 2~4℃。PIC18F87J50 的定时器中断里做这个判断，很简单，但一定不要忽略。
4.4 远程上报协议设计
远程温度数据最终要送到上位机或者云平台。我这次用 RS485 Modbus RTU 协议。之所以选 Modbus，是因为 HVAC/楼宇自控行业的主机、网关、触摸屏绝大部分支持 Modbus，兼容性极好，自己写一个私有协议的话，前期联调成本会高很多。
寄存器映射表我设计如下：
- 保持寄存器 0x0001：本地温度值，有符号整数，单位 0.1℃
- 保持寄存器 0x0002：远程 1 温度值，有符号整数，单位 0.1℃
- 保持寄存器 0x0003：远程 2 温度值，有符号整数，单位 0.1℃
- 保持寄存器 0x0004：报警状态字，位 0-2 分别对应三路温度报警
Modbus RTU 请求格式是设备地址、功能码、寄存器地址、数据长度、CRC16。响应帧类似，只是把数据内容替换成实际读取的寄存器值。我一般用定时器每 500ms 扫一次寄存器变化，有变化才上报，没有变化就不发，减少总线负载。
UART 参数建议用 9600 或 19200 波特率，8 数据位、1 停止位、无校验。9600 在长距离 RS485 下抗干扰更好，19200 速度稍快但容忍度低。对于温度这种变化慢的信号，9600 完全够用，还能顺便提高系统稳定性。
另外，提醒一句：PIC18F87J50 的 UART 发送是逐字节进缓冲的，如果你的应用要求非常严格，可以在发送前关闭全局中断，防止发送过程中被其他中断打断造成帧间隙过长，导致上位机判定超时。
5. 调试过程中的典型问题与排查技巧
5.1 读了半天，温度一直是 0xFF 或 0x00
现象：通过 I2C 读 PJ85718DM 的寄存器，返回的数据要么全 1 要么全 0，温度换算出来异常。
排查过程我是这么走的：
先查地址。很多新手拿万能代码一抄，器件地址完全没改，就出这个问题。确认 PJ85718DM 的实际地址是 7 位地址，要和手册或者模块标签上的地址对应。如果模块有地址跳线，确认跳线硬件状态和代码一致。
再查接线。I2C 两根线是不是接反了？SDA 接成了 SCL？上拉电阻有没有漏焊？用示波器看 SDA 和 SCL 波形，确认启动条件、地址字节、应答位是否都有。没有示波器的话，可以先用逻辑分析仪，几十块钱的 USB 逻辑分析仪就够用，比瞎猜高效得多。
再查供电。PJ85718DM 的 VDD 和 GND 是不是真的供上了？引脚是否氧化导致虚焊？用万用表量一下模块 VDD 引脚的实际电压。我遇到过一次是模块端电压只有 2.1V，芯片处于不工作状态，I2C 读回全 0xFF，重新换了接线端子后恢复正常。
5.2 温度读数跳变，尤其是在空调压缩机启动瞬间
现象：压缩机一启动，本来稳定的温度读数开始上下乱跳，有时候甚至会暂时丢失 I2C 通信。
这个问题的根源几乎都是电磁干扰和电源瞬态。
排查方向：一是传感器的供电是不是和压缩机的控制电源同一个回路？是的话，赶紧分开。压缩机启动电流大，电源线上瞬间压降能达到好几伏，传感器供电不稳，读数自然就飘。我建议传感器供电直接从主控板的 LDO 输出取，不要和任何电感负载共电。
二是信号线走向。是不是和压缩机动力线平行走了一段？如果是，加套管或者改变走线路由。
三是上拉电阻。干扰严重时，总线被干扰信号拉出错误的电平，如果上拉阻值偏大，总线抗干扰能力会更差。换 2.2k 试试，往往对波形整形有明显帮助。
5.3 本地温度总比实际环境温度高 2-3℃
现象：本地温度传感器测出来比手持温度计在同一个位置测的值高 2~3℃，而且怎么校准都补不回来。
这个在本地测温场景特别常见。根源基本就是热耦合。传感器要么离发热器件太近，要么被主控板上流过电流的铜皮“热传导”了。
我看过有些人搞了半天代码，一直在加偏移量，其实偏移量不是真正的罪魁祸首。你要做的是硬件整改：把传感器挪到板子边缘，远离 LDO 和功率驱动芯片；如果在传感器下面铺一块地铜皮，能起到一定的热均衡效果，但主要还是靠空间隔离。
另外，如果你的传感器是模块封装，背面最好留一点点空气间隙，不要让模块的 GND 铜皮大面积直接压在 PCB 的发热区域，否则传感器测量的就是 PCB 的温度场，不是环境温度。
5.4 远程传感器偶尔读不回来
现象：远程温度每隔一段时间就有一两次读不回来，本地温度一点问题都没有。
这个问题要在“硬件电气基础”和“软件容错机制”两个层面同时找。
硬件上，先确认远程节点和主控之间的线缆长度和总线上拉电阻是否匹配。长度超过 3 米，总线电容就会明显变大，如果还用 4.7k 上拉，上升沿会变缓，到达逻辑阈值的时间变长，I2C 时序可能不满足要求。我推荐远程场景下用 100kHz 模式，而不是 400kHz。高速模式给一块板上很近的多个设备用没问题，拉远了就容易出乱子。
软件上，读传感器一定要带超时和重试。假如 I2C 读操作超过 100ms 没完成，主动复位 I2C 外设，释放总线，复位后再重新发起读操作。这个处理在工业现场特别重要，总线偶尔被干扰或者传感器瞬间无响应都是可能的，扛过去就是成功。我见过不少同行在软件里完全不处理 I2C 错误，一卡死就只能断电重启，这种系统交付到客户手里是很被动的。
5.5 快速排查速查表
| 现象 | 可能原因 | 排查/处理办法 |
|---|---|---|
| 读数恒定 0xFF/0x00 | 地址不对 / 接线错 / 芯片未供电 | 核对地址，量电压，示波器看时序 |
| 读数随机跳变 | 电源纹波 / 干扰 / 滤波不足 | 加去耦电容，检查供电回路，软件加滤波 |
| 远程读数异常 | 走线电容过大 / 上拉不合适 | 降速到 100kHz，上拉换 2.2k |
| 温度整体偏高 | 热源耦合 / 探头位置问题 | 远离发热元件，改善安装位置 |
| I2C 偶尔卡死 | 总线被干扰 / 时序冲突 | 软件超时复位 I2C 外设 |
| 串口上报乱码 | 波特率误差 / 接线不稳定 | 加外部晶振，降低波特率 |
5.6 一个少有人提但很管用的调试习惯
调试 I2C 温度传感器时，我强烈建议你找一个能直接读 I2C 的工具来验证，比如 USBTiny 之类的 I2C 调试器，或者直接用单片机的另一个空闲 I2C 外设做从机，把 PJ85718DM 的实时数据通过调试串口打出来对比。
很多问题，你光靠看代码很难看出毛病，但如果能实时看到波形、看到原始寄存器值，排查效率就完全不一样。我在本地调试时，永远保留一个调试串口，Print 功能默认打开。到现场的时候再关掉，否则串口数据太多反而干扰远程通信。
写在最后
这套 PJ85718DM 加 PIC18F87J50 的方案，从我最初搭原型到最后现场稳定运行，中间大概花了一个多星期。回头看，真正花时间的不是写代码，不是看数据手册，而是装探头、排干扰、反复验证安装位置对读数的影响。
在实际使用中我最大的体会是，温度监测这个行当，没有一劳永逸的方案。HVAC 现场更是如此，今天你解决了一个风管的测温问题，明天可能就碰到冷冻水管的温度测不准。但硬件底子打好、通信链路稳定、固件有足够容错能力，后面的问题大多是“装在哪、怎么装”这类现场工程问题，而不是“传感器为什么读不出来”这种基础功能问题。
最后再分享一个小技巧：在所有传感器节点的接线端子上，我都留了额外的备用线。上次现场维护，发现某个远程探头线缆被老鼠咬断了，因为预留了备用线，重新压了个端子就恢复了，全程不到十分钟。设计系统的时候，给自己留点冗余，出问题的时候你会感谢当初这个决定的。
