智能温度计这类产品续航翻车几乎是绕不开的一道坎。我前后经手过五六款不同形态的温度计项目有蓝牙的、有Wi-Fi的、有带屏幕的、也有纯贴片式的几乎每一款在量产前都会遇到标称一年、实际两周的尴尬。问题在于续航这东西不像功能bug那样有明确的报错它更像慢性病——你很难一眼看出是谁在偷偷耗电只能靠一套系统的排查方法把嫌疑对象一个个揪出来。这篇内容就是把我这些年排查温度计续航问题的完整思路拆开讲从功耗模型怎么建、测量工具怎么选、固件里哪些坑最容易踩到实测中那些反直觉的结论都会覆盖到。不管你是刚接手一个续航不达标的项目还是想在设计阶段就把功耗控制住这些经验应该都能直接用上。1. 先把续航问题拆成可量化的账很多人一上来就问为什么续航这么短这个问题太笼统了根本没法排查。我的习惯是先把续航换算成一笔可以算的账把续航短这个模糊的感受变成平均电流超标这个具体的数字问题。1.1 用平均电流反推理论续航电池续航的本质就是一个除法电池容量除以系统平均电流。比如一颗CR2032纽扣电池标称容量大约220mAh如果整机平均电流是25微安那理论续航就是220000微安时除以25微安约8800小时差不多一年。这个算法看起来简单但它是整个排查工作的锚点。我一般会先做一张这样的对照表把目标续航倒推成允许的平均电流目标续航电池容量允许平均电流1年220mAh约25uA2年220mAh约12.5uA6个月220mAh约50uA1年1000mAh锂亚约114uA有了这张表排查就有了明确的目标。如果实测平均电流是200微安而目标是25微安那说明有接近8倍的超额功耗需要找出来。这个倍数关系很重要它决定了你后面排查的优先级——是某个大块头在持续耗电还是很多小漏电叠加起来的。提示纽扣电池的实际可用容量往往只有标称的70%到85%尤其是低温环境下内阻上升有效容量还会进一步缩水。做理论计算时留20%余量别把账算得太满。1.2 区分工作功耗和待机功耗温度计的功耗结构通常分两块一块是测量和通信时的瞬时功耗另一块是两次测量之间的待机功耗。这两块的排查思路完全不同。工作功耗高往往是因为通信协议重、测量时间长、或者传感器预热电流大。比如某些温湿度传感器每次测量要持续几十毫秒电流能到几百微安甚至毫安级。如果测量频率是每分钟一次那这部分功耗其实占比不大但如果设计成每秒一次那工作功耗就会变成主导。待机功耗高问题通常出在休眠没睡干净——MCU没进最低功耗模式、外设时钟没关、上拉电阻一直在漏电、LDO静态电流偏大等等。这类问题最隐蔽因为它不表现为任何功能异常只是电池悄悄变少。我的经验是先测出整机的平均电流再分别测只待机不测量和只测量不待机两种状态的电流把总账拆成两笔问题范围立刻就缩小了一半。1.3 建立一份功耗预算表在动手改代码之前我会先让团队填一份功耗预算表把每个器件的预期电流列出来。这份表不需要特别精确但必须覆盖所有可能耗电的环节MCU运行电流、休眠电流、唤醒时间传感器测量电流、测量时长、待机电流无线模块发射电流、接收电流、休眠电流、唤醒开销显示屏点亮电流、刷新频率、背光电源部分LDO或DC-DC的静态电流、效率其他上拉电阻、分压电阻、LED指示灯把这份表加起来和实测值对比。如果实测远大于预算说明有预算外的漏电如果预算本身就超标那说明设计阶段就没算清楚得从架构上调整。这一步能避免很多改了半天代码发现是选型问题的无效劳动。2. 测量工具和测量方法决定你能不能找到真凶续航排查最怕的就是测量方法不对测出来的数字没有参考价值。我见过太多人拿个万用表串在电池上测电流结果因为万用表内阻和采样速度的问题测出来的值完全不能用。2.1 为什么普通万用表测不了动态电流温度计的电流是动态的大部分时间在微安级的休眠偶尔跳到毫安级的测量和发射。普通手持万用表的电流档采样率低、内阻大测休眠电流时它自身的压降会改变电路工作状态测瞬时电流时它又跟不上变化。你看到的可能是一个跳动的、毫无规律的数字根本没法用来算平均电流。正确的做法是用专门的功耗分析仪或者至少是一个高采样率、低内阻的电流采集方案。这类设备的核心能力是能连续记录电流波形采样率足够高至少几千次每秒并且能对时间做积分算出平均电流。2.2 用示波器加采样电阻的土办法如果手头没有专业功耗分析仪一个可行的替代方案是在电池和电路之间串一个小阻值的采样电阻比如10欧姆或100欧姆用示波器测电阻两端的电压再换算成电流。这个方法的关键是采样电阻要足够小不能影响电路正常工作同时示波器的带宽和采样率要够。具体操作上我会把示波器设成滚动模式或者长存储模式抓取一段完整的工作周期比如从一次测量到下一次测量的全过程。然后从波形上读出休眠电流、测量峰值电流、发射峰值电流以及每个状态持续的时间最后手动算平均电流。这个办法的缺点是费时间优点是直观——你能亲眼看到电流在什么时刻跳起来跳多高持续多久。很多隐藏的功耗问题比如某个外设在特定条件下没关掉就是靠看波形发现的。2.3 分段测量的隔离思路当整机平均电流超标时下一步是定位到具体模块。我的做法是分段隔离先断开无线模块的供电测一次再断开传感器测一次再断开显示屏测一次。每断开一个模块看平均电流下降多少下降最多的那个就是主要嫌疑对象。这个思路听起来笨但非常有效。我遇到过一个案例整机平均电流是目标的6倍断开无线模块后直接降到了目标的1.2倍问题一下就锁定在无线模块的休眠配置上。后来发现是模块的自动重连机制在后台一直尝试连接每次尝试都会唤醒射频累积起来就是巨大的功耗。注意分段测量时要注意模块之间的依赖关系。有些模块断电后MCU会检测到异常并进入重试循环反而让电流升高。所以每次断开后要观察一段时间确认系统进入了稳定状态再读数。2.4 长时间记录才能发现偶发功耗有些功耗问题不是持续存在的而是偶发的。比如每小时一次的数据上报、每天一次的校准、或者某个异常触发的重传。这类问题用短时间测量根本发现不了必须做长时间记录。我一般会让功耗分析仪连续记录至少24小时最好是72小时覆盖完整的测量周期和可能的异常场景。然后看平均电流随时间的变化曲线如果发现某些时间点有规律的电流尖峰那就要去查那个时间点系统在做什么。有一次我们发现温度计每天凌晨三点左右会有一个持续几分钟的电流抬升查下来是固件里的一个定时校准任务每次校准都会唤醒传感器和MCU而且校准后没有正确回到休眠。这种问题如果不做长时间记录永远找不到。3. 固件层面最常见的几个耗电陷阱硬件选型没问题、测量方法也对但续航还是不达标那大概率是固件的问题。固件层面的功耗陷阱特别多而且很多是看起来没问题、实际很耗电的类型。3.1 休眠没睡干净外设时钟和引脚状态MCU进入低功耗模式之前必须把所有不需要的外设时钟关掉把不用的引脚设成合适的电平状态。这两件事听起来是常识但实际项目里十有八九会漏。外设时钟没关MCU就算进了休眠模式外设还在跑电流自然下不来。我见过一个项目MCU休眠电流应该是1微安左右实测却是80微安查了半天发现是某个定时器的时钟没关那个定时器还在后台计数。引脚状态的问题更隐蔽。一个悬空的输入引脚如果没设成上拉或下拉它会因为电平不确定而在高低之间漂移导致输入级的MOS管反复开关产生额外的漏电。一个两个引脚可能只多几微安但如果有一排引脚都悬空累积起来就很可观了。我的习惯是在休眠前把所有GPIO的状态过一遍该输出低的输出低该上拉的上拉该关的模拟功能关掉。这份检查清单我会写进代码里每次进休眠前都执行一遍避免遗漏。3.2 无线模块的重连和心跳策略无线模块是温度计里最耗电的部分之一它的功耗策略直接决定整机续航。最常见的坑是重连机制和心跳策略设计得太激进。重连机制方面如果模块在信号弱的时候频繁尝试重连每次重连都要唤醒射频、扫描信道、发送请求功耗会急剧上升。正确的做法是设置退避策略重连失败后等待时间逐渐拉长而不是一直以固定间隔重试。心跳策略方面很多设计为了让云端知道设备在线会定期发送心跳包。心跳间隔越短功耗越高。如果心跳间隔是30秒那基本上模块一直在工作状态续航不可能好。我的经验是温度计这类低频设备心跳间隔可以放到几小时甚至更长或者干脆用心跳加事件上报的混合策略——平时不心跳有数据变化时才上报。3.3 传感器测量的频率和时长传感器的功耗取决于两个因素测量频率和单次测量时长。频率越高、时长越长功耗越大。测量频率要根据实际需求定。温度变化本身是缓慢的除非有特殊需求否则没必要每秒测一次。我一般会把测量间隔设在几十秒到几分钟之间具体看应用场景。如果是室内温度计一分钟一次足够了如果是冷链监控可能要更频繁但也要权衡续航。单次测量时长方面有些传感器支持单次测量模式测完自动进入休眠这种比连续测量模式省电得多。选型时要特别关注传感器有没有这种低功耗模式以及从休眠唤醒到出结果需要多长时间。唤醒时间越长MCU陪着等的时间就越长功耗越高。3.4 显示屏和LED的隐形消耗带屏幕的温度计屏幕往往是功耗大户。LCD本身功耗不高但背光很耗电。如果背光常亮续航基本没救。我的做法是背光只在按键或特定事件时点亮几秒平时完全关闭。LED指示灯也是类似的问题。有些设计用LED指示工作状态如果LED一直亮着或者频繁闪烁功耗会很明显。一个普通的贴片LED点亮电流几个毫安如果每天亮几个小时累积起来就是可观的电量。还有一个容易被忽略的点是屏幕刷新。如果屏幕内容没变就不要重复刷新。有些固件为了保险会定期全屏刷新每次刷新都要驱动一遍所有段码虽然单次功耗不大但频率高了也是负担。4. 电源电路和元器件的静态漏电硬件层面的漏电往往是最难查的因为它不涉及任何代码逻辑纯粹是电路设计和元器件特性导致的。这类问题一旦存在就是7乘24小时不间断地耗电。4.1 LDO的静态电流和选型误区很多温度计用LDO给MCU和传感器供电。LDO的静态电流也叫接地电流是一个关键参数它指的是LDO自身工作消耗的电流和负载无关。普通LDO的静态电流可能几十微安甚至上百微安对于目标是几十微安平均电流的系统来说这本身就是不可接受的。低功耗LDO的静态电流可以做到1微安以下但价格会贵一些。选型时一定要看数据手册里的静态电流参数而且要区分无负载静态电流和带负载时的接地电流后者往往更大。更彻底的做法是干脆不用LDO让MCU和传感器直接由电池供电或者用负载开关在不需要时把整个支路断掉。这样静态电流可以降到接近零。4.2 上拉电阻和分压电阻的持续消耗上拉电阻和分压电阻是另一个常见的漏电来源。一个10千欧的上拉电阻如果它连接的引脚一直是低电平那这个电阻上就会持续流过电流。在3伏系统里10千欧上拉、引脚拉低电流就是300微安这已经超过很多温度计的整机预算了。分压电阻用于电池电压检测时也是类似的问题。如果分压电阻一直挂在电池上它就会一直耗电。解决办法是用一个MOS管在需要检测时才把分压电路接通检测完立刻断开。我的经验是凡是直接跨接在电源和地之间的电阻都要算一下它的静态电流超过1微安就要考虑能不能去掉或者用开关控制。4.3 电容漏电和PCB表面漏电电容漏电在低功耗设计里也不能忽视。普通的铝电解电容漏电较大不适合用在微功耗电路里。陶瓷电容漏电小但大容量的陶瓷电容在高温高湿环境下也可能出现漏电增加的情况。PCB表面漏电则和板子清洁度、湿度、助焊剂残留有关。如果板子没洗干净助焊剂残留会在潮湿环境下形成微弱的导电通路导致漏电。这个问题在实验室里可能不明显但到了实际使用环境尤其是湿度大的地方就会暴露出来。我遇到过一个案例同一批板子有的续航正常有的明显偏短。查到最后发现是清洗工艺不稳定部分板子助焊剂残留偏多在潮湿环境下漏电。后来加强了清洗和烘干工序问题就解决了。4.4 电池自身的自放电和内阻有时候问题不在电路而在电池本身。电池都有自放电不同化学体系的自放电率差别很大。纽扣电池的自放电率相对较低但如果存放时间长了或者存储环境不好自放电会加快。电池内阻也会影响续航。内阻大的电池在大电流脉冲时压降大可能导致系统提前欠压复位或者让LDO工作不稳定间接增加功耗。选电池时除了看容量也要关注内阻和自放电参数。5. 一套可复现的排查流程前面讲的都是零散的知识点这一节把它们串成一套完整的排查流程。这套流程我在多个项目里用过基本能覆盖大部分续航问题。5.1 第一步确认目标算出允许平均电流先明确目标续航和电池容量算出允许的平均电流。这一步是所有后续工作的基准没有这个基准后面测出来的数字都没有意义。5.2 第二步长时间记录整机平均电流用功耗分析仪或等效方案连续记录至少24小时的整机电流算出实际平均电流。和允许值对比确认差距有多大。5.3 第三步分段隔离锁定主要模块依次断开无线模块、传感器、显示屏等观察平均电流的变化找出主要耗电模块。这一步能把问题范围从整机缩小到某个模块。5.4 第四步针对模块深入排查锁定模块后再深入排查。如果是无线模块查休眠配置、重连策略、心跳间隔如果是传感器查测量频率和时长如果是MCU查休眠模式和引脚状态。5.5 第五步改完复测确认改善每次修改后都要复测确认平均电流确实下降了。不要一次改很多地方否则出了问题不知道是哪个改动导致的。改一处、测一处稳扎稳打。5.6 第六步做边界场景测试常温下续航达标不代表所有场景都达标。要做低温测试、弱信号测试、频繁唤醒测试确认在边界条件下功耗不会失控。低温下电池内阻上升、传感器可能需要加热、无线模块发射功率可能提高这些都会影响续航。6. 几个反直觉的实测结论最后分享几个我在实测中遇到的、和直觉不太一样的结论这些经验在常规文档里基本看不到。6.1 有时候更省电的配置反而更耗电比如降低无线发射功率直觉上应该省电但如果功率太低导致重传次数增加总功耗反而可能上升。又比如延长测量间隔直觉上省电但如果间隔太长导致每次唤醒后需要更长的稳定时间单次功耗增加总账未必划算。功耗优化要看总账不能只看单点。6.2 休眠电流不是越低越好追求极低的休眠电流有时会牺牲唤醒速度。如果唤醒时间太长MCU陪着等的时间增加工作功耗上升总平均电流可能反而更高。休眠电流和唤醒开销要一起权衡。6.3 温度对功耗的影响比想象中大低温下电池内阻上升、容量下降同时某些传感器的测量时间会变长无线模块的发射功率可能需要提高。这些因素叠加起来低温续航可能只有常温的一半甚至更低。做续航评估时一定要把温度因素考虑进去。6.4 固件版本和续航的关系同一个硬件不同固件版本的续航可能差很多。每次固件更新后都要重新评估续航不能想当然认为只改了一点逻辑功耗不会变。我见过一次固件更新只是加了一个日志打印功能结果因为日志输出频繁唤醒了串口续航直接腰斩。排查智能温度计的续航问题说到底是一个算账、测量、隔离、验证的循环。先把模糊的续航感受变成具体的电流数字再用合适的工具测出真实值然后通过分段隔离锁定主要矛盾最后改一处测一处地验证。这个过程没有捷径但只要方法对再隐蔽的功耗问题也能找出来。我在实际项目里最大的体会是续航问题往往不是单一原因造成的而是好几个小问题叠加的结果所以排查时要有耐心一个一个解决别指望一招制敌。 
长河君 · 2026/9/30 0:02:42 · 阅读 1.2k 智能温度计续航翻车排查：从功耗模型到固件陷阱的完整实战
智能温度计这类产品续航翻车几乎是绕不开的一道坎。我前后经手过五六款不同形态的温度计项目有蓝牙的、有Wi-Fi的、有带屏幕的、也有纯贴片式的几乎每一款在量产前都会遇到标称一年、实际两周的尴尬。问题在于续航这东西不像功能bug那样有明确的报错它更像慢性病——你很难一眼看出是谁在偷偷耗电只能靠一套系统的排查方法把嫌疑对象一个个揪出来。这篇内容就是把我这些年排查温度计续航问题的完整思路拆开讲从功耗模型怎么建、测量工具怎么选、固件里哪些坑最容易踩到实测中那些反直觉的结论都会覆盖到。不管你是刚接手一个续航不达标的项目还是想在设计阶段就把功耗控制住这些经验应该都能直接用上。1. 先把续航问题拆成可量化的账很多人一上来就问为什么续航这么短这个问题太笼统了根本没法排查。我的习惯是先把续航换算成一笔可以算的账把续航短这个模糊的感受变成平均电流超标这个具体的数字问题。1.1 用平均电流反推理论续航电池续航的本质就是一个除法电池容量除以系统平均电流。比如一颗CR2032纽扣电池标称容量大约220mAh如果整机平均电流是25微安那理论续航就是220000微安时除以25微安约8800小时差不多一年。这个算法看起来简单但它是整个排查工作的锚点。我一般会先做一张这样的对照表把目标续航倒推成允许的平均电流目标续航电池容量允许平均电流1年220mAh约25uA2年220mAh约12.5uA6个月220mAh约50uA1年1000mAh锂亚约114uA有了这张表排查就有了明确的目标。如果实测平均电流是200微安而目标是25微安那说明有接近8倍的超额功耗需要找出来。这个倍数关系很重要它决定了你后面排查的优先级——是某个大块头在持续耗电还是很多小漏电叠加起来的。提示纽扣电池的实际可用容量往往只有标称的70%到85%尤其是低温环境下内阻上升有效容量还会进一步缩水。做理论计算时留20%余量别把账算得太满。1.2 区分工作功耗和待机功耗温度计的功耗结构通常分两块一块是测量和通信时的瞬时功耗另一块是两次测量之间的待机功耗。这两块的排查思路完全不同。工作功耗高往往是因为通信协议重、测量时间长、或者传感器预热电流大。比如某些温湿度传感器每次测量要持续几十毫秒电流能到几百微安甚至毫安级。如果测量频率是每分钟一次那这部分功耗其实占比不大但如果设计成每秒一次那工作功耗就会变成主导。待机功耗高问题通常出在休眠没睡干净——MCU没进最低功耗模式、外设时钟没关、上拉电阻一直在漏电、LDO静态电流偏大等等。这类问题最隐蔽因为它不表现为任何功能异常只是电池悄悄变少。我的经验是先测出整机的平均电流再分别测只待机不测量和只测量不待机两种状态的电流把总账拆成两笔问题范围立刻就缩小了一半。1.3 建立一份功耗预算表在动手改代码之前我会先让团队填一份功耗预算表把每个器件的预期电流列出来。这份表不需要特别精确但必须覆盖所有可能耗电的环节MCU运行电流、休眠电流、唤醒时间传感器测量电流、测量时长、待机电流无线模块发射电流、接收电流、休眠电流、唤醒开销显示屏点亮电流、刷新频率、背光电源部分LDO或DC-DC的静态电流、效率其他上拉电阻、分压电阻、LED指示灯把这份表加起来和实测值对比。如果实测远大于预算说明有预算外的漏电如果预算本身就超标那说明设计阶段就没算清楚得从架构上调整。这一步能避免很多改了半天代码发现是选型问题的无效劳动。2. 测量工具和测量方法决定你能不能找到真凶续航排查最怕的就是测量方法不对测出来的数字没有参考价值。我见过太多人拿个万用表串在电池上测电流结果因为万用表内阻和采样速度的问题测出来的值完全不能用。2.1 为什么普通万用表测不了动态电流温度计的电流是动态的大部分时间在微安级的休眠偶尔跳到毫安级的测量和发射。普通手持万用表的电流档采样率低、内阻大测休眠电流时它自身的压降会改变电路工作状态测瞬时电流时它又跟不上变化。你看到的可能是一个跳动的、毫无规律的数字根本没法用来算平均电流。正确的做法是用专门的功耗分析仪或者至少是一个高采样率、低内阻的电流采集方案。这类设备的核心能力是能连续记录电流波形采样率足够高至少几千次每秒并且能对时间做积分算出平均电流。2.2 用示波器加采样电阻的土办法如果手头没有专业功耗分析仪一个可行的替代方案是在电池和电路之间串一个小阻值的采样电阻比如10欧姆或100欧姆用示波器测电阻两端的电压再换算成电流。这个方法的关键是采样电阻要足够小不能影响电路正常工作同时示波器的带宽和采样率要够。具体操作上我会把示波器设成滚动模式或者长存储模式抓取一段完整的工作周期比如从一次测量到下一次测量的全过程。然后从波形上读出休眠电流、测量峰值电流、发射峰值电流以及每个状态持续的时间最后手动算平均电流。这个办法的缺点是费时间优点是直观——你能亲眼看到电流在什么时刻跳起来跳多高持续多久。很多隐藏的功耗问题比如某个外设在特定条件下没关掉就是靠看波形发现的。2.3 分段测量的隔离思路当整机平均电流超标时下一步是定位到具体模块。我的做法是分段隔离先断开无线模块的供电测一次再断开传感器测一次再断开显示屏测一次。每断开一个模块看平均电流下降多少下降最多的那个就是主要嫌疑对象。这个思路听起来笨但非常有效。我遇到过一个案例整机平均电流是目标的6倍断开无线模块后直接降到了目标的1.2倍问题一下就锁定在无线模块的休眠配置上。后来发现是模块的自动重连机制在后台一直尝试连接每次尝试都会唤醒射频累积起来就是巨大的功耗。注意分段测量时要注意模块之间的依赖关系。有些模块断电后MCU会检测到异常并进入重试循环反而让电流升高。所以每次断开后要观察一段时间确认系统进入了稳定状态再读数。2.4 长时间记录才能发现偶发功耗有些功耗问题不是持续存在的而是偶发的。比如每小时一次的数据上报、每天一次的校准、或者某个异常触发的重传。这类问题用短时间测量根本发现不了必须做长时间记录。我一般会让功耗分析仪连续记录至少24小时最好是72小时覆盖完整的测量周期和可能的异常场景。然后看平均电流随时间的变化曲线如果发现某些时间点有规律的电流尖峰那就要去查那个时间点系统在做什么。有一次我们发现温度计每天凌晨三点左右会有一个持续几分钟的电流抬升查下来是固件里的一个定时校准任务每次校准都会唤醒传感器和MCU而且校准后没有正确回到休眠。这种问题如果不做长时间记录永远找不到。3. 固件层面最常见的几个耗电陷阱硬件选型没问题、测量方法也对但续航还是不达标那大概率是固件的问题。固件层面的功耗陷阱特别多而且很多是看起来没问题、实际很耗电的类型。3.1 休眠没睡干净外设时钟和引脚状态MCU进入低功耗模式之前必须把所有不需要的外设时钟关掉把不用的引脚设成合适的电平状态。这两件事听起来是常识但实际项目里十有八九会漏。外设时钟没关MCU就算进了休眠模式外设还在跑电流自然下不来。我见过一个项目MCU休眠电流应该是1微安左右实测却是80微安查了半天发现是某个定时器的时钟没关那个定时器还在后台计数。引脚状态的问题更隐蔽。一个悬空的输入引脚如果没设成上拉或下拉它会因为电平不确定而在高低之间漂移导致输入级的MOS管反复开关产生额外的漏电。一个两个引脚可能只多几微安但如果有一排引脚都悬空累积起来就很可观了。我的习惯是在休眠前把所有GPIO的状态过一遍该输出低的输出低该上拉的上拉该关的模拟功能关掉。这份检查清单我会写进代码里每次进休眠前都执行一遍避免遗漏。3.2 无线模块的重连和心跳策略无线模块是温度计里最耗电的部分之一它的功耗策略直接决定整机续航。最常见的坑是重连机制和心跳策略设计得太激进。重连机制方面如果模块在信号弱的时候频繁尝试重连每次重连都要唤醒射频、扫描信道、发送请求功耗会急剧上升。正确的做法是设置退避策略重连失败后等待时间逐渐拉长而不是一直以固定间隔重试。心跳策略方面很多设计为了让云端知道设备在线会定期发送心跳包。心跳间隔越短功耗越高。如果心跳间隔是30秒那基本上模块一直在工作状态续航不可能好。我的经验是温度计这类低频设备心跳间隔可以放到几小时甚至更长或者干脆用心跳加事件上报的混合策略——平时不心跳有数据变化时才上报。3.3 传感器测量的频率和时长传感器的功耗取决于两个因素测量频率和单次测量时长。频率越高、时长越长功耗越大。测量频率要根据实际需求定。温度变化本身是缓慢的除非有特殊需求否则没必要每秒测一次。我一般会把测量间隔设在几十秒到几分钟之间具体看应用场景。如果是室内温度计一分钟一次足够了如果是冷链监控可能要更频繁但也要权衡续航。单次测量时长方面有些传感器支持单次测量模式测完自动进入休眠这种比连续测量模式省电得多。选型时要特别关注传感器有没有这种低功耗模式以及从休眠唤醒到出结果需要多长时间。唤醒时间越长MCU陪着等的时间就越长功耗越高。3.4 显示屏和LED的隐形消耗带屏幕的温度计屏幕往往是功耗大户。LCD本身功耗不高但背光很耗电。如果背光常亮续航基本没救。我的做法是背光只在按键或特定事件时点亮几秒平时完全关闭。LED指示灯也是类似的问题。有些设计用LED指示工作状态如果LED一直亮着或者频繁闪烁功耗会很明显。一个普通的贴片LED点亮电流几个毫安如果每天亮几个小时累积起来就是可观的电量。还有一个容易被忽略的点是屏幕刷新。如果屏幕内容没变就不要重复刷新。有些固件为了保险会定期全屏刷新每次刷新都要驱动一遍所有段码虽然单次功耗不大但频率高了也是负担。4. 电源电路和元器件的静态漏电硬件层面的漏电往往是最难查的因为它不涉及任何代码逻辑纯粹是电路设计和元器件特性导致的。这类问题一旦存在就是7乘24小时不间断地耗电。4.1 LDO的静态电流和选型误区很多温度计用LDO给MCU和传感器供电。LDO的静态电流也叫接地电流是一个关键参数它指的是LDO自身工作消耗的电流和负载无关。普通LDO的静态电流可能几十微安甚至上百微安对于目标是几十微安平均电流的系统来说这本身就是不可接受的。低功耗LDO的静态电流可以做到1微安以下但价格会贵一些。选型时一定要看数据手册里的静态电流参数而且要区分无负载静态电流和带负载时的接地电流后者往往更大。更彻底的做法是干脆不用LDO让MCU和传感器直接由电池供电或者用负载开关在不需要时把整个支路断掉。这样静态电流可以降到接近零。4.2 上拉电阻和分压电阻的持续消耗上拉电阻和分压电阻是另一个常见的漏电来源。一个10千欧的上拉电阻如果它连接的引脚一直是低电平那这个电阻上就会持续流过电流。在3伏系统里10千欧上拉、引脚拉低电流就是300微安这已经超过很多温度计的整机预算了。分压电阻用于电池电压检测时也是类似的问题。如果分压电阻一直挂在电池上它就会一直耗电。解决办法是用一个MOS管在需要检测时才把分压电路接通检测完立刻断开。我的经验是凡是直接跨接在电源和地之间的电阻都要算一下它的静态电流超过1微安就要考虑能不能去掉或者用开关控制。4.3 电容漏电和PCB表面漏电电容漏电在低功耗设计里也不能忽视。普通的铝电解电容漏电较大不适合用在微功耗电路里。陶瓷电容漏电小但大容量的陶瓷电容在高温高湿环境下也可能出现漏电增加的情况。PCB表面漏电则和板子清洁度、湿度、助焊剂残留有关。如果板子没洗干净助焊剂残留会在潮湿环境下形成微弱的导电通路导致漏电。这个问题在实验室里可能不明显但到了实际使用环境尤其是湿度大的地方就会暴露出来。我遇到过一个案例同一批板子有的续航正常有的明显偏短。查到最后发现是清洗工艺不稳定部分板子助焊剂残留偏多在潮湿环境下漏电。后来加强了清洗和烘干工序问题就解决了。4.4 电池自身的自放电和内阻有时候问题不在电路而在电池本身。电池都有自放电不同化学体系的自放电率差别很大。纽扣电池的自放电率相对较低但如果存放时间长了或者存储环境不好自放电会加快。电池内阻也会影响续航。内阻大的电池在大电流脉冲时压降大可能导致系统提前欠压复位或者让LDO工作不稳定间接增加功耗。选电池时除了看容量也要关注内阻和自放电参数。5. 一套可复现的排查流程前面讲的都是零散的知识点这一节把它们串成一套完整的排查流程。这套流程我在多个项目里用过基本能覆盖大部分续航问题。5.1 第一步确认目标算出允许平均电流先明确目标续航和电池容量算出允许的平均电流。这一步是所有后续工作的基准没有这个基准后面测出来的数字都没有意义。5.2 第二步长时间记录整机平均电流用功耗分析仪或等效方案连续记录至少24小时的整机电流算出实际平均电流。和允许值对比确认差距有多大。5.3 第三步分段隔离锁定主要模块依次断开无线模块、传感器、显示屏等观察平均电流的变化找出主要耗电模块。这一步能把问题范围从整机缩小到某个模块。5.4 第四步针对模块深入排查锁定模块后再深入排查。如果是无线模块查休眠配置、重连策略、心跳间隔如果是传感器查测量频率和时长如果是MCU查休眠模式和引脚状态。5.5 第五步改完复测确认改善每次修改后都要复测确认平均电流确实下降了。不要一次改很多地方否则出了问题不知道是哪个改动导致的。改一处、测一处稳扎稳打。5.6 第六步做边界场景测试常温下续航达标不代表所有场景都达标。要做低温测试、弱信号测试、频繁唤醒测试确认在边界条件下功耗不会失控。低温下电池内阻上升、传感器可能需要加热、无线模块发射功率可能提高这些都会影响续航。6. 几个反直觉的实测结论最后分享几个我在实测中遇到的、和直觉不太一样的结论这些经验在常规文档里基本看不到。6.1 有时候更省电的配置反而更耗电比如降低无线发射功率直觉上应该省电但如果功率太低导致重传次数增加总功耗反而可能上升。又比如延长测量间隔直觉上省电但如果间隔太长导致每次唤醒后需要更长的稳定时间单次功耗增加总账未必划算。功耗优化要看总账不能只看单点。6.2 休眠电流不是越低越好追求极低的休眠电流有时会牺牲唤醒速度。如果唤醒时间太长MCU陪着等的时间增加工作功耗上升总平均电流可能反而更高。休眠电流和唤醒开销要一起权衡。6.3 温度对功耗的影响比想象中大低温下电池内阻上升、容量下降同时某些传感器的测量时间会变长无线模块的发射功率可能需要提高。这些因素叠加起来低温续航可能只有常温的一半甚至更低。做续航评估时一定要把温度因素考虑进去。6.4 固件版本和续航的关系同一个硬件不同固件版本的续航可能差很多。每次固件更新后都要重新评估续航不能想当然认为只改了一点逻辑功耗不会变。我见过一次固件更新只是加了一个日志打印功能结果因为日志输出频繁唤醒了串口续航直接腰斩。排查智能温度计的续航问题说到底是一个算账、测量、隔离、验证的循环。先把模糊的续航感受变成具体的电流数字再用合适的工具测出真实值然后通过分段隔离锁定主要矛盾最后改一处测一处地验证。这个过程没有捷径但只要方法对再隐蔽的功耗问题也能找出来。我在实际项目里最大的体会是续航问题往往不是单一原因造成的而是好几个小问题叠加的结果所以排查时要有耐心一个一个解决别指望一招制敌。