我做过很多和“温度采集 网络上报”相关的项目大部分都是设备已经装在现场需要把多点温度汇总到一个控制面板或者上位机上。这类需求单独看都不难真正麻烦的是很多人把“本地温度”和“远程温度”当成一回事结果要么在本地追求过高的实时性增加成本要么在远程传输上想得太简单把稳定性全赌在网络上。这次想分享一套比较典型的组合用 PJ85718DM 作为温度采集前端用 PIC18F87J60 作为主控和联网芯片把本地传感器数据和远传数据分开处理。适合正在做嵌入式、HVAC 或楼宇自控项目的朋友参考尤其是那种既要在本机面板上显示实时温度又要把数据传到监控中心的场景。下面从整个系统的功能拆分开始讲再逐步落到硬件接线、代码实现和现场踩坑。1. 这个方案要解决什么问题本地测温与远程测温根本不是一回事很多项目的需求文档里只会写一句话实时监测温度并上传。但“实时”这个词在不同位置有不同的含义。面板上看的温度需要秒级刷新出差错时操作员能立刻看到而监控中心看的温度可能允许十几秒甚至一分钟的延迟但数据不能丢、不能乱、不能漂。这两种场景如果混在一起设计往往两头都不讨好。1.1 本地温度实时性优先现场本地的温度监测对象通常是机柜内部温度、送风回风温度、管道表面温度这几个位置。这些温度有一个共同特点就是它们的变化通常不会特别剧烈布点位置却可能比较分散线拉得比较长。本地读数首先要保证的是刷新快、抗干扰。PJ85718DM 这类模块的好处是它把传感器、信号调理和数字化输出做在了一起主控只需要通过数字接口去读取不需要在前端额外做运放、滤波、线性化这些电路。软件采样周期可以做到几百毫秒一次面板上的显示就能接近“跟随温度实时走动”的效果。本地路径要关注的不是网络而是采样稳定性和电源干净程度。尤其 HVAC 现场里压缩机启动、变频器调速瞬间会产生很大的干扰如果传感器模块使用模拟电压输出ADC 很容易被拉偏。这也是我为什么更倾向于选数字接口版本。1.2 远程温度传输可靠性优先远程监测走的是网络通道这里要处理的问题从“怎么读准”变成了“怎么传稳”。温度数据本身量不大一个点也就两到四个字节真正影响体验的是连接管理、帧格式、超时重试和断线缓存。PIC18F87J60 在这条路径上的价值很明显芯片内部集成了以太网 MAC 和 PHY主控只需要外接网络变压器和 RJ45 座子就能在物理层上把所有数据包收发处理好。对于 8 位单片机来说这样的集成度意味着整体成本可以压得很低BOM 里少了很多外围芯片。远程温度数据不需要和本地完全同步更常见的是周期性上报、变化超过阈值时主动上报。这一点需要在设计一开始就定好因为控制器的工作模式完全不同。周期上报实现简单适合对实时性要求不高的场景变化上报省流量、省带宽适合节点数量多的系统但需要在协议里约定好心跳和超时判定。1.3 把两者放一块系统的分工就清晰了一旦把本地和远程拆开看待整个系统的结构就非常清晰。PJ85718DM 负责把物理温度变成数字量这是数据源头。PIC18F87J60 负责两件事一是以固定间隔读取这些数字量做滤波和显示二是把处理完的数据通过以太网封装成帧发送给上位机或服务器。本地的实时逻辑不放网络上远程的网络逻辑也不阻塞本地采样。这样做还有个额外好处后期如果传感器换成别的型号只需要改主控里对应的驱动部分如果上位机协议要改也只是改动网络封装层的代码。硬件板卡可以保持不变维护成本低很多。2. 传感器选型与接线PJ85718DM 是起点温度数据的质量决定了整个系统的质量。哪怕 PIC18F87J60 的处理和网络传输做得再稳传感器端读出来的值是错的后面全是白搭。所以这一部分值得多说几句。2.1 模块的定位与信号接口PJ85718DM 从命名习惯看是一个典型的一体化温度测量模块工作电压通常在直流低压范围输出端已经是调理过的数字信号和主控之间通过 I2C 或单总线这类协议通信。具体到某一批货的接口定义可能会略有差异但大多数这类模块都会把电源、地、数据线这几个引脚直接引出丝印上标注得很清楚。焊接和接线之前一定要先看丝印和厂商给的原理图确认引脚顺序尤其是电源正负搞反的问题。这类模块一般有防反接但也不是所有批次都有保护二极管接到损坏就麻烦了。模块内部的测温核心通常是半导体测温元件或热敏电阻经过 ADC 采样后再由内部算法换算成实际温度。用户拿到手的是已经在模块内部做过滤波和补偿的数字结果精度通常在正负 0.5 摄氏度级别已经完全满足 HVAC 监测的需求。如果你想追求正负 0.1 摄氏度的高精度那就需要选配更高等级的探头和校准流程但绝大多数场景真没必要。2.2 接线和电源接线遵循的基本原则是传感器电源单独走线别和继电器、电机驱动线捆在一起。HVAC 现场经常有 220V 动力线如果传感器线缆长时间和动力线平行走即使传感器模块本身做了滤波干扰也可能通过电荷耦合进信号线导致读数跳动。我常采用的做法是传感器线用双绞屏蔽线屏蔽层在控制板一端单点接地另一端悬空。单点接地可以避免形成地环路屏蔽层本身又能把空间耦合的电磁干扰导入大地这是成本最低、效果最好的抗干扰手段。电源方面需要注意压降。PJ85718DM 如果采用 5V 直流供电较长的现场布线会有明显的线路压降。模块的供电电压如果再往下掉内部 ADC 的参考电压可能不稳定会造成读数整体偏移。如果发现传感器离控制器超过二十米建议评估是否在传感器端配置独立的稳压电源或者考虑提升供电电压后再在模块端做二次稳压。2.3 现场读数的稳定措施传感器装好后测试阶段就要在白天的正常工况和晚上的低负荷工况分别读几组数据不要只在环境温度稳定的情况下测一次就结束。实测中经常遇到的问题是空调启动瞬间控制面板上的温度显示突然跳高或跳低几度。用示波器看信号线通常会看到明显的毛刺。简单有效的处理方法是两层一层是硬件上在靠近主控的数据引脚对地加一个 100nF 左右的小电容把高频噪声滤掉另一层是软件上做滑动平均或中值滤波。滑动平均适合缓慢变化的温度信号窗口大小我一般取五到十个采样点。中值滤波更适合抵抗脉冲干扰比如读取到异常跳变时直接丢弃。两者也可以结合先取中值去掉野值再做滑动平均进一步平滑。代价是响应变慢但 HVAC 的温度变化本身是分钟级别几秒钟的响应延迟完全能接受。3. PIC18F87J60 的初始化与温度采集PIC 系列单片机在工业控制领域用得非常广PIC18F87J60 这个型号最大的特点是内部直接集成了 10/100M 以太网控制器物理层和链路层都在芯片内部这是选型时的核心优势。3.1 内置以太网控制器省掉一整块外部芯片常见的单片机联网方案一般是 MCU 外接一块 ENC28J60 或 W5100 这类独立的以太网控制芯片。外接芯片当然可行但会增加 PCB 面积、焊接成本和调试工作量。PIC18F87J60 把以太网 MAC 和 PHY 集成在 MCU 内部MCU 和网络之间只隔一个隔离变压器和 RJ45 座硬件设计一下子简单很多。我实际测量过这类集成方案的稳定性。在正规设计的板卡上配合良好的网络变压器长时间运行 ping 的丢包率可以做到很低完全能支撑温度采集上传这类小包长连接业务。要注意的是网络变压器的选型不要贪便宜劣质变压器在高低温变化时电气参数会漂出现低温下网络偶尔掉线的怪问题。芯片初始化时有几个关键步骤配置时钟、配置以太网模块的 MAC 地址、设置 IP 参数、打开接收和发送缓冲区。MAC 地址可以用芯片的序列号拼接生成也可以直接用一组静态地址但要注意不要在同一个局域网里出现两块板卡 MAC 一样的情况否则交换机的 MAC 表会乱掉。3.2 读取 PJ85718DM 的流程温度模块的读取流程不复杂但有一个容易忽略的环节模块上电之后需要一小段稳定时间此时内部基准源和传感器都在建立工作状态立刻读取得到的数据可能偏大。所以初始化时建议延时几十到几百毫秒后再启动采样。以基本的 I2C 接口为例采样逻辑可以按这样的思路写// 伪代码接口地址和寄存器以模块手册为准 uint8_t temp_raw[2]; float temperature; void read_temperature(void) { if (i2c_start(DEV_ADDR_W) 0) { i2c_write(REG_TEMP_MSB); i2c_stop(); i2c_start(DEV_ADDR_R); temp_raw[0] i2c_read(1); // ACK temp_raw[1] i2c_read(0); // NACK i2c_stop(); temperature (temp_raw[0] 8 | temp_raw[1]) * RESOLUTION; } else { // I2C 无应答标记传感器异常 sensor_error 1; } }这段代码的关键在于每次读取前要做一次总线起始信号读取结束之后要发停止信号。I2C 总线上如果挂了多个设备地址冲突会导致全部设备无法正常访问现场调试时可以用扫描程序把所有应答地址打印出来确认一下。3.3 采集频率与软件滤波温度采集频率我通常设置为一秒一次这个频率对 HVAC 场景足够实用了。如果采样频率太高传感器模块和主控都处于连续工作状态反而没有必要如果太低面板显示的数值会有明显的台阶感。软件滤波直接决定显示效果。我试过三种方式取最近 N 次的平均值、去掉最大最小值后的均值、带权重的递推平均。对温度这种惯性大的信号来说普通均值就够了。温度如果出现突变比如从 20 摄氏度一下跳到 40 摄氏度先不要急着相信最好连续多读几次确认不是干扰造成的。真正的大型制冷机组跳停时温度也不会一秒钟跳二十度。滤波之后的数值可以同时用于本地显示和远程上报这样至少保证两边看到的数据是一致的不会出现面板和后台数值对不上的尴尬情况。4. 把温度送到远端HTTP 服务与自定义帧的两条路线远程数据通道是整个系统的最后一段。这里有两种常见的实现方式HTTP 适合人通过浏览器查看自定义帧适合系统与系统之间对接。两种方式可以共存但各自要处理的问题不太一样。4.1 HTTP JSON 适合人看的 Web 页面基于 PIC18F87J60 做一个简单的 HTTP 服务器占用资源不算大。芯片本身有内置以太网缓冲区再加上 TCP/IP 协议栈的裁剪完全可以支撑起一个轻量 Web 页面。最简单的做法是让设备监听 80 端口当浏览器访问时返回一段包含温度数据的 HTML 或 JSON。JSON 格式模型里比较干净上位机解析起来也方便代码逻辑上就是一个字符串拼接的过程void build_json_response(char *buf, float local_temp, float remote_temp) { sprintf(buf, HTTP/1.1 200 OK\r\n Content-Type: application/json\r\n Connection: close\r\n \r\n {\local\:%.2f,\remote\:%.2f}\r\n, local_temp, remote_temp); }HTTP 的好处是“所见即所得”用浏览器直接访问就能看到结果非常适合调试和验证网络链路通不通。但 HTTP 也有个问题如果上位机需要主动控制设备比如设置温度阈值基于 HTTP 的方式必须实现 POST 请求解析代码复杂度会上升一个台阶。纯监测场景用 HTTP 够用双向控制场景建议走自定义 TCP 帧。4.2 自定义 TCP 帧适合系统对接自定义帧没有标准协议的约束但正因如此怎么保证帧结构的完整性和可扩展性就成了设计重点。我常用的帧格式是帧头、长度、设备地址、功能码、数据区、校验字、帧尾。温度数据放在数据区固定偏移位置。// 帧结构示意 // 0xAA 0x55 | LEN | DEV_ID | FUNC | TEMP_H | TEMP_L | CRC16 | 0x0D 0x0A uint8_t frame[16];校验字我推荐用 CRC16虽然比校验和多两个字节但能检出更多错误类型现场环境干扰偶尔会在长线缆上制造很难发现的数据位翻转。上位机解析时一定要保留“长度异常就丢弃”的逻辑因为网络层重组出来的数据可能是半包或粘包不处理会直接把后续数据解错位置。链路层连接可以做成上位机主动连接设备的模式也可以做成设备主动上位机模式。我更倾向后者中的一种特殊形态设备维持短连接每隔一段时间上报一次数据后关闭下一次上报再从新建立连接。这种短连接方式对单片机内存的压力小也方便后期加多台设备。4.3 断线缓存与看门狗远程温度监控最怕的不是网络慢而是断线之后数据丢失。温度历史曲线中间缺一段对事后分析非常不利。在实际项目中我建议给 PIC18F87J60 加一块小的非易失存储区域用来缓存断网期间的采样数据。缓存区容量不用很大只保留最近几个小时的温度记录即可按一分钟一条算几 KB 存储够用了。网络恢复后设备把缓存的温度数据按时间顺序重新上报并在上报完成后清除对应记录。注意这里要处理好“当前时间”的同步问题。没有实时时钟芯片的话远程服务器收到的是设备本地累计时间做数据归档时会有偏差。最简单的方案是设备每次连接服务器成功后以服务器的校时报文更新时间戳基准。这样至少能保证缓存数据的相对顺序是准确的。主控本身必须有独立看门狗。以太网协议栈运行在 8 位单片机上如果某个 RAW 数据帧触发了协议栈里的异常分支可能存在死循环风险。看门狗能在程序卡死时让系统自动复位保证设备不会因为一个网络数据包就永久停工。5. HVAC 场景下的控制联动别只把读数传上去温度监测做到能看、能传只完成了数据采集的部分。HVAC 现场真正需要的是基于温度数据做出控制决策或者至少是提前预警。这里有一些和暖通强相关的策略值得单独梳理。5.1 本地控温和远程控温的分工本地控制逻辑要放在 PIC18F87J60 里不依赖上位机下发指令。这样即使远程链路断开现场设备也能按照预设策略运行不至于停摆。我在项目里通常把本地策略分成两档普通模式按本地设定值控温联网模式接收远程设定值覆盖本地值。远程断开后自动回退到本地设定值。这套逻辑用代码表达其实就是一个简单的优先级判断float target_temp; if (remote_link_ok remote_target ! 0) { target_temp remote_target; } else { target_temp local_target; }远程设置的目标温度只保存在 RAM 里本地默认温度则存在 EEPROM 中。每次冷启动时先读 EEPROM再用当前的远程值覆盖这样现场断电重启后也能快速回到可用状态。5.2 滞回区间的设置HVAC 控制不能设计成“温度一到设定值就立即动作”的硬开关逻辑否则压缩机和电加热器会被频繁启停设备寿命大幅缩短。标准的做法是设置滞回区间。比如要加热可以设定目标温度为 20 摄氏度允许上限为 20 摄氏度回差 2 摄氏度。实际逻辑是温度低于 20 摄氏度时开启加热加热到 22 摄氏度以上才停止中间区域不操作。这样压缩机或电加热器每次启停之间的间隔明显拉长整体使用寿命会好很多。滞回区间的大小需要根据被控对象的惯性和现场容忍范围来调整。惯性小的电加热可以取 1 摄氏度惯性大的风管系统取 3 到 5 摄氏度都正常。这个参数不建议写死在代码的宏定义里最好做成可以通过远程下发的寄存器项现场调试时有很大的便利。5.3 传感器失效时的保护策略温度传感器也是电子器件也会坏。HVAC 现场常见故障是传感器断线、短路、信号线进水导致读数异常。代码里要针对每一种异常做处理。传感器断线通常会让模块返回一个异常标志位或者返回一个远超过正常范围的数值。比如真实温度不可能低于 -40 摄氏度也不可能高于 150 摄氏度超出去就可以判定异常。此时控制系统不能继续按错误温度去控制阀门或加热器必须进入保护模式关闭执行器或输出报警。在多传感器系统中我还会做交叉判定。送风温度和回风温度不可能相差太离谱如果同一台设备上两个传感器读数相差过大说明其中一个已经漂移了需要上报“温度数据可疑”而不是直接上报数值。这个细节在现场维护时非常有价值能大大缩短排查时间。6. 我踩过的坑校准、网口和电磁干扰最后一部分直接写我在类似项目里遇到过的真问题。这些问题不一定每次都会出现但一旦出现就很隐蔽提前知道能省很多调试时间。6.1 温度不准先查这几件事温度显示不准时不要第一时间怀疑传感器模块坏掉。按照优先级排查先看模块供电电压是否稳定再看信号线是否和动力线走在一起最后才检查传感器探头安装位置。我遇到过很典型的一次某设备的温度读数始终比实际水温高两度左右检查半天模块和线缆都没问题后来发现探头安装在管道外壁保温层里贴着的其实是高温侧管壁而不是真正的水体温度。这类问题属于安装位置的系统性偏差单纯修传感器是永远修不好的。还有一个常见问题是电源纹波太大。某批板卡采样数值在小数点后一位不停跳动用示波器量模块电源端看到毛刺很明显加了一个低通滤波器后读数立刻稳定了。HVAC 现场电机的启停瞬态很容易把纹波引入电源轨传感器模块的电源入口处加电容和磁珠是非常有必要的。6.2 网口偶尔连不上的排查链路PIC18F87J60 的以太网在硬件设计上虽然简化了很多但调试时还是会遇到“偶尔能连上过一会又断”的情况。我的排查链路是固定的先看链路指示灯是否正常再断开网线直接测量变压器中心抽头的偏置电压然后换一根质量可靠的网线交叉测试。有一次现场反馈设备总是凌晨掉线白天正常。后来分析了设备间的距离、施工中的网络端子接线方式等因素最终锁定是布线经过了一段温度变化剧烈的区域接头处热胀冷缩导致接触不良。这是个很典型的现场问题排查时如果只看设备端会走很多弯路。如果确认硬件没问题再怀疑软件。检查网络协议栈的缓冲区分配是否够用尤其是发送缓冲区和接收缓冲区是否被大量广播包占满。控制网络规模或者在交换机上开启 VLAN 隔离这类问题都能规避。6.3 一些好用的调试工具调试阶段我习惯用一个串口打印调试信息把温度原始值、滤波值、帧收发状态全部打印出来。这样在出问题时能快速定位是传感器端的问题还是网络端的问题。字符串打印对时间敏感的代码有影响但调试阶段完全值得。网络侧我常用 tcpdump 或类似的抓包工具抓取设备与上位机之间的交互报文查看帧结构是否完整、重传是否过多。对于数据上报这种低速率业务只要能看到周期性报文正常发出链路稳定性基本就有保障。最后的经验是这类系统不需要追求多功能稳定才是第一位。把本地采样和远程上报分成两个独立的软件模块来开发分别测试、分别打包整个项目的调试效率会高很多。真出了问题时也能很快确定是哪一半的责任。