搞嵌入式的人都有体会温度监测看着最不起眼做起事来最容易翻车。散热设计、功率器件温升、风管和回风口的温差监控任何一路测不准后面的控制逻辑全白搭。我最近刚把一个 HVAC 控制器项目从样板做到小批量核心组合就是 PJ85718DM 加 STM32F407VGT6目的就是在嵌入式和暖通两个场景里把本地与远程温度一次搞清楚。PJ85718DM 是 DS18B20 兼容的单总线数字温度传感器STM32F407VGT6 则是一颗主频 168MHz 的 Cortex-M4 主控资源非常富余。这套组合既能测主板附近的本地温度也能通过单总线长线把探头放到几十米外的风管和房间适合两类人参考一类是嵌入式设备里要做温度监控的另一类是 HVAC 自动控制里要采多路远程温度的。文章会从需求差异、器件选型、硬件电路、软件时序一直讲到现场排查尽量把我踩过的坑都摊开说。1. 项目背景嵌入式与 HVAC 的测温差在哪很多人一听到“温度监测”第一反应就是随便拿个传感器读一下就完事。但真把场景拆开看嵌入式板级测温跟 HVAC 环境测温的需求相差极大放在同一个系统里做得先想清楚每路探头是干嘛用的。1.1 嵌入式场景板级测温要的是“快”和“准”嵌入式系统里的温度监测绝大多数是板级、机箱级的。比如 MCU 附近的环境温度、电源模块的温升、功率 MOS 和电感的表面温度、电池包内部温度。这类测温点通常离主控近走线也就几厘米到几十厘米讲究的是响应快、能及时发现异常关键时刻要能触发降频或断电保护。这里有个容易踩的认知误区STM32F407 内部本身就带一个温度传感器精度也能看但它的绝对误差通常不小而且只能感知芯片结温不能代表板级空气温度和功率器件温度。所以我在这个项目里哪怕“本地温度”这种看似简单的需求也是用一颗板载的 PJ85718DM 直接放在疑似热点区域附近而不是依赖 MCU 内部传感器。本地温度的意义在于给控制逻辑一个“外部真实环境”的参考而不是拿芯片自己的温度来猜。1.2 HVAC 场景要的是“远”和“稳”HVAC 应用完全是另一种画风。测点通常分散在送风管、回风管、混风段、新风口、排风口甚至贴到冷媒管或电加热器表面。探头离主控盒几米到几十米都很正常现场还有变频器、压缩机启动、交流接触器吸合这些强干扰源。在这种场景里最怕的就是模拟传感器长线传输。我以前在某个项目里用 NTC 拉了几米线结果是每台设备都要做引线电阻校正现场穿管布线的时候稍微压一下线读数就飘。后来换成单总线数字温度传感器温度直接以数字形式传回抗干扰和免标定这两个优势非常明显。单总线只需要一根信号线沿线可以并联多个探头每个探头又自带唯一的 64 位 ROM 地址天然适合 HVAC 里多点分散测温的需求。1.3 为什么把“本地远程”放一套系统里标题里强调“本地和远程温度”其实说的是一套主控同时兼顾两种测点。本地探头放主控板负责机箱温度和设备自检远程探头走单总线长线出去负责风管、回风口、房间等远端环境温度。这样做的好处是软硬件平台可以复用不用为远程测温单独加一路采集板。我实际搭的拓扑是主控板上放 2 个本地探头分别测箱内气温和电源模块附近温度第二路总线从主控的端子排引出走屏蔽双绞线到空调风管区域最多挂了 8 个远程探头。这套系统再往上走STM32F407VGT6 通过 RS485 转 Modbus RTU 上报给楼宇自控网关那才算真正意义上的“远程监控”。也就是说这里有两层远程一层是探头在地理位置上离主控远另一层是温度数据通过网络传到监控中心远。在设计初期就要把这两层分开后面扩展才不会乱。2. 方案选型与系统拆解选型阶段我其实纠结过一阵子。核心问题就两个温度传感器用哪颗主控能不能撑得住。这两个问题想清楚后面的软硬件设计就顺了。2.1 PJ85718DM 的关键特性与兼容性定位PJ85718DM 是一款国产的单总线数字温度传感器指令集和电气参数跟 DS18B20 基本对齐。它的测量范围是 -55℃ 到 125℃默认 12 位分辨率也就是 0.0625℃ 的步进精度在 -10℃ 到 85℃ 范围内能做到 ±0.5℃这个量级对于嵌入式保护和 HVAC 舒适性控制都够用。供电支持 3.0V 到 5.5V单总线通信每个器件出厂带唯一 64 位 ROM 编码可以一条总线上挂多个节点。很多人问为什么不用 NTC 热敏电阻省那几毛钱不好吗我做过一个对比NTC 的优势是便宜、响应快但劣势也很明显需要恒流源或者分压电阻需要查表或公式标定批次之间一致性差而且模拟信号长线传输容易受干扰。单总线传感器虽然单价比普通 NTC 贵一些但省掉了信号调理电路和标定流程综合成本反而更低。下表是我在实际选型时列的对比对比项PJ85718DM 单总线数字传感器NTC 热敏电阻方案输出形式数字信号单总线串行输出模拟电阻变化需 ADC 采集转换标定免标定出厂校准每批次需校正实测差异明显接线一根数据线可并联多路每路两根线多个测点线缆量暴涨抗干扰数字信号抗长线干扰较好模拟信号易受干扰和线阻影响唯一识别64 位 ROM可寻址无地址概念只能一路一 ADC测温精度±0.5℃-10~85℃依校准精度现场很难做到一致这里特别提一句兼容性问题。因为它是 DS18B20 兼容器件我第一版程序直接用现成的单总线驱动库上电就能读到温度基本没有遇到协议层面的坑。但“兼容”不代表“一模一样”不同批次、不同封装的器件在时序裕量上会有细微差别所以我在固件里把读时序的采样点稍微往中间挪了挪给双方都留点余量这个后面软件部分细讲。2.2 STM32F407VGT6 的角色定位STM32F407VGT6 是一颗 Cortex-M4F 内核的主控主频最高 168MHz1MB Flash192KB RAM外设资源相当丰富。对于单总线测温这种任务来说它属于典型的性能过剩但这正好是优势温度采集只是其中一个任务主控还要跑控制逻辑、显示、通信协议甚至可能做简单的数据处理这些活它都扛得住。用 STM32F407 做单总线最大的好处是普通 GPIO 配合微秒级延时就能实现所有时序不需要额外硬件。像 F407 这种主频高的芯片用 DWT 计数器做精确延时非常方便比依赖 SysTick 中断或者 HAL_Delay 靠谱得多。这个点我在软件章节会专门展开。另外F407 的很多 GPIO 具有 5V 容忍能力如果单总线器件用 5V 供电选一个标注为 FT 的引脚直连也没问题。但我自己的项目里统一用 3.3V 供电和 3.3V 上拉这样整个系统的逻辑电平都是 3.3V少一层转换风险。2.3 系统拓扑与本地/远程探头的划分画拓扑之前我先定了两个原则第一本地探头和远程探头尽量分开走不同的总线避免远程侧一个干扰把板级温度也带崩第二远程总线从主板端子排引出时要经过一级 ESD 和滤波保护防止现场静电和浪涌顺线打进来。实际拓扑大概是这样的总线 A本地主控板上 2 个探头一个测板级环境温度一个贴在电源模块散热片附近走线长度小于 15cm。总线 B远程主控引出到接线端子经过屏蔽双绞线出机箱沿线在送风管、回风管、混风段布置 4~8 个探头最远端接近 20 米。数据上报STM32F407VGT6 的 USART 接 RS485 收发器通过 Modbus RTU 协议把温度和诊断信息上报给上位机。这个拓扑有一个工程上的好处本地总线短上拉电阻固定用一个值远程总线长上拉电阻单独优化。两边互不影响调试的时候也可以先把远程总线断开主控板自己照常工作故障定位会容易很多。3. 硬件连接与关键电路设计硬件电路是单总线系统里最容易被低估的部分。很多人 GPIO 一接上拉电阻一怼就开始调软件结果时序怎么调都调不稳。其实问题多半出在电路参数上。3.1 单总线连接原理与上拉电阻的取值单总线的物理层是开漏结构与线与逻辑。主机和从机都不能主动输出高电平它们能做的是拉低总线或者释放总线总线被释放后靠上拉电阻把电平抬回高电平。这样一来任何一方拉低整条总线就是低电平这就是“线与”。因为主机 GPIO 要模拟开漏所以软件上要把引脚配成开漏输出模式而不是推挽输出。推挽模式下如果主机输出高电平而从机也在拉低就会形成直接短路轻则数据错误重则烧引脚。我在样板调试时有个项目就犯过这个错换回开漏输出后一切正常。上拉电阻取值是第一个硬骨头。理论上阻值越小上升沿越陡长线驱动能力越强但阻值太小会导致从机拉低时电流过大影响低电平电压判断阻值太大总线带不动线缆和引脚的电容上升沿变缓读时序很容易失败。我习惯先算一遍。假设 10 米屏蔽线的总线寄生电容大约 10nF 到 15nF希望上升沿时间控制在 2μs 以内按 RC 估算τ RC。如果用 4.7kΩ 上拉配上 10nF 电容τ 47μs实际上升沿要到 100μs 以上这在单总线协议里是不可接受的。所以长线必须减小上拉电阻我实际用的原则是总线长度推荐上拉电阻备注1m 以内板级4.7kΩ常规值功耗也小5m~15m 布线2.2kΩ明显改善上升沿15m~50m 长距离1kΩ 或加大总线驱动配合屏蔽双绞线使用如果总线上挂的设备很多等效下拉能力会变强上拉电阻也可以相应调小一些。现场有条件时最好用示波器看上升沿调到 1μs 到 3μs 之间就是比较健康的状态。3.2 供电方式、去耦电容与屏蔽布线PJ85718DM 有两种供电方式一种是标准的 VDD/GND/DQ 三线制一种是寄生供电只接 DQ 和 GND从总线上窃取能量。寄生供电可以省一根线听起来很香但在长线、多节点、HVAC 强干扰环境下非常不稳定。转换电流最大时如果总线驱动能力不足电压会塌陷直接导致转换失败。所以我的项目里全部采用三线制VDD 统一从主控板上的 3.3V 输出取每个探头附近放一个 0.1μF 瓷片电容主控端的总线起点再放一个 10μF 电解电容保证瞬态电流需求。布线上远程总线我强烈建议用屏蔽双绞线。DQ 和 GND 走一对绞线VDD 和 GND 走另一对绞线屏蔽层在主控端单点接地不要两端都接否则会形成地环路反而把干扰引进系统。总线在机箱内部要避开开关电源、继电器、接触器这些强干扰源入口处加一个简单的 TVS 管比如 PESD 系列的封装能在现场静电打进端子时把电压钳位住。3.3 GPIO 配置要点与电平匹配STM32F407 的 GPIO 配置很简单但有几个细节要留意。首先必须选支持开漏模式的引脚实际上 F407 的 GPIO 都可以配成开漏。其次如果单总线外部上拉到 5V那必须确认引脚耐受 5V也就是数据手册里标注为 FT 的引脚如果上拉到 3.3V 就不用担心。我统一上拉到 3.3V省去电平匹配的麻烦。初始化代码大概是这样的我用的是 HAL 库风格实际工程里也可以直接用寄存器操作GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_13; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_OD; // 开漏输出模拟单总线线的与逻辑 GPIO_InitStruct.Pull GPIO_NOPULL; // 外部已有上拉内部上下拉都不用 GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; // 高速改善边沿 HAL_GPIO_Init(GPIOB, GPIO_InitStruct);这里有个很多人不知道的点开漏输出模式下引脚既可以输出 0 和释放也可以直接读输入电平。读输入不需要切换模式直接读 IDR 就行。所以单总线主机用开漏模式非常合适输出和输入共用一根引脚不需要反复初始化。4. 软件实现单总线时序与测温任务硬件调通之后真正的硬仗在软件。单总线协议的时序是微秒级的对于跑在 168MHz 的 STM32F407 来说时间控制不能靠简单的 for 循环数空指令必须用可靠的微秒级延时并且要考虑中断抢占的影响。4.1 微秒级延时DWT 计数器比 HAL_Delay 靠谱HAL_Delay 是基于 SysTick 中断实现的精度到毫秒级而且正被中断服务程序占用时调用会直接卡死。单总线的单个时隙往往就是 30μs 到 120μs毫秒级延时根本无法胜任。我推荐用 STM32 内核自带的 DWT 计数器它是调试观测单元里的一个时钟计数器每个机器周期加一可以实现高精度微秒延时。上电后先初始化 DWTstatic void dwt_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } static void delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000U); while ((DWT-CYCCNT - start) ticks); }这里有个重要的坑ticks 计算用的是 SystemCoreClock不是写死 168MHz。如果你在调试时把主频降到 16MHz但代码里写死了 168那所有时序都会整体漂移单总线直接罢工。用变量计算虽然多几条指令但换来的是不同主频下都能正常工作非常值。另外DWT 延时总会被中断打断但周期计算能保证总延时量近似正确。可是单总线协议对单个位时隙内的连续性有要求如果在你延时读到一半时来了一个长时间中断这个时隙就会失效。所以更稳妥的做法是在一个位时隙或一个字节的读写过程中进入临界区关闭中断。FreeRTOS 里可以用 taskENTER_CRITICAL 和 taskEXIT_CRITICAL一次最多也就占用几十微秒对实时系统影响很小。4.2 复位脉冲与存在脉冲检测单总线通信的第一步永远是复位脉冲。主机把总线拉低 480μs 到 960μs然后释放。总线上的从机检测到这个下降沿后会在 15μs 到 60μs 的时间内拉低总线输出一个约 60μs 到 240μs 的存在脉冲。主机读到这个低电平就知道总线上有设备。我实现的复位函数会在释放后延时 70μs 再读总线状态比协议允许的最小值稍微靠后一点这样能给响应慢一点的国产兼容器件一点余量static uint8_t ow_Reset(void) { uint8_t presence 0; HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_RESET); delay_us(600); HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_SET); // 释放总线 delay_us(70); if (HAL_GPIO_ReadPin(OW_GPIO_Port, OW_Pin) GPIO_PIN_RESET) { presence 1; // 检测到存在脉冲 } delay_us(410); // 等待存在脉冲结束保证总线进入空闲高电平 return presence; }如果 ow_Reset 返回 0说明总线上没有任何设备响应。最常见的原因是接线错误、上拉电阻没接、共地不良、或者 GPIO 没配成开漏。这个问题一半以上出在硬件而不是时序。4.3 读写时隙的具体实现单总线的所有通信都是通过读时隙和写时隙完成的。写 0 和写 1 的区别在于低电平持续时间写 1 是主机拉低 1μs 到 15μs 后释放总线高电平维持到时隙结束写 0 是主机持续拉低整个时隙大约 60μs 到 120μs。读时隙是主机拉低总线并快速释放从机如果拉低总线则表示输出 0释放总线则表示输出 1主机要在释放后大约 15μs 的时间点采集电平。代码里我分别实现了写位和读位static void ow_WriteBit(uint8_t bit) { if (bit) { HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_RESET); delay_us(2); HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_SET); delay_us(60); } else { HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_RESET); delay_us(60); HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_SET); delay_us(2); } } static uint8_t ow_ReadBit(void) { uint8_t bit 0; HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_RESET); delay_us(2); HAL_GPIO_WritePin(OW_GPIO_Port, OW_Pin, GPIO_PIN_SET); delay_us(5); if (HAL_GPIO_ReadPin(OW_GPIO_Port, OW_Pin) GPIO_PIN_SET) { bit 1; } delay_us(50); return bit; }这两个函数是所有单总线通信的基础。字节级的读写就是用循环把 8 个位组合起来LSB 优先。方向要特别注意单总线协议所有字节都是低位先发别按习惯把高位先发出去否则读回来的数据会完全不对。4.4 多探头识别ROM 搜索与地址缓存策略总线上挂多个探头时必须解决“如何知道总线上有哪些设备”的问题。PJ85718DM 和 DS18B20 一样每个器件有 64 位 ROM 码前 8 位是家族码中间 48 位是唯一序列号最后 8 位是 CRC 校验值。获取这些地址有两种方式。第一种是每次上电都执行 Search ROM 搜索算法主机不断读两位来选择分支遍历整棵 ROM 树把所有在线设备的地址全部枚举出来第二种是首次组装时在单总线只挂一个探头的情况下用 Read ROM 指令读取地址然后存入 STM32 的 Flash 或参数表之后运行时直接用 Match ROM 指令精确定位。我的工程做法偏向第二种。Search ROM 算法在数据链路不稳定或者总线上设备增减时很容易写崩溃排查也麻烦。而首检时逐个读取地址写入掉电保存参数区现场更换探头时再做一次地址登记这种方式简单可靠单设备时发 Read ROM0x33直接读 8 字节地址多设备运行时发 Match ROM0x55后面跟上 8 字节地址全总线广播则用 Skip ROM0xCC不跟地址让所有探头同时执行命令。地址在发送时按低字节到高字节的顺序逐字节发出和 ROM 码的位流顺序保持一致。实际固件里我用一个结构体把每个探头的地址、别名、安装位置存放起来现场调试时通过调试串口打印一张“地址-位置对照表”比对着图纸找探头靠谱多了。4.5 温度转换流程与暂存器读取温度采集固定分两个阶段。第一阶段让探头开始转换温度这期间探头会执行一次 A/D 转换12 位分辨率下最长时间是 750ms第二阶段等转换结束后读取暂存器里的温度数据。工程上的关键优化是让总线上所有探头并行转换。先发 Skip ROM 加 Convert T0x44这样所有探头同时开始转换然后利用延时等待的 750ms 去做刷新显示、处理 Modbus 报文等其他工作等时间差不多了再逐个 Match ROM 读取每个探头的暂存器。这比“一个探头转换完再下一个”的方式快得多。8 个探头如果串行转换光转换时间就是 6 秒并行转换后一轮采集时间大约为 750ms 加上 8 次短暂读取总耗时不到 1 秒。读取暂存器要发 Read Scratchpad0xBE读回 9 个字节。其中字节 0 是温度低字节字节 1 是温度高字节含符号位字节 8 是 CRC 校验值。组合成温度值的代码如下float Temp_Convert(uint8_t *scratch) { int16_t raw; raw (int16_t)(scratch[1] 8 | scratch[0]); return raw * 0.0625f; }严格说scratch[1] 需要先转换成无符号再左移否则在标准 C 环境下右移行为可能不确定。更稳妥的写法是int16_t raw (int16_t)((uint16_t)scratch[1] 8 | scratch[0]); return raw * 0.0625f;温度是负数时低字节照样有值用 int16_t 解释会自动做符号扩展不需要自己处理补码。12 位分辨率下每个 LSB 代表 0.0625℃所以直接乘以 0.0625 就是摄氏温度值。如果你只是做粗略监控也可以把分辨率配置成 9 位转换时间会降到 93.75ms适合追求实时性的场景代价是分辨率变差。CRC 校验一定不能省。单总线长线在 HVAC 现场经常会吃到干扰CRC 是最后一道防线。校验函数用 Maxim 单总线标准算法多项式是 x^8 x^5 x^4 1uint8_t CRC8_Check(uint8_t *addr, uint8_t len) { uint8_t crc 0; while (len--) { uint8_t inbyte *addr; for (uint8_t i 0; i 8; i) { uint8_t mix (crc ^ inbyte) 0x01; crc 1; if (mix) crc ^ 0x8C; inbyte 1; } } return crc; }在主循环里读取完 9 字节后先算 CRC8如果结果跟读取的第 9 字节不一致这组数据直接丢弃算某一路测温失败但不影响其他探头不要让脏数据进入控制逻辑。4.6 在 FreeRTOS 中设计测温任务的注意事项我的系统里跑着 FreeRTOS温度采集是一个独立任务优先级中等。之所以不设最高优先级是因为单总线一轮采集最长会占用 750ms 的等待和大约几十毫秒的通信时间不能让它在关键控制中断面前抢道。任务骨架大致是这样的void Temp_Client_Task(void *argument) { float local1, local2, remote[8]; uint64_t *addr_list (uint64_t *)load_probe_addr(); for (;;) { // 所有探头并行开始转换 ow_Reset(); ow_WriteByte(0xCC); // Skip ROM ow_WriteByte(0x44); // Convert T vTaskDelay(pdMS_TO_TICKS(800)); // 等待 12 位转换完成 // 先读本地总线 local1 Temp_ReadSingle(addr_local1); local2 Temp_ReadSingle(addr_local2); // 再读远程总线 for (int i 0; i remote_num; i) { remote[i] Temp_ReadSingle(addr_remote[i]); } // 更新共享变量上位机通过 Modbus 读取 vTaskDelay(pdMS_TO_TICKS(2000)); } }通信阶段要特别注意中断保护。单总线总线一条消息最长一次读 9 字节也就是几十毫秒所以我的做法是在 ow_WriteByte 和 ow_ReadByte 内部进入临界区而不是把整轮采集全部包进临界区避免长时间关闭中断影响系统响应。还有一个细节STM32F407 有多个 GPIO 端口本地总线和远程总线我用了两个不同的引脚它们的读写函数相互独立。万一远程总线在 HAVC 现场被干扰卡死本地总线依然能正常读温度主控不至于全盘瘫痪。这种冗余设计在工程交付时很重要。5. 实测数据与常见问题排查软件写完到现场调试真正的问题才开始显露。这部分我整理了自己实际碰到的几类现象和处理办法适合直接对照排查。5.1 连续运行实测表现在实验室环境里我先用一块样板验证了 2 个本地探头和 8 个远程探头。室温稳定时同一探头连续 100 次读取的温度值都在 0.06℃ 到 0.07℃ 范围内跳动基本就是 12 位分辨率的量化噪声。把其中一路远程探头放到一个恒温箱里设定 50.0℃实测读数稳定在 49.9℃ 到 50.1℃ 之间说明 ±0.5℃ 的指标是可以做到的。后来到 HV 现场远程总线走了大约 18 米屏蔽双绞线上拉电阻 2.2kΩ旁边有变频器和一天的启停干扰。把上拉换成 4.7kΩ 时偶尔会出现 CRC 错误和 -127℃ 的脏数据换成 2.2kΩ 后连续跑了一周CRC 错误率基本是零只在几次压缩机启动瞬间出现个位数的校验异常这在我的容错设计范围内。5.2 常见问题速查表现象可能原因解决措施总线上没有存在脉冲接线错误、未共地、上拉缺失检查 DQ/VDD/GND确认共地用万用表量上拉电压读温度一直 85.0℃读到上电默认值转换未生效确认 Convert T 命令执行等待时间是否足够温度显示 -127℃总线数据错误或 CRC 失败检查波形减小上拉电阻加强屏蔽某路温度偶尔跳变长线干扰或连接接触不良用屏蔽双绞线端子压接紧固考虑加 TVS多个探头地址相同没有执行地址搜索或读取错误逐个挂读地址用 Match ROM 精确寻址时序时好时坏延时不准或中断抢占用 DWT 延时位级通信区加临界区挂多探头后整体变慢串行转换耗时过长先 Skip ROM 发起并行转换再逐路读取5.3 调试心得与现场避坑技巧如果只能给一条调试建议我会说逻辑分析仪或者带解码的示波器是单总线调试的必备工具。你只要把 DQ 信号接到逻辑分析仪上解出单总线波形就能一眼看出是复位失败、某个位时隙过短还是从机根本没有任何脉冲。靠肉眼猜时序效率低而且容易把电路也怀疑进去。第一次接现场前建议先做一个总线扫描小工具把总线上所有探头的 ROM 地址和当前读数都打出来确认物理位置和地址的对应关系。这个工具花不了多少时间但是能帮你避免后面布线完成后搞不清楚哪路探头在哪个风管里的尴尬。还有个很小的经验PJ85718DM 这类 TO-92 封装探头在风管里安装时不要紧贴管壁金属外壳会直接传导管壁温度导致测的是风管材料温度而不是空气温度。把探头固定在风道中心位置用带孔的支架或者扎带悬空固定读数才真正代表风管内的空气温度。这个细节在暖气或者冷气系统里差个两三度太正常了。探头线缆的接线端子也要定期检查。HVAC 现场常有震动和冷热循环端子压接不紧的话一段时间后会出现接触电阻漂移。我做项目时会要求生产环节对每个接线点使用压线钳并打上标记方便后期维护。最后说点个人体会。我之前在 HVAC 项目里先用了 NTC 模拟长线结果每台设备都要校正引线电阻现场数据飘得厉害。后来换到单总线数字方案问题基本一次解决。PJ85718DM 这类 DS18B20 兼容器件最大的价值不是省那几毛钱而是把温度测量从“模拟调理问题”变成了“数字时序问题”而后者的确定性高得多。如果你也在做类似系统第一版就建议把本地/远程探头分成两条总线留好屏蔽接口后面扩展会轻松很多。这算是我踩过坑之后最想说的一句。
