★ FEATURED ARTICLE 搞温度监测的朋友应该都有体会本地测温容易难的是把温度数据可靠地送到远端远程通信能打通但现场安装环境复杂精度和稳定性又容易翻车。我最近基于PJ85718DM数字温度传感器和STM32F767ZG微控制器做了一套同时覆盖本地与远程温度监测的系统用在嵌入式设备舱和HVAC管道测点场景。这篇文章就把整个项目的设计思路、硬件连接、固件关键代码、调试数据和踩坑经验完整拆开讲适合正在做环境监控、设备温度采集或者暖通控制项目的开发者参考。1. 项目拆解与方案选型1.1 标题背后的真实需求“本地与远程温度监测”这句话看起来简单但拆开之后是两类完全不同的需求。本地监测指的是在设备现场直接读取温度、查看状态、触发告警。比如HVAC系统的送风管道、回水管道、机房空调出风口运维人员需要就地看到温度数值判断系统是否正常运行。嵌入式设备舱也一样控制柜里元器件发热、柜内环境温度变化都需要实时监控。本地侧的核心要求很直接读数准、响应快、能直观显示最好还能在超温时第一时间报警。远程监测则是把温度数据通过网络传到监控中心或者云平台供管理人员远程查看和记录。HVAC场景里一栋楼的空调机房可能分散在几十个楼层运维不可能每个机房都跑一遍远程汇总才是效率所在。嵌入式设备舱则在部署上更分散可能分布在户外、地下室、远端站点无人值守温度数据必须主动上报。远程侧的核心要求是链路稳定、数据传输可靠、断线能恢复、数据不丢。两条线叠在一起项目就变成了一个典型的边缘采集节点本地负责高精度采集和就地展示远程负责将数据安全送达。这需要单一MCU同时兼顾传感驱动、数据处理、本地交互和网络通信所以主控选型不能太弱。1.2 为什么是PJ85718DM加STM32F767ZG先说传感器选型。HVAC和嵌入式温度监测的测量对象温度跨度不大基本在-40℃到125℃范围内但对绝对精度有要求HVAC节能计算、能效评估都需要准确的温度差嵌入式设备则靠温度判断热保护策略误差大了可能误触发保护或者漏报警。我最早试过NTC热敏电阻方案优点是便宜、电路简单但NTC的B值一致性差需要逐点校准而且在-20℃以下和80℃以上线性度明显变差批量生产时每路都标定非常痛苦。也试过模拟输出的集成温度传感器但这需要MCU的ADC精度足够高还要做好基准电压的温漂补偿实际精度很难稳定做到±0.5℃以内。PJ85718DM是我后来换上的数字温度传感器内置高精度ADC通过I2C接口直接输出数字温度值测量精度标称±0.3℃分辨率0.01℃完全覆盖HVAC和嵌入式设备舱的精度需求。最关键的是它的上电时序和抗干扰能力做了加强——在工业现场电缆较长、电磁环境复杂的条件下读数依然稳定这比模拟方案省心太多。再说主控选型。STM32F767ZG是Cortex-M7内核主频216MHz带1MB Flash和512KB RAM这个性能做温度采集简直是杀鸡用牛刀但项目不只是采个温度——它还要跑本地显示、阈值告警、通信协议栈、断线重连和数据补发。M7内核跑起来非常从容以后想扩展更多测点或者加算法模型也不至于推倒重来。更重要的是外设配置。PJ85718DM走I2C接一片没问题但项目实际接了6路温度传感器分布在不同的管道和机柜位置I2C总线长度和地址数量都受限。好在STM32F767ZG给了3个I2C外设和4个SPI还可以扩展I2C多路复用器我把传感器分成两组挂在不同I2C总线上降低了总线负载地址冲突也好处理。远程通信方面这颗MCU原生带以太网MAC控制器配合外部PHY芯片即可跑100M以太网走MQTT或Modbus TCP都能轻松胜任。如果现场不方便拉网线它也有多个USART可以接4G模块或者LoRa模块。可以说从本地采集到远程上报一颗芯片全部搞定板子面积和BOM成本都控制在合理的范围。2. 硬件架构与关键模块设计2.1 系统总体架构整套系统按功能划分为三层采集层、控制层、远程层。采集层由6路PJ85718DM构成分布在HVAC管道测点和嵌入式机柜的关键发热部位。每路传感器用屏蔽双绞线引出线长最长约8米。控制层以STM32F767ZG作为核心负责定时轮询所有传感器、做温度校准、驱动LCD显示屏、判断超温阈值、通过RS485和以太网向外发送数据。远程层包括RS485总线上挂接的现场触摸屏以及以太网上连的MQTT服务器监控中心通过上位机软件实时查看所有测点温度和历史曲线。这个三层结构的好处是职责清晰传感器只管测MCU只管算和传远程平台只管看和存。哪怕远程网络瘫痪本地显示和报警照常工作不会因为网络故障而丧失监控能力。2.2 PJ85718DM的接口与接线设计PJ85718DM我使用的封装是SOT-23-6引脚不多电源、地、SCL、SDA外加一个地址选择引脚AD0和一根可选的报警输出引脚ALR。电源电压范围2.7V到5.5V我统一用3.3V供电和STM32F767ZG的IO电平直接兼容不需要电平转换。芯片在3.3V下的典型功耗只有几十微安即使6路传感器同时工作对系统总功耗的影响也微乎其微。地址配置AD0引脚拉低时I2C设备地址是0x48拉高时是0x49。所以一组I2C总线上最多可挂两个器件。项目有6路传感器我把它们分成三组用两个I2C外设接口各接3路传感器——每路总线上最多两个器件地址实际3路就需要处理。这里我做了个小设计I2C1总线上直接挂2路地址0x48和0x49剩下的4路通过两块I2C多路复用器接到I2C2总线上每个复用器通道再接1路。虽然结构复杂了一点但每条总线的负载都控制在合理范围信号质量有保障。接线时需要注意几点电源和地线尽量用双绞线SCL和SDA也要配地对减少磁场干扰。I2C上拉电阻我选了2.2kΩ在400kHz速率下8米线长的上升沿依然满足时序要求。每个传感器靠近电源引脚处加100nF去耦电容长线接入端并一个TVS管到地防止静电和浪涌打坏芯片。ALR报警输出引脚接回MCU的GPIO并加10kΩ上拉。这样传感器自身检测到超温时即使MCU正在忙于通信也能通过外部中断及时响应。2.3 STM32F767ZG核心板设计主控板我按最小系统加功能模块的思路来画时钟部分用25MHz无源晶振作为HSE配合内部PLL倍频到216MHz。STM32F767ZG的VDD和VDDA之间做常规磁珠隔离模拟电源单独供电保证ADC相关电路不受数字噪声影响。实际上温度数据是数字接口读进来的ADC只用于监测板载电源电压但隔离一下仍然值得——供电质量影响整个板的稳定性。调试接口留了标准的SWD四线再加UART1做日志输出。我习惯把调试日志和业务数据分开业务数据走RS485和以太网日志走独立串口出问题时用逻辑分析仪直接抓不会互相干扰。外设分配如下I2C1、I2C2分别连接直接传感器和多路复用器后的传感器通道。两路UART一路接RS485收发器跑Modbus RTU从站协议另一路备用后续可接4G模块。以太网SPI3接口连接外部PHY芯片跑LWIP协议栈走MQTT。一组GPIO控制继电器当任意测点温度超过设定阈值时继电器动作触发声光报警器。LCD屏采用SPI接口刷新率不需要太高重点是把6路温度和报警状态一目了然展示出来。PCB布局上的一个经验数字电路和传感器接线端子尽量分布在板子两侧避免高速信号和低速传感器线交叉。我的板子左边是电源和传感器输入右边是以太网口和RS485口中间是MCU实测下来传感器读数受到的干扰明显小于最初的紧凑布局版本。3. 固件开发与核心代码实现3.1 开发环境与工程搭建固件开发基于HAL库IDE用的是主流的ARM开发环境调试器配了ST-Link。工程结构上按模块划分bsp板级驱动、drv传感器驱动、app业务逻辑、net网络协议栈、sys系统配置。初始化顺序很重要我踩过一次坑一开始先初始化I2C再初始化以太网结果LWIP协议栈起不来查了半天发现是ETH的GPIO和I2C1的引脚有冲突。后来把所有外设引脚分配列成一张总表逐一比对确认没有复用冲突之后才解决了问题。这里也给个建议画板子之前先把全部功能模块的引脚分配表整理出来哪些引脚被哪个外设占用哪些引脚有默认功能必须清清楚楚否则后期软件阶段会非常痛苦。3.2 传感器驱动与温度转换PJ85718DM的寄存器结构是标准配置寄存器加2字节温度数据寄存器。初始化时先读ID寄存器确认设备在线然后配置分辨率、单次还是连续转换模式。HVAC场景中温度变化相对缓慢我采用单次转换模式每500ms轮询一次所有通道。这个周期对HVAC和机柜监测都足够了省电又降低总线占用。如果后续需要快速响应报警可以改成连续转换模式并启用ALR引脚的外部中断。核心读取逻辑float read_temperature(uint8_t bus_id, uint8_t dev_addr) { uint8_t reg 0x00; uint8_t data[2] {0}; i2c_start(bus_id, dev_addr, I2C_WRITE); i2c_write_byte(bus_id, reg); i2c_stop(bus_id); i2c_start(bus_id, dev_addr, I2C_READ); data[0] i2c_read_byte(bus_id, ACK); data[1] i2c_read_byte(bus_id, NACK); i2c_stop(bus_id); int16_t raw (data[0] 8) | data[1]; return raw * 0.01f; }这里要注意一个有符号数处理的坑PJ85718DM的高字节是符号位温度值在零下时raw是一个负数。如果把高字节直接左移8位赋给int16_t编译器会做正确的符号扩展但我第一次用的是uint16_t临时变量导致零下温度全部变成65535附近的大正数校准了半天才反应过来。温度转换务必将原始数据强制转换为int16_t再做乘法。3.3 温度校准与数据处理即使传感器标称精度很高批量安装和长线传输仍然会引入细微偏差。除了传感器自身误差还有线缆电阻、连接器接触电阻、PCB走线差异等。所以我做了两级校准。第一级是单点偏移校准在0℃冰水混合物中让传感器稳定15分钟后读取实际输出计算偏移量并保存到Flash。第二级是两点增益校准再取一个50℃的恒温源计算出增益系数。最终温度计算float calibrated_temp(float raw_temp) { return (raw_temp - offset) * gain; }对于HVAC这种测量范围集中在-10℃到60℃的场景两点校准完全够用。实测下来校准后整条链路的误差可以控制在±0.15℃以内。不要迷信传感器标称精度系统级的误差是累加的增益校准能显著提升多通道之间的一致性。数据处理上还加了滑动平均滤波。窗口取了8次采样对应4秒的时间常数既能抑制瞬间干扰又不会让报警响应太迟钝。滤波代码很轻量#define FILTER_WINDOW 8 float filter_push(float window[], uint8_t *idx, float new_val) { window[(*idx)] new_val; if (*idx FILTER_WINDOW) *idx 0; float sum 0; for (uint8_t i 0; i FILTER_WINDOW; i) { sum window[i]; } return sum / FILTER_WINDOW; }这里我故意没有做剔除异常值的处理因为PJ85718DM本身稳定性很好偶尔出现的异常值会被滑动平均平滑掉如果再加中值剔除反而会让真实温度变化被过渡平滑影响报警响应速度。3.4 本地显示与超温告警LCD屏显示6个通道的实时温度、通道名称、报警状态。刷新频率设计为1秒因为半秒轮询一次数据1秒刷新显示不会感觉到卡顿也避免了SPI刷屏占用MCU太多时间。告警逻辑分两级预警和报警。预警阈值默认设50℃报警阈值设60℃均可在上位机远程修改也可以在现场通过按键调整。两级告警的好处是可以提前发现温度爬升趋势给运维留出响应时间。告警处理有个细节单个通道超温后程序只发一次报警事件带上通道号和温度值而不是一直重复发同一状态。避免网络被重复报警消息刷爆也让监控端能清楚区分新事件和重复状态。3.5 远程上报实现远程通信我做了两套链路并行的方案第一套是Modbus RTU从站协议通过RS485接到现场触摸屏和本地监控终端。STM32F767ZG作为从站地址设为1功能码支持读保持寄存器。6路温度打包成12个模拟量寄存器监控终端直接轮询读取。这套方案适合已有现场总线的工业环境不依赖IP网络非常可靠。第二套是以太网MQTT链路STM32F767ZG作为客户端连接MQTT服务器以固定Topic上报数据payload用轻量的JSON格式如{device:AHU-01,points:[{ch:1,t:23.45},{ch:2,t:24.12}]}MQTT链路做了两个关键处理。一个是心跳保活每30秒发心跳包60秒没收到服务器响应就判定链路异常主动重连。另一个是数据补发本地搞了一个环形缓冲区容量为3000条记录当网络断线超过5分钟时历史数据会按时间戳批量补发到服务器保证远程记录不出现长时间缺口。协议栈方面直接集成了现成的LWIP和MQTT客户端库把TCP连接管理、重连策略、JSON打包等工作交给上层应用底层协议栈是成熟代码稳定性反而更好。4. 系统调试与实测数据4.1 硬件调试步骤拿到第一批打样的板子我没有直接上全套外设而是按“电源-核心-传感器-通信”的顺序逐步调试。先焊电源部分用万用表确认3.3V、2.5V等各路电压正常量一下静态电流没有异常。然后只焊STM32F767ZG最小系统用SWD连接调试器写一个最简单的LED闪烁程序确认时钟、Flash、启动流程正常。第三步才接入传感器。用一个通道测试把PJ85718DM焊到转接板上用杜邦线连到开发板的I2C1接口。先不装6路只验证单路通信时序用逻辑分析仪抓I2C波形确认通信正常、数据寄存器读取值符合预期。确认单路正常后再焊接全部6路传感器和通信模块。此时如果出现问题就能快速定位是硬件还是软件的问题避免一上来就一大摊子东西分不清责任。4.2 温度测量精度对比为了验证系统的实际精度我用标准的工业水银温度计做参照同时在恒温箱里做了3组温度点对比测试。恒温箱设定值分别为0℃、25℃、50℃稳定30分钟后记录系统读数。在0℃点6路通道的实测偏差在-0.08℃到0.12℃之间在校准前这个偏差范围是-0.21℃到0.18℃。在25℃点偏差在-0.06℃到0.09℃表现最好。在50℃点偏差在-0.12℃到0.14℃相比低温度段略大这与传感器在高温段线性度微变有关但仍在±0.3℃标称范围内。6路通道之间的最大温差也就是不同通道之间的读数差校准后控制在0.15℃以内。这对HVAC的温差测量非常关键——很多时候用户其实不关心绝对温度到底是多少而是关心温差。比如换热器两侧温差、送风回风温差如果两个通道的系统偏差不一致温差数值就不可信了。双点校准把通道间的一致性做上来了这是整个项目交付时用户最满意的一点。4.3 远程通信稳定性测试远程链路在真实的HVAC机房环境里测试了48小时。机房内有变频器、电机、继电器等干扰源以太网线和RS485线都走现场原有线槽。Modbus RTU链路表现很稳定48小时内触摸屏轮询读取10,000多次没有出现一次通信超时。RS485走的是屏蔽双绞线屏蔽层单端接地终端电阻按标准并接在总线的物理末端这些细节做到位之后现场干扰基本不影响通信。MQTT链路48小时内断线重连了3次每次都在5秒内恢复原因是现场网络有短暂的设备重启。断线期间产生的数据都从本地缓冲区补发了服务器侧记录的时间序列连续无缺口。数据上报的延时平均在200ms以内对于温度这类缓变量这个延迟完全不是问题。5. 踩坑记录与排查手册5.1 温度读数异常跳变现象某天现场反馈3号测点偶尔出现温度从25℃直接跳到80℃再跳回来。排查过程用逻辑分析仪抓I2C波形发现跳变前总线上出现了一个不完整的波形——SCL只有6个时钟周期SDA却在第3个时钟就变了电平。初步判断是干扰导致的通信错位。进一步检查发现3号传感器所在的线缆经过一段靠近强电电缆的线槽虽然用了屏蔽双绞线但屏蔽层在现场被剪断没有接地。这件事暴露了安装规范的重要性屏蔽层必须单端接地且接地端在现场控制柜侧。解决措施把屏蔽层重新接地同时I2C频率从400kHz降到100kHz并将SCL和SDA各加了一个33pF的滤波电容把信号边沿变缓一些以增强抗干扰能力。之后连续测试一周没有再出现跳变。5.2 上电后部分传感器I2C通信失败现象板子断电重开后偶尔有一两个传感器无法应答。排查过程一开始怀疑是传感器损坏换新后同样出现。后来发现每次失败的都是挂在I2C多路复用器后面的通道复用器的使能时间不够长MCU按键之后立即发起I2C通信通道还没来得及打开。解决措施在切换复用器通道后加入5ms延时再启动I2C传输。同时在软件初始化流程里增加了全通道的在线检测发现无应答的通道会单独重试3次。这个问题本质是时序竞争硬件没问题但在固件里被忽略了。5.3 远程MQTT频繁掉线现象部署到现场后MQTT连接每隔几分钟就断开。排查过程抓包看到服务器发送了心跳超时断开。原来我把WiFi模块和以太网PHY放在了同一个供电支路上WiFi发射瞬间拉低了以太网PHY的电源电压导致PHY芯片偶发复位。解决措施给以太网PHY供电路径增加独立的LC滤波WiFi模块改用单独的电源轨两者在物理布局上也拉开了距离。调整后连续运行72小时掉线次数降为0。5.4 HVAC场景中的冷凝水问题现象在空调冷水管道的测点传感器外壳出现凝露温度读数在凝露后开始缓慢漂移。排查过程不是因为电气问题而是外壳密封失效。水汽渗入传感器封装后改变了散热路径导致测温偏差。解决措施换用带IP67防护等级的传感器探头安装时探头朝上线缆走线形成“滴水弯”冷凝水沿线的方向滴落而不进入探头。这件事提醒我HVAC环境里防水防潮和防雷防干扰一样重要。6. 经验扩展与后续优化思路这块硬件的性能其实还有不少富余我已经在考虑两个方向的扩展。一个是增加测点类型。现在6路传感器都是湿度温度一体方案中的温度部分后续可以在同一套主控下接入管道压力、流量的变送器通过RS485或者模拟量输入把更多过程参数汇聚到同一个节点形成真正的多功能现场采集站。另一个是边缘计算。STM32F767ZG的M7内核性能足够跑轻量级的异常预测算法比如基于温度变化率来判断风机轴承是否开始磨损或者根据温差趋势预测过滤器堵塞时间。这样远程平台收到的就不只是原始数据还有设备健康状态对HVAC的预测性维护会更有价值。能耗方面也可以优化。当前板子一直保持全速运行实际上在工作模式之间加一个轻量级的低功耗调度让MCU在两次轮询之间进入Sleep模式整机功耗可以降到目前的30%以下。对于使用太阳能供电的嵌入式设备舱节点这个优化会非常实用。最后再分享一个体会温度监测项目看着简单但真正交付时用户最在意的不是你能采集多少数据而是数据可不可信、链路稳不稳、维护易不易。把精度校准、抗干扰、断线补发这些“看不见的细节”做扎实系统才真正可用。这套方案目前已经在两个现场稳定运行了几个月验证了从本地到远程的完整闭环后续我也会持续把新的调试经验补充进来。
阅读完成 · 觉得有帮助？
