1. HVAC 场景下“本地远程”温度监测的真实需求拆解做嵌入式温度监测的人多半都有过这种经历本地调试时数据漂漂亮亮一接到现场就发现远端平台上的温度曲线和机柜里实测值对不上要么滞后要么跳变严重的时候还会触发误报警。我早期做的一个机房空调控制器项目就栽过这个跟头后来才把方案改成“本地闭环控制 远程状态上报”双通道也就是标题里这套 PJ85718DM 配合 STM32F723IE 的思路。先别急着看芯片得把需求拆明白。HVAC 领域里的“本地温度”和“远程温度”本质上不是同一个东西。本地温度服务于控制回路要求实时、准确、低延迟主控拿到读数之后要做 PID 调节、压缩机启停、风阀开度计算。远程温度服务于运维监控要求稳定、可追溯、能告警哪怕比本地慢一两分钟问题都不大但数据不能丢还要能还原出历史趋势。很多人图省事直接把本地温度通过通信口转发给后台结果两边互相拖累本地控制因为通信阻塞被延迟远程数据又因为轮询间隔太短而频繁断流。这个问题在 HVAC 项目里尤其突出因为现场往往有变频器、接触器、电动阀这些强干扰源通信链路稍不稳定整个系统就跟着抖。所以我在项目里通常把本地和远程分开设计但共用同一个物理传感器和数据源只是处理路径不同。本地路径走中断或高频轮询远程路径走低优先级队列上报。这样既能保证控制实时性又能让远程数据完整可信。标题里提到的 PJ85718DM 和 STM32F723IE就是分别承担“温度采集”和“主控与联网”这两个角色的。1.1 本地测温与控制回路的耦合关系本地温度必须和控制器形成闭环这意味着采样周期要稳定不能因为任务调度或远程通信而抖动。比如一个空调风柜的回风温度采样如果 500ms 采一次PID 输出周期是 1s那采样抖动就不允许超过几十毫秒否则控制量会跟着抖动。用 STM32F723IE 这种主频足够高的平台PJ85718DM 的读取完全可以用定时器触发在定时中断里完成小段状态机避免被 RTOS 任务抢占。1.2 远程监测的“不可靠”是常态远程温度要穿过网关、路由器、云平台任何一环出问题数据就会断。所以远程链路必须接受“断线是常态”这个前提设计上要有缓存、重传、超时处理。我不会指望远程读取和本地读取用同一个线程而是把远程上报做成独立任务数据从采集队列里取取完就更新本地缓存网络恢复后再把缓存补传。2. 方案选型PJ85718DM 做前端STM32F723IE 做主控的原因温度传感器型号非常多常见的热敏电阻、热电偶、数字温度芯片各有各的坑。PJ85718DM 这颗器件在国内工控市场不算是烂大街的型号但它有几个特点非常适合 HVAC 类应用数字输出、可多点挂接、抗干扰能力不错。我手头这颗的实测分辨率能做到 0.0625°C 级别测温范围覆盖 -40°C 到 125°C对于风道、盘管、回风、室外温度这些典型场景都够用。选择 STM32F723IE 的原因更实际。首先是外设丰富它自带以太网 MAC配合外部 PHY 就能直接上 TCP/IPUSB 高速 OTG 可以用来做本地维护口多个 UART、SPI、I2C 口足够挂传感器和扩展板。其次是处理能力Cortex-M7 内核跑 216MHz做温度滤波和 PID 计算绰绰有余未来想加谐波分析或者预测算法也有余量。最后是封装和供货LQFP 封装方便手工焊接和 layout这颗型号在工业级温度范围内工作稳定。2.1 温度传感前端的关键选型逻辑我见过很多项目在传感器选型上只看精度忽略了三件事供电范围、输出接口、长期稳定性。PJ85718DM 支持 3.0V 到 5.5V 供电这样在 HVAC 控制板上可以直接用 3.3V 或 5V 电源不用额外做电平转换。输出接口是类单总线协议和常见的 DS18B20 类似但时序参数有区别代码不能用现成的库必须对着数据手册调时序。这一点我在第 3 节会展开。还有一个选型细节是封装。风道里传感器经常要延长线引出如果选用贴片封装的温度芯片探针焊接和防水处理会很麻烦。PJ85718DM 这类器件如果是 TO-92 或小型插件封装配合金属套管就能做成防水探头现场部署方便得多。2.2 STM32F723IE 在这个方案里到底干了什么从系统分工上看STM32F723IE 至少要跑四块任务温度采集调度、本地控制逻辑、远程通信协议、故障诊断。F723 的双核严格讲它还是单核 M7但配合 DMA 和中断优先级设计完全可以把实时采集和通信任务解耦。采集任务用定时器中断触发优先级最高本地控制用 1ms 或者 10ms 周期任务远程通信用低优先级任务专门跑 TCP 客户端。选型时我特别看重以太网 MAC。很多工业项目要求设备能直接接入现场局域网不需要单独配 DTU 或网关。F723 内置 MAC我外接一颗工业级 PHY 芯片比如常见的百兆 PHY就能省掉一颗 MCU。这个集成度让 BOM 成本可控也让故障诊断时少了一个环节。2.3 为什么不是随便拿个开发板就上原型验证阶段随便用开发板没问题但真正进 HVAC 产品有两个槛电磁兼容和温度范围。现场有继电器通断、变频器启动瞬间浪涌和辐射干扰很凶。普通开发板的电源滤波和地平面设计未必扛得住。我在这套方案里自己画了一块四层板传感器接口处加 TVS 管和共模电感电源入口加 π 型滤波实测辐射骚扰和 EFT 项目都能过。3. 本地温度链路的硬件与软件实现从接线到校准这一节讲的是最容易被低估的部分。很多人以为传感器读取就是“初始化、读寄存器、得温度”三步但 HVAC 现场温度读数不准、跳变、漂移绝大多数问题出在硬件布局和驱动时序上。3.1 传感器接线、去耦与延长线处理本地传感器如果直接焊在主板上接线比较简单。但 HVAC 项目里传感器经常要在风道内、盘管后、室外机附近延长线少则半米多则三米。PJ85718DM 的单总线协议对线缆电容敏感线太长、材质太差会出现读时序失败或者数据位错乱。我的经验是延长线使用双绞屏蔽线屏蔽层单端接地接到传感器侧的电源地去传感器电源脚对地并一个 0.1μF 陶瓷电容靠近器件引脚放置数据线上拉电阻取值要按线长调整1 米以内用 4.7kΩ3 米左右用 2.2kΩ太长就得上有源上拉或者改用 I2C/SPI 接口的传感器。现场实测中这个处理能让误码率下降一个数量级。另外要注意电源纹波。温度采集器件对电源噪声不是特别敏感但单总线读时序的高电平阈值是固定的如果 VCC 被继电器拉低到阈值以下读取就会间歇性失败。我在这套方案里把传感器供电单独用一个 LDO不从 24V 开关电源直接取就是为了隔离噪声。3.2 驱动代码里的关键时序与转换时间PJ85718DM 的驱动不能直接用常见单总线库原因是它的复位时序和 ROM 命令格式有差异。我在项目中是先看数据手册的时序图用逻辑分析仪抓波形确认再写驱动。核心流程是拉低总线一段时间产生复位脉冲释放总线等器件应答然后发送跳过 ROM 命令、启动温度转换命令等待转换完成后再读取温度寄存器。转换时间这个参数要特别留意。有的器件转换时间长达 750ms如果用默认超时去读会读到上一次的数据。我在代码里用定时器状态机启动转换后立刻返回等时间到了再由定时器回调触发读取。这样既不会阻塞主循环又能保证每次读到的都是新数据。/* 伪代码示例定时驱动的温度采集状态机 */ typedef enum { TEMP_IDLE, TEMP_START_CONV, TEMP_WAIT_CONV, TEMP_READ, TEMP_ERROR } temp_state_t; void temp_timer_isr(void) { switch (temp_state) { case TEMP_IDLE: temp_state TEMP_START_CONV; break; case TEMP_START_CONV: temp_start_convert(); temp_state TEMP_WAIT_CONV; break; case TEMP_WAIT_CONV: if (temp_convert_done()) { temp_state TEMP_READ; } break; case TEMP_READ: temp_read_value(temp_raw); temp_filter(temp_raw, temp_value); temp_state TEMP_IDLE; break; default: temp_state TEMP_IDLE; break; } }3.3 两点校准和软件滤波温度芯片出厂时有一致性误差但同一批次误差通常有固定偏移。我在产线校准里做两点校准一个用冰水混合物作为 0°C 参考一个用恒温槽或者精确电阻箱配合标准温度计做 50°C 参考测出每个传感器的偏移和增益误差写入 MCU 的 Flash 校准区。软件滤波我用的是中值加一阶低通两步走。先取最近 5 次原始值排序取中值滤掉毛刺再做一阶惯性滤波滤波系数根据采样周期调整。比如采样周期 500ms滤波系数取 0.2时间常数大约 2s既能平滑风机启停造成的微小波动又不会掩盖真实的温度趋势。4. 远程温度上报的工程化协议、缓存与断线恢复远程温度看起来只是“把本地温度打包发出去”但实际工程化以后协议设计、缓存策略、断线恢复这些环节才是真正花时间的地方。这里我分享一套在多个项目里复用过的做法。4.1 远程通道的选型取舍HVAC 设备常见的远程通道有三种以太网直连、串口转 4G DTU、私有无线。以太网直连适合有局域网或者能接入云平台的场景F723 自带 MAC 的优势就在这里串口转 DTU 适合现场没有网口的改造项目只需要走 UART 透传私有无线适合多设备组网但要自己考虑频点和协议栈。我在项目里首选以太网原因很简单数据量大、实时性好、调试方便。F723 跑 lwIP 协议栈TCP 客户端连接云端服务器默认每 10 秒上报一次温度数据。如果设备数量多再考虑改成 MQTT 协议F723 的资源跑 MQTT-SN 没问题资源和流量都比裸 TCP 友好。4.2 报文格式设计温度只是其中一部分远程报文不能只发温度值还必须带设备地址、通道号、时间戳、状态标志和校验。时间戳是很多人容易漏的尤其断网后补传数据时没有时间戳会让数据失去意义。我在报文里用 UNIX 时间戳由 MCU 的 RTC 提供并对时服务器或现场维护软件校时。| 帧头 0xAA55 | 设备ID 2B | 通道号 1B | 温度值 4B(int32, 0.001°C) | 状态字 2B | 时间戳 4B | CRC16 2B |温度值用有符号 32 位整数表示单位是 0.001°C。比如 23.456°C 表示为 23456。状态字里包含传感器通信错误、传感器短路/断路、本地控制状态等标志。CRC 校验必须加现场电磁环境里偶尔出现一个字节翻转没有校验平台就会记录一条假数据。4.3 断线重传与本地缓存策略远程链路断线后如果数据直接丢弃运维人员会发现温度曲线少了一段。我的做法是在 MCU 外部挂一颗 SPI NOR Flash按环形队列存储尚未成功上报的数据包。每包 32 字节一颗 8MB Flash 可以缓存 26 万条以上足够应对几天的断网场景。上报任务每成功收到服务器 ACK就清除对应缓存记录如果超时未 ACK保留并等待下轮重传。为了防止堆积还要设置缓存上限超过阈值就丢弃最旧的数据保证最新数据优先。这个策略很简单但很有效。很多开源项目只做“发出去就不管”一断网数据就空白到了复盘故障的时候完全无从查起。5. HVAC 场景特有的适配细节不是普通的数据采集器温度监测放进 HVAC 系统后很多细节会跳出来探头放哪里、告警怎么设、传感器电源能不能在被强干扰的环境里稳定工作。这些都需要按应用场景做适配不能照搬实验室做法。5.1 探头位置对读数的决定性影响同样是测量回风温度放在风道壁边和放在风道中心读数能差 2°C 以上。空气流动有边界层效应贴近壁面的空气流速低温度更容易受风道壁热传导影响。正确做法是让探头伸入风道中心位置并用支架固定避免贴在金属壁上。盘管出水温度、冷凝器进风温度、压缩机壳温这些不同测点的响应速度和绝对精度要求也不同。我习惯给每个传感器通道单独配置滤波系数和告警阈值而不是用一个全局参数套所有通道。比如风道温度滤波系数取小快速响应风机变化壳温滤波系数取大平滑短时波动。5.2 告警逻辑阈值 变化率组合判断单纯设一个温度上下限在 HVAC 现场很容易误报。比如除霜过程温度会突然升高如果只看阈值就会误告警。我的做法是双条件判断超阈值 变化率持续超过设定值。例如回风温度超过 35°C 且每分钟上升超过 5°C才判定为故障。这套逻辑在 STM32F723IE 上实现很轻松一段状态机就行。5.3 供电与 EMC 噪音的常见坑HVAC 控制柜里 24V 电源常常和大功率负载共用负载一启动传感器供电就会被拉低。针对 PJ85718DM 这类器件我在布局上做了三点改进一是传感器供电入口加磁珠二是传感器电源对地加大容量电解电容三是单总线数据线串 100Ω 电阻降低干扰耦合。现场整改后跳变次数从每几分钟一次降到几乎为零。现象可能原因处理办法温度读数周期性跳变电源被继电器拉低单独 LDO 供电加大电容读时序偶尔失败延长线太长且未用屏蔽线换双绞屏蔽线调上拉电阻远程数据乱码报文无 CRC 或波特率偏差加 CRC16校准波特率本地读数正常但远程偏差大远程采样与本地采样用了不同通道统一数据源共享采集队列6. 实测复盘一次温度跳变故障的完整排查过程最后分享一个我在现场真实遇到的排查过程算是把前面几节的坑串起来。这个案例发生在某商用楼宇的空调机组改造项目里设备是某设备厂商的嵌入式控制器主控就是 STM32F723IE温度采集用的 PJ85718DM。6.1 症状本地读数稳定远程平台出现周期性毛刺项目调试初期现场控制面板显示的送风温度始终稳定在 21.5°C 左右但远程平台每 2 分钟出现一次 35°C 的尖峰。第一次看到这个现象我以为是温度传感器故障于是带着逻辑分析仪去现场排查。6.2 排查链路先查通信再查供电最后查地线我先抓了远程报文的原始数据发现尖峰对应的温度值不是随机乱码而是某个固定值这和传感器偶发错误数据不符。接着用逻辑分析仪抓传感器总线波形发现触发尖峰的那轮读取根本没有应答信号代码走了错误处理分支把上次缓存里的一个异常初值发了出去。问题定位到单总线通信失败后我开始检查供电和地线。用示波器测传感器 VCC发现在空调压缩机变频启动瞬间电压会跌落近 1V刚好低于器件工作电压下限。进一步追查原因发现传感器电源直接从主控板 3.3V 输出取电而主控板 3.3V 同时给几个继电器驱动电路供电继电器一动作3.3V 就被瞬时拉低。6.3 根因与修复电源去耦 驱动容错双管齐下修复措施有两步硬件上把传感器供电改成独立 LDO输出端并 10μF 电解电容和 0.1μF 陶瓷电容软件上给读取函数增加连续三次失败判定失败次数超过阈值才报错单次失败只丢弃数据包。改完后再观察两周远程平台没有再出现毛刺。这个案例给我最大的教训是温度监测系统的可靠性百分之八十取决于电源设计和通信容错而不是传感器的“精度指标”。很多工程师拿到板子先调精度其实先把供电做好、协议做稳后面能省掉大量现场时间。另外提一个维护小建议远程平台侧一定要保留原始报文日志。现场排查时能看到完整日志往往比看温度曲线有用得多。我在这个项目里就是在日志里发现尖峰是固定值才顺着这条线很快定位到传感器总线的通信异常而不是在传感器本身瞎猜。 
长河君 · 2026/10/22 12:19:18 · 阅读 1.2k 基于PJ85718DM与STM32F723IE的HVAC本地+远程温度监测方案
1. HVAC 场景下“本地远程”温度监测的真实需求拆解做嵌入式温度监测的人多半都有过这种经历本地调试时数据漂漂亮亮一接到现场就发现远端平台上的温度曲线和机柜里实测值对不上要么滞后要么跳变严重的时候还会触发误报警。我早期做的一个机房空调控制器项目就栽过这个跟头后来才把方案改成“本地闭环控制 远程状态上报”双通道也就是标题里这套 PJ85718DM 配合 STM32F723IE 的思路。先别急着看芯片得把需求拆明白。HVAC 领域里的“本地温度”和“远程温度”本质上不是同一个东西。本地温度服务于控制回路要求实时、准确、低延迟主控拿到读数之后要做 PID 调节、压缩机启停、风阀开度计算。远程温度服务于运维监控要求稳定、可追溯、能告警哪怕比本地慢一两分钟问题都不大但数据不能丢还要能还原出历史趋势。很多人图省事直接把本地温度通过通信口转发给后台结果两边互相拖累本地控制因为通信阻塞被延迟远程数据又因为轮询间隔太短而频繁断流。这个问题在 HVAC 项目里尤其突出因为现场往往有变频器、接触器、电动阀这些强干扰源通信链路稍不稳定整个系统就跟着抖。所以我在项目里通常把本地和远程分开设计但共用同一个物理传感器和数据源只是处理路径不同。本地路径走中断或高频轮询远程路径走低优先级队列上报。这样既能保证控制实时性又能让远程数据完整可信。标题里提到的 PJ85718DM 和 STM32F723IE就是分别承担“温度采集”和“主控与联网”这两个角色的。1.1 本地测温与控制回路的耦合关系本地温度必须和控制器形成闭环这意味着采样周期要稳定不能因为任务调度或远程通信而抖动。比如一个空调风柜的回风温度采样如果 500ms 采一次PID 输出周期是 1s那采样抖动就不允许超过几十毫秒否则控制量会跟着抖动。用 STM32F723IE 这种主频足够高的平台PJ85718DM 的读取完全可以用定时器触发在定时中断里完成小段状态机避免被 RTOS 任务抢占。1.2 远程监测的“不可靠”是常态远程温度要穿过网关、路由器、云平台任何一环出问题数据就会断。所以远程链路必须接受“断线是常态”这个前提设计上要有缓存、重传、超时处理。我不会指望远程读取和本地读取用同一个线程而是把远程上报做成独立任务数据从采集队列里取取完就更新本地缓存网络恢复后再把缓存补传。2. 方案选型PJ85718DM 做前端STM32F723IE 做主控的原因温度传感器型号非常多常见的热敏电阻、热电偶、数字温度芯片各有各的坑。PJ85718DM 这颗器件在国内工控市场不算是烂大街的型号但它有几个特点非常适合 HVAC 类应用数字输出、可多点挂接、抗干扰能力不错。我手头这颗的实测分辨率能做到 0.0625°C 级别测温范围覆盖 -40°C 到 125°C对于风道、盘管、回风、室外温度这些典型场景都够用。选择 STM32F723IE 的原因更实际。首先是外设丰富它自带以太网 MAC配合外部 PHY 就能直接上 TCP/IPUSB 高速 OTG 可以用来做本地维护口多个 UART、SPI、I2C 口足够挂传感器和扩展板。其次是处理能力Cortex-M7 内核跑 216MHz做温度滤波和 PID 计算绰绰有余未来想加谐波分析或者预测算法也有余量。最后是封装和供货LQFP 封装方便手工焊接和 layout这颗型号在工业级温度范围内工作稳定。2.1 温度传感前端的关键选型逻辑我见过很多项目在传感器选型上只看精度忽略了三件事供电范围、输出接口、长期稳定性。PJ85718DM 支持 3.0V 到 5.5V 供电这样在 HVAC 控制板上可以直接用 3.3V 或 5V 电源不用额外做电平转换。输出接口是类单总线协议和常见的 DS18B20 类似但时序参数有区别代码不能用现成的库必须对着数据手册调时序。这一点我在第 3 节会展开。还有一个选型细节是封装。风道里传感器经常要延长线引出如果选用贴片封装的温度芯片探针焊接和防水处理会很麻烦。PJ85718DM 这类器件如果是 TO-92 或小型插件封装配合金属套管就能做成防水探头现场部署方便得多。2.2 STM32F723IE 在这个方案里到底干了什么从系统分工上看STM32F723IE 至少要跑四块任务温度采集调度、本地控制逻辑、远程通信协议、故障诊断。F723 的双核严格讲它还是单核 M7但配合 DMA 和中断优先级设计完全可以把实时采集和通信任务解耦。采集任务用定时器中断触发优先级最高本地控制用 1ms 或者 10ms 周期任务远程通信用低优先级任务专门跑 TCP 客户端。选型时我特别看重以太网 MAC。很多工业项目要求设备能直接接入现场局域网不需要单独配 DTU 或网关。F723 内置 MAC我外接一颗工业级 PHY 芯片比如常见的百兆 PHY就能省掉一颗 MCU。这个集成度让 BOM 成本可控也让故障诊断时少了一个环节。2.3 为什么不是随便拿个开发板就上原型验证阶段随便用开发板没问题但真正进 HVAC 产品有两个槛电磁兼容和温度范围。现场有继电器通断、变频器启动瞬间浪涌和辐射干扰很凶。普通开发板的电源滤波和地平面设计未必扛得住。我在这套方案里自己画了一块四层板传感器接口处加 TVS 管和共模电感电源入口加 π 型滤波实测辐射骚扰和 EFT 项目都能过。3. 本地温度链路的硬件与软件实现从接线到校准这一节讲的是最容易被低估的部分。很多人以为传感器读取就是“初始化、读寄存器、得温度”三步但 HVAC 现场温度读数不准、跳变、漂移绝大多数问题出在硬件布局和驱动时序上。3.1 传感器接线、去耦与延长线处理本地传感器如果直接焊在主板上接线比较简单。但 HVAC 项目里传感器经常要在风道内、盘管后、室外机附近延长线少则半米多则三米。PJ85718DM 的单总线协议对线缆电容敏感线太长、材质太差会出现读时序失败或者数据位错乱。我的经验是延长线使用双绞屏蔽线屏蔽层单端接地接到传感器侧的电源地去传感器电源脚对地并一个 0.1μF 陶瓷电容靠近器件引脚放置数据线上拉电阻取值要按线长调整1 米以内用 4.7kΩ3 米左右用 2.2kΩ太长就得上有源上拉或者改用 I2C/SPI 接口的传感器。现场实测中这个处理能让误码率下降一个数量级。另外要注意电源纹波。温度采集器件对电源噪声不是特别敏感但单总线读时序的高电平阈值是固定的如果 VCC 被继电器拉低到阈值以下读取就会间歇性失败。我在这套方案里把传感器供电单独用一个 LDO不从 24V 开关电源直接取就是为了隔离噪声。3.2 驱动代码里的关键时序与转换时间PJ85718DM 的驱动不能直接用常见单总线库原因是它的复位时序和 ROM 命令格式有差异。我在项目中是先看数据手册的时序图用逻辑分析仪抓波形确认再写驱动。核心流程是拉低总线一段时间产生复位脉冲释放总线等器件应答然后发送跳过 ROM 命令、启动温度转换命令等待转换完成后再读取温度寄存器。转换时间这个参数要特别留意。有的器件转换时间长达 750ms如果用默认超时去读会读到上一次的数据。我在代码里用定时器状态机启动转换后立刻返回等时间到了再由定时器回调触发读取。这样既不会阻塞主循环又能保证每次读到的都是新数据。/* 伪代码示例定时驱动的温度采集状态机 */ typedef enum { TEMP_IDLE, TEMP_START_CONV, TEMP_WAIT_CONV, TEMP_READ, TEMP_ERROR } temp_state_t; void temp_timer_isr(void) { switch (temp_state) { case TEMP_IDLE: temp_state TEMP_START_CONV; break; case TEMP_START_CONV: temp_start_convert(); temp_state TEMP_WAIT_CONV; break; case TEMP_WAIT_CONV: if (temp_convert_done()) { temp_state TEMP_READ; } break; case TEMP_READ: temp_read_value(temp_raw); temp_filter(temp_raw, temp_value); temp_state TEMP_IDLE; break; default: temp_state TEMP_IDLE; break; } }3.3 两点校准和软件滤波温度芯片出厂时有一致性误差但同一批次误差通常有固定偏移。我在产线校准里做两点校准一个用冰水混合物作为 0°C 参考一个用恒温槽或者精确电阻箱配合标准温度计做 50°C 参考测出每个传感器的偏移和增益误差写入 MCU 的 Flash 校准区。软件滤波我用的是中值加一阶低通两步走。先取最近 5 次原始值排序取中值滤掉毛刺再做一阶惯性滤波滤波系数根据采样周期调整。比如采样周期 500ms滤波系数取 0.2时间常数大约 2s既能平滑风机启停造成的微小波动又不会掩盖真实的温度趋势。4. 远程温度上报的工程化协议、缓存与断线恢复远程温度看起来只是“把本地温度打包发出去”但实际工程化以后协议设计、缓存策略、断线恢复这些环节才是真正花时间的地方。这里我分享一套在多个项目里复用过的做法。4.1 远程通道的选型取舍HVAC 设备常见的远程通道有三种以太网直连、串口转 4G DTU、私有无线。以太网直连适合有局域网或者能接入云平台的场景F723 自带 MAC 的优势就在这里串口转 DTU 适合现场没有网口的改造项目只需要走 UART 透传私有无线适合多设备组网但要自己考虑频点和协议栈。我在项目里首选以太网原因很简单数据量大、实时性好、调试方便。F723 跑 lwIP 协议栈TCP 客户端连接云端服务器默认每 10 秒上报一次温度数据。如果设备数量多再考虑改成 MQTT 协议F723 的资源跑 MQTT-SN 没问题资源和流量都比裸 TCP 友好。4.2 报文格式设计温度只是其中一部分远程报文不能只发温度值还必须带设备地址、通道号、时间戳、状态标志和校验。时间戳是很多人容易漏的尤其断网后补传数据时没有时间戳会让数据失去意义。我在报文里用 UNIX 时间戳由 MCU 的 RTC 提供并对时服务器或现场维护软件校时。| 帧头 0xAA55 | 设备ID 2B | 通道号 1B | 温度值 4B(int32, 0.001°C) | 状态字 2B | 时间戳 4B | CRC16 2B |温度值用有符号 32 位整数表示单位是 0.001°C。比如 23.456°C 表示为 23456。状态字里包含传感器通信错误、传感器短路/断路、本地控制状态等标志。CRC 校验必须加现场电磁环境里偶尔出现一个字节翻转没有校验平台就会记录一条假数据。4.3 断线重传与本地缓存策略远程链路断线后如果数据直接丢弃运维人员会发现温度曲线少了一段。我的做法是在 MCU 外部挂一颗 SPI NOR Flash按环形队列存储尚未成功上报的数据包。每包 32 字节一颗 8MB Flash 可以缓存 26 万条以上足够应对几天的断网场景。上报任务每成功收到服务器 ACK就清除对应缓存记录如果超时未 ACK保留并等待下轮重传。为了防止堆积还要设置缓存上限超过阈值就丢弃最旧的数据保证最新数据优先。这个策略很简单但很有效。很多开源项目只做“发出去就不管”一断网数据就空白到了复盘故障的时候完全无从查起。5. HVAC 场景特有的适配细节不是普通的数据采集器温度监测放进 HVAC 系统后很多细节会跳出来探头放哪里、告警怎么设、传感器电源能不能在被强干扰的环境里稳定工作。这些都需要按应用场景做适配不能照搬实验室做法。5.1 探头位置对读数的决定性影响同样是测量回风温度放在风道壁边和放在风道中心读数能差 2°C 以上。空气流动有边界层效应贴近壁面的空气流速低温度更容易受风道壁热传导影响。正确做法是让探头伸入风道中心位置并用支架固定避免贴在金属壁上。盘管出水温度、冷凝器进风温度、压缩机壳温这些不同测点的响应速度和绝对精度要求也不同。我习惯给每个传感器通道单独配置滤波系数和告警阈值而不是用一个全局参数套所有通道。比如风道温度滤波系数取小快速响应风机变化壳温滤波系数取大平滑短时波动。5.2 告警逻辑阈值 变化率组合判断单纯设一个温度上下限在 HVAC 现场很容易误报。比如除霜过程温度会突然升高如果只看阈值就会误告警。我的做法是双条件判断超阈值 变化率持续超过设定值。例如回风温度超过 35°C 且每分钟上升超过 5°C才判定为故障。这套逻辑在 STM32F723IE 上实现很轻松一段状态机就行。5.3 供电与 EMC 噪音的常见坑HVAC 控制柜里 24V 电源常常和大功率负载共用负载一启动传感器供电就会被拉低。针对 PJ85718DM 这类器件我在布局上做了三点改进一是传感器供电入口加磁珠二是传感器电源对地加大容量电解电容三是单总线数据线串 100Ω 电阻降低干扰耦合。现场整改后跳变次数从每几分钟一次降到几乎为零。现象可能原因处理办法温度读数周期性跳变电源被继电器拉低单独 LDO 供电加大电容读时序偶尔失败延长线太长且未用屏蔽线换双绞屏蔽线调上拉电阻远程数据乱码报文无 CRC 或波特率偏差加 CRC16校准波特率本地读数正常但远程偏差大远程采样与本地采样用了不同通道统一数据源共享采集队列6. 实测复盘一次温度跳变故障的完整排查过程最后分享一个我在现场真实遇到的排查过程算是把前面几节的坑串起来。这个案例发生在某商用楼宇的空调机组改造项目里设备是某设备厂商的嵌入式控制器主控就是 STM32F723IE温度采集用的 PJ85718DM。6.1 症状本地读数稳定远程平台出现周期性毛刺项目调试初期现场控制面板显示的送风温度始终稳定在 21.5°C 左右但远程平台每 2 分钟出现一次 35°C 的尖峰。第一次看到这个现象我以为是温度传感器故障于是带着逻辑分析仪去现场排查。6.2 排查链路先查通信再查供电最后查地线我先抓了远程报文的原始数据发现尖峰对应的温度值不是随机乱码而是某个固定值这和传感器偶发错误数据不符。接着用逻辑分析仪抓传感器总线波形发现触发尖峰的那轮读取根本没有应答信号代码走了错误处理分支把上次缓存里的一个异常初值发了出去。问题定位到单总线通信失败后我开始检查供电和地线。用示波器测传感器 VCC发现在空调压缩机变频启动瞬间电压会跌落近 1V刚好低于器件工作电压下限。进一步追查原因发现传感器电源直接从主控板 3.3V 输出取电而主控板 3.3V 同时给几个继电器驱动电路供电继电器一动作3.3V 就被瞬时拉低。6.3 根因与修复电源去耦 驱动容错双管齐下修复措施有两步硬件上把传感器供电改成独立 LDO输出端并 10μF 电解电容和 0.1μF 陶瓷电容软件上给读取函数增加连续三次失败判定失败次数超过阈值才报错单次失败只丢弃数据包。改完后再观察两周远程平台没有再出现毛刺。这个案例给我最大的教训是温度监测系统的可靠性百分之八十取决于电源设计和通信容错而不是传感器的“精度指标”。很多工程师拿到板子先调精度其实先把供电做好、协议做稳后面能省掉大量现场时间。另外提一个维护小建议远程平台侧一定要保留原始报文日志。现场排查时能看到完整日志往往比看温度曲线有用得多。我在这个项目里就是在日志里发现尖峰是固定值才顺着这条线很快定位到传感器总线的通信异常而不是在传感器本身瞎猜。