基于PIC18F87J10与PJ85718DM的本地远程温度监测系统设计

1. 从一颗温度传感器说起为什么本地与远程监测要分开做嵌入式温度监测这件事看起来简单真做起来坑不少。我最早接触温度采集是在一个环境控制类项目里当时想当然地认为一颗传感器测到底就行结果现场跑了两周就发现数据飘得厉害——靠近功率器件的测点比实际环境温度高了七八度而远端测点又因为线缆压降和噪声干扰读数跳变严重。后来才明白本地温度板载/近端和远程温度远端/异地在硬件选型、信号链路、软件滤波上根本就是两套逻辑硬凑在一起只会两头不讨好。这次要聊的方案核心是围绕PJ85718DM这颗远程温度传感器配合PIC18F87J10这颗8位单片机搭建一套能同时覆盖本地与远程测点的温度监测系统。标题里提到的 HVAC 应用其实就是暖通空调这类场景——它典型的特点是测点分散室内、风管、回水、室外、环境恶劣粉尘、电磁干扰、温差大、对可靠性要求高24小时连续跑。这类场景下你不可能把单片机放到每个测点旁边所以本地采集远程传输的架构几乎是必然选择。PIC18F87J10是这套方案的主控。它是 Microchip PIC18 系列里比较经典的一款128KB Flash、近4KB RAM自带多路10位ADC、多个UART/SPI/I2C接口工作电压2.0V~3.6V工业级温度范围-40°C到85°C。选它的理由很直接外设够用、功耗可控、开发工具链成熟而且8位机在这个场景下完全够用——温度监测本身不需要多强的算力稳定性和外设匹配度才是关键。PJ85718DM则负责远程测点这一端。它是一颗数字温度传感器通过串行接口输出温度数据适合放在离主控有一定距离的位置。这里要强调一个概念所谓远程并不是指几公里那么远在板级和机柜级应用里几十厘米到几米的距离就足以让模拟信号质量急剧下降所以用数字传感器把信号在测点就地数字化再通过数字总线传回来是更稳妥的做法。提示本地与远程的划分标准不是物理距离的绝对值而是信号是否需要经过长线传输。只要走线超过十几厘米就该考虑数字化传输方案。这套组合能解决什么问题简单说三件事第一本地测点用主控自带的ADC或板载传感器直接采成本低、响应快第二远程测点用 PJ85718DM 就地数字化抗干扰能力强第三主控统一做数据融合、滤波、上报形成完整的监测闭环。适合谁来参考做嵌入式环境监测、HVAC控制板、工业数据采集的开发者尤其是那些正在纠结传感器怎么选、线怎么走、数据怎么稳的人。2. PJ85718DM 与 PIC18F87J10 的搭配逻辑不是随便凑的2.1 为什么远程端选数字传感器而不是模拟传感器很多人第一反应是远程测点用热敏电阻或者模拟温度芯片拉两根线回主控的ADC不就行了理论上可行实际很痛苦。模拟信号在长线上传输会遭遇三类问题线阻导致的压降、电磁耦合引入的噪声、地电位差造成的共模干扰。这三点在 HVAC 场景里尤其明显因为风机、压缩机、继电器这些大功率负载就在旁边电磁环境相当糟糕。PJ85718DM 这类数字传感器的优势在于它在测点本地就把模拟量转成了数字量传输的是抗干扰能力强的数字信号。即使线缆上叠加了噪声只要电平判决没错数据就不会失真。而且数字接口通常带校验机制传输出错能被发现甚至纠正。从系统角度看这相当于把信号完整性的责任从长线缆转移到了传感器内部主控只需要处理干净的数字数据。这个思路在工业现场是标准做法只是很多初学者容易忽略。2.2 PIC18F87J10 的外设资源怎么分配才合理PIC18F87J10 的外设不算少但也不能浪费。在这套方案里我建议这样分配外设资源用途分配理由ADC 通道本地温度采集板载热敏电阻或模拟温度芯片直接接入UART/SPI远程传感器通信数字接口速率和距离匹配定时器采样周期控制固定间隔触发采集保证时序一致GPIO传感器使能/复位控制远程传感器电源或状态看门狗系统可靠性防止程序跑飞导致监测中断这里有个细节值得说采样周期不要设得太快。温度本身是慢变量环境温度变化通常以秒甚至分钟计采样间隔设到1秒已经足够。设太快只会增加功耗和数据处理负担还会让噪声更容易混进来。我一般建议本地和远程各设一个独立的定时器通道周期可以不同——本地快一点比如500ms远程慢一点比如2s因为远程通信本身有开销。2.3 供电与电平匹配的坑PIC18F87J10 的工作电压是2.0V~3.6V典型3.3V系统。PJ85718DM 的供电范围需要查具体手册但数字传感器常见的是2.7V~5.5V或者3.3V单电源。如果两者电压域不同接口电平就需要处理。我踩过的坑是传感器用5V供电主控用3.3V直接连I2C结果主控的引脚被传感器的上拉电阻拉到5V长期运行后引脚损伤。正确做法是加电平转换或者干脆让两者共用3.3V电源。如果传感器必须5V供电那就用专用的电平转换芯片别想着用电阻分压糊弄——I2C是双向开漏总线电阻分压会破坏时序。注意数字接口的电平匹配不是能通就行长期运行下的电气应力会慢慢损伤IO口这类问题往往在量产几个月后才暴露。3. 硬件链路搭建从传感器到主控的完整走线思路3.1 本地测点的电路设计本地测点相对简单因为距离近可以用主控的ADC直接采。常见方案有两种热敏电阻分压法或者板载数字温度芯片。热敏电阻分压法的电路是一个固定电阻和热敏电阻串联中间节点接ADC。NTC热敏电阻阻值随温度升高而降低分压点的电压随之变化。这个方案的优点是便宜缺点是线性度差需要查表或公式换算。我一般用Steinhart-Hart公式做换算精度能到0.1°C级别。板载数字芯片比如常见的I2C温度传感器则更省事直接读寄存器就行精度也有保证。缺点是成本略高而且需要占用I2C总线。如果本地测点只有一个用热敏电阻就够了如果有多个本地测点数字芯片反而更划算因为可以挂在同一条总线上。3.2 远程测点的线缆选择与布线规则远程测点这部分是重点。线缆选择上我建议用双绞线最好是带屏蔽层的。双绞的作用是让干扰在两根线上感应出共模信号而接收端是差分输入的话就能抵消掉。屏蔽层则要单端接地通常接在主控端不要两端都接否则会形成地环路。布线规则有几条是血的教训信号线远离动力线至少保持10cm以上间距交叉时尽量垂直交叉。线缆长度超过1米时通信速率要降下来。I2C在长线上很容易失败SPI相对好一些但也要注意。如果距离真的远超过3米考虑用RS-485这类差分总线做物理层或者用带长线驱动能力的传感器。传感器端加去耦电容通常0.1uF加10uF组合靠近传感器电源引脚放置。3.3 接地与屏蔽的实际处理接地这件事说起来简单做起来玄。我的经验是单点接地是基本原则。主控的地是参考地远程传感器的地通过线缆回到主控地不要在当地再接大地否则两个地之间如果有电位差就会在信号线上形成电流。屏蔽层的处理也类似屏蔽层只在主控端接地传感器端悬空。这样屏蔽层感应到的干扰会通过主控端泄放而不会在屏蔽层上形成环流。如果现场电磁环境特别恶劣还可以考虑在信号线上加共模扼流圈或者用隔离器把两端完全隔开。隔离方案成本高一些但在工业现场很常见尤其是传感器和主控不在同一个配电回路的时候。4. 固件实现采样、滤波与数据上报的完整流程4.1 初始化与自检流程上电之后固件的第一件事不是急着采样而是做自检。我通常按这个顺序来时钟配置确认系统时钟稳定PIC18F87J10 可以用内部振荡器也可以用外部晶振温度监测场景对时钟精度要求不高内部振荡器够用但要注意温漂。GPIO初始化把传感器使能脚、通信引脚配置好注意上电默认状态避免传感器在上电瞬间被误触发。通信接口初始化UART或SPI的波特率、数据位、校验位设置好先做一次回环测试确认接口正常。传感器探测尝试读取远程传感器的ID或状态寄存器确认它在线上且能响应。ADC校准如果本地用ADC做一次零点校准消除偏移。自检不通过怎么办我的做法是记录错误码点亮一个状态指示灯然后进入安全模式——继续尝试重连但不输出数据。这样现场人员能一眼看出问题而不是拿到一堆错误数据。4.2 本地温度采集与换算本地用热敏电阻的话ADC读回来的是原始码值需要换算成温度。以10位ADC、3.3V参考电压为例电压值 码值 × 3.3 / 1023。然后根据分压公式反推热敏电阻阻值再用 Steinhart-Hart 公式算温度。Steinhart-Hart 公式是1/T A B·ln(R) C·(ln(R))^3其中T是开尔文温度R是阻值A、B、C是系数由热敏电阻的规格决定。这个公式比简单的B值公式精度高但计算量大一些。在8位机上做浮点运算要小心PIC18F87J10 没有硬件浮点全靠软件模拟一次换算可能要几百个周期。如果采样周期是500ms这点开销可以接受如果要求更快就得考虑查表法或者定点运算。我一般会做一个折中先用B值公式快速估算如果温度在正常范围内就用估算值只有接近边界时才用Steinhart-Hart精算。这样既省算力又保证精度。4.3 远程传感器数据读取与校验PJ85718DM 的数据读取关键是时序和校验。数字传感器通常有固定的通信协议读命令、读数据、校验这几个步骤不能乱。我建议在固件里把通信封装成一个函数每次调用返回状态码和数据上层只管调用不用关心底层时序。校验方面如果传感器支持CRC一定要用。CRC能发现绝大多数传输错误比简单的和校验可靠得多。如果传感器只支持和校验那就在软件层再加一层连续读两次如果两次数据差异超过阈值就丢弃这次结果重新读。还有一个细节读取超时要设合理。超时太短正常通信也会被误判为失败超时太长传感器真挂了会拖慢整个系统。我的经验是设成正常通信时间的3到5倍比如正常读取需要2ms超时就设10ms。4.4 数据滤波滑动平均与中值滤波的组合原始数据一定有噪声滤波是必须的。常用的两种滤波滑动平均和中值滤波。滑动平均是把最近N次采样求平均能平滑随机噪声但对突变响应慢。中值滤波是把最近N次采样排序取中间值能去掉脉冲干扰但对缓变噪声效果一般。我的做法是组合使用先用中值滤波去掉明显的脉冲干扰再做滑动平均平滑剩余噪声。N的取值要看采样周期和实际噪声特性一般中值滤波取5点滑动平均取8到16点。这样既不会太滞后又能有效抑制噪声。提示滤波窗口不要设太大否则温度真实变化时响应会明显滞后。HVAC场景下温度变化本身不快但控制回路需要及时响应滞后太大会影响控制效果。5. 实测中遇到的典型问题与排查过程5.1 远程读数周期性跳变从现象到根因项目跑起来之后发现远程温度每隔一段时间就跳变一次跳变幅度大概2到3度然后自己恢复。这个现象很有规律大概每30秒一次。排查过程是这样的先怀疑是传感器本身的问题换了一颗新的现象依旧。然后怀疑是通信错误加了日志发现跳变时通信是成功的数据校验也通过。接着怀疑是电源干扰用示波器看传感器电源发现确实有周期性纹波频率和跳变周期一致。顺着电源纹波查下去发现是主控端的一个DC-DC转换器在轻载时进入了间歇工作模式纹波变大通过电源线耦合到了传感器。解决办法是在传感器端加了一级LC滤波同时调整DC-DC的负载让它工作在连续模式。问题解决。这个坑的教训是远程传感器的电源质量比本地更重要因为线缆会引入额外的阻抗和耦合路径。传感器端的去耦电容不能省必要时还要加电感做滤波。5.2 本地ADC读数漂移参考电压的隐藏问题本地温度读数慢慢漂移一天能漂一度多。一开始以为是热敏电阻的问题换了高精度的还是有漂移。后来用万用表直接测ADC参考电压发现参考电压本身就在漂。PIC18F87J10 的ADC参考电压可以选内部参考或者外部参考。内部参考受温度和供电影响较大外部参考如果用的是电源电压那电源波动就直接影响读数。解决办法是改用专用的参考电压芯片比如2.5V或3.0V的基准源温漂小、噪声低。换了之后漂移降到了0.1度以内。这个问题的隐蔽性在于你测的是温度但误差来源是电压参考跟温度传感器本身没关系。排查时容易在传感器上绕圈子实际上应该先确认整个信号链的基准是否稳定。5.3 通信偶发失败线缆与连接器的接触问题现场运行一段时间后偶尔出现通信失败重启就好但过几天又出现。这种偶发问题最难查。我的排查思路是先排除软件问题把通信失败时的错误码记录下来发现都是超时。然后检查硬件用万用表测线缆通断静态下都正常。后来把线缆拆下来仔细看发现连接器的一个压接点有轻微氧化接触电阻变大在温度变化时接触状态会变。换了连接器问题消失。这件事让我养成了一个习惯现场用的连接器一定要选带镀金触点的普通锡触点在高湿环境下容易氧化。另外线缆要有应力释放不要让连接器直接承受拉力。6. 让系统更稳的几个工程习惯6.1 采样数据的合理性检查不管滤波做得多好都要加一层合理性检查。温度不可能瞬间跳变如果两次采样之间变化超过某个阈值比如5度那这次数据大概率有问题应该丢弃或者标记。这个检查还能发现传感器故障。比如传感器短路读数会固定在某个极值传感器开路读数会跑到量程外。这些情况通过合理性检查都能识别出来然后触发报警或者切换到备用传感器。6.2 通信失败的重试与降级策略通信不可能100%成功关键是失败之后怎么办。我的策略是单次失败重试2到3次如果还失败就用上一次的有效数据顶替同时记录错误计数。如果连续失败超过阈值就判定传感器离线上报故障。这样做的目的是让系统在部分故障时还能继续运行而不是一有问题就整个停摆。HVAC场景下一个测点失效不应该导致整个系统停机降级运行比直接宕机好得多。6.3 长期运行的数据记录与趋势分析温度监测的价值不只在实时数据还在历史趋势。我一般会在系统里加一个简单的数据记录功能把温度数据按固定间隔存到EEPROM或者外部存储里。这样出问题时可以回溯也能做趋势分析比如发现某个测点温度慢慢升高可能是设备老化的早期信号。记录间隔不用太密5分钟或10分钟一次就够存一周的数据量也不大。关键是要有时间戳否则回溯时对不上时间。6.4 现场调试的实用技巧最后分享几个现场调试的小技巧带一个便携式温度计做参考现场比对读数比在办公室猜要快得多。通信线缆两端做好标记远程测点最容易接错。如果条件允许在传感器端加一个LED做状态指示调试时一眼就能看出传感器是否在工作。固件里留一个调试模式可以通过串口输出原始数据和中间变量现场排查时非常有用。这套 PJ85718DM 加 PIC18F87J10 的方案我在几个环境监测项目里都用过整体稳定性不错关键是硬件链路要做扎实固件的容错和滤波要到位。温度监测本身不复杂复杂的是让它在真实环境里长期可靠地跑下去。