1. 别急着算电流：先看DTU一次完整上报的电流波形
1.1 四段电流分别对应什么状态
做物联网设备的都知道，DTU（数据传输单元）这玩意儿看着不起眼，却是功耗计算里最让人头疼的一环。去年我们做了一套果园气象站的远程监控，4G DTU上报温湿度和土壤数据，选电池的时候我按模块手册上的“待机电流”做了个加法，12Ah订下去，心里盘算着两三年不用管。结果两个月后现场反馈电量只剩20%，最后用电流钳实测才发现，问题根本不是电池容量，而是整个功耗计算方法从一开始就不对。
很多工程师拿到DTU，第一反应是去看“发送数据时电流多大”，然后按一包数据几秒钟去算，得出一个非常乐观的续航。但真实的DTU电流远不是“一封数据就完了”，它比你想象的复杂得多。一次完整的上报，电流波形大致可以分成四段：
- 深度休眠段：整个设备没有业务，主控睡下去，模块进入PSM或休眠模式。这一段电流可以做到几十微安到几毫安，取决于外设有没有被彻底断电。
- 唤醒与初始化段：MCU醒来、传感器上电、模块重新上电或者从休眠恢复。电流通常在5~30mA，持续几十毫秒到几百毫秒。这一段往往被很多人忽略，因为时间短，但如果每天唤醒几百次，积少成多也很吓人。
- 搜网驻网段：模块重新入网或者附着网络，这是一次上报里最凶猛的电流段。2G模块峰值能到1.6~2A，4G模块稍微温和也有0.5~0.8A，NB-IoT则在0.3A左右。如果在信号好的地方，这个阶段可能1~2秒就过了；信号差一点，几十秒甚至几分钟都在硬扛。
- 数据收发段：建立TCP或者MQTT连接、发送数据、等待确认。电流取决于信号质量和调制方式，一般150~800mA，持续几百毫秒到几秒，数据大一点还会拉长。
把这四段分开看，才能真正理解DTU功耗的脾气。你发现没有，真正吓人的不是“发数据”那一下，而是“搜网驻网”这一段——它的电流最高、持续时间最不可控，偏偏又是每次上报都绕不过去的坎。
1.2 真正吃电的不是上报，是“维持在线”
我在很多项目里看到过一个共性误区：设备明明不需要被实时控制，固件却默认走了一条运营商的TCP长连接，靠每几十秒一次的心跳保活。这样做的原因是省事——服务器随时能连上设备，不用额外处理“设备不在线”的逻辑。但在电池供电场景里，这个“省事”贵得离谱。
移动网络为了省无线资源，设备没有业务时就会释放无线承载，模块为了保持长连接，得靠心跳让网络侧觉得“你还活着”，同时还要响应基站调度。这个时候模块并不会进入深睡，而是停留在idle状态，平均电流随信号和网络配置浮动，我实测常见在30~80mA之间。
做个直观对比。一台DTU维持长连接在线，平均电流按40mA算，一天耗电就是0.04A×24h＝0.96Ah。另一台DTU每天上报4次，每次从唤醒到发完数据回深睡一共12秒，上报期间平均电流0.35A，其余时间深睡50μA，一天耗电大约：
- 上报：4次×12秒＝48秒＝0.0133小时，0.0133×0.35A≈0.0047Ah
- 深睡：23.987小时×0.00005A≈0.0012Ah
- 日总耗电：0.0059Ah
两种模式差了大概160倍。同样的3400mAh锂电池，前者只能撑两三天，后者能跑一年多。所以，算DTU功耗的第一原则不是“算电流”，而是先问业务：我到底能不能不接受设备随时在线？只要想明白了这一点，功耗计算才谈得上有意义。
1.3 外围器件的隐形功耗
还有一个必须强调的点：DTU的功耗是整机功耗，不是模块功耗。外壳上印着“低功耗DTU”，不代表你的产品就是低功耗。主控MCU、传感器、RS485收发器、电平转换、LED指示灯、LDO空载损耗，全都挂在同一块电池上。
举几个我实际测过的例子：一颗RS485收发器如果一直使能接收模式，电流在1.5~3mA左右，24小时就是36~72mAh；一颗LED常亮，限流电阻按1k算也有3~5mA，24小时就是72~120mAh；一个LDO空载待机，规格书上可能写“几十微安”，实际加电阻网络、分压反馈之后，轻轻松松吃掉100~200μA。这些数字单独看都不大，但对于一个深度睡眠目标是50μA的设备来说，任何一个外设漏电流都是几十倍的预算超标。
我后来养成了一个习惯：计算功耗时把这个模块从底板上摘下来，再把整个底板的“裸奔电流”先测一遍。如果底板空载就费了几百微安，后面模块再省也是白搭。
2. 电池容量到续航天数：一套能落地的计算公式
2.1 从毫安时换算到安时的两个陷阱
很多人算电池寿命，直接拿电池容量mAh除以平均电流mA，得出小时数。这个算法有两个陷阱必须避开。
第一个陷阱是电压平台。mAh不是能量单位，同样是1000mAh，3.7V的锂电池和4.2V的锂电池能做的总功是不一样的。DTU模块的输入电压范围往往很宽，有的可以直接吃电池的3.4~4.2V，有的要稳压到3.3V，如果后端是3.3V电路，你还要考虑DCDC或者LDO的转换损耗。跨不同电压平台比较时，我建议用Wh（瓦时）做总账：Wh＝标称电压×Ah。这样至少你没把4.2V的容量当成3.7V的容量来用。
第二个陷阱是“容量并不能全放出来”。锂电池为了保护循环寿命，通常放电深度控制在90%以内，长期做100%深度放电，循环寿命衰减很快。更别说低温时电池容量会缩水，老化后容量还会进一步下降。所以电池标称的Ah，到最后能实实在在供给DTU的，通常要打七折甚至六折。我们用mAh做日常沟通没问题，但落到最终设计时一定要有这个折扣意识。
2.2 平均功耗的加权算法与完整算例
正确做法是把一天拆成若干个运行状态，每个状态的电流乘以持续时间，累加得到一天的耗电量，公式长这样：
Q_day(Ah) ＝ Σ( I_i × T_i )
其中I_i是第i个状态的平均电流（安培），T_i是第i个状态每天持续的时间（小时）。然后：
续航天数N ＝ ( Q_nominal×可用系数 ) ÷ Q_day
可用系数我建议起步取0.7，包含放电深度、低温衰减、老化、电源转换损耗和线路压降的整个余量。环境好的场景可以放宽到0.8，户外设备不建议超过0.75。
拿上一节那个“每天4次上报”的场景算一遍：电池用3400mAh锂电池，Q_nominal×0.7≈2.38Ah，日耗0.0059Ah，续航N＝2.38÷0.0059≈403天。如果改成常在线40mA，日耗0.96Ah，续航N＝2.38÷0.96≈2.5天。同样一块电池，两种策略能差出160倍，这就是通信策略对设备寿命的真实影响。
2.3 温度、老化、DCDC效率三个修正因子
为什么可用系数只取0.7而不是更乐观？因为户外设备几乎一定会同时撞上温度、老化和DCDC效率这三个问题。
锂电池对温度极其敏感，-20℃环境下放电容量可能只有常温的60%~70%，冬天和夏天的续航完全不是一个概念。老化方面，锂电池每年容量衰减能到2%~5%，如果项目要跑三年，你要按三年后的容量来设计，而不是按第一天的新电池算。电源转换效率听起来是小事，但DCDC在轻负载下效率掉得很厉害，很多标称90%效率的芯片，在1mA负载时实际只剩60%不到，电池端看起来就是电流凭空多了一截。
我把这几个系数乘起来给你看：放电深度0.9，低温容量0.8，两年老化0.8，DCDC加线路损耗0.9，0.9×0.8×0.8×0.9≈0.52。你如果什么都不考虑，用标称容量算出来是三年，加了修正之后可能只有一年半。这正是“理论续航”和“实际寿命”之间差距的主要来源。
3. 通信策略决定电池寿命：三种上报模式的实测对照
3.1 常连接+短心跳：实时性换来的电量代价
常连接模式在工业现场非常常见，因为服务器需要随时下发指令，比如远程继电器控制、参数修改、OTA。这种模式里DTU必须保持在线，心跳间隔一般设在20秒到1分钟，防止被运营商NAT超时断开。
我实测过一台4G Cat.1模块的整机，在信号满格、心跳30秒的配置下，平均电流大约35~45mA。再叠加主控和外设工作，整机50mA很正常。这个功耗意味着如果用3400mAh电池，理论可用寿命不超过3天，只有可充电、市电供电或者大电池组场景才扛得住。所以常连接模式不能算“电池供电方案”，它更适合有持续电源的场景。
如果你非要在电池供电里保留接近实时的控制能力，可以退一步用“短连接+空窗监听”的思路：设备每5分钟醒来一次，连接服务器查询有没有待下发指令，没有就立刻回深睡。这比长连接省得多，但实时性也降到了“分钟级”，这是业务和功耗之间的真实取舍。
3.2 定时上报+深度休眠：低功耗的首选
我做的多数野外监测项目都走这条路线：平时深度休眠，到点醒来上报一次，然后立刻睡回去。关键是休眠时要把外设电源也彻底切断，而不是仅仅把主控睡下去。
具体做法：给RS485收发器、传感器、电平转换这些外设加MOS管电源开关，由主控GPIO控制。设备进入深睡时，整个外围链路断电，只剩下实时时钟RTC和模块的低功耗唤醒定时器在跑。这一套做下来，整机深睡电流可以压到50μA以内。再结合合理上报频率，3400mAh电池撑一年以上是很常见的。
这种模式最适合的典型业务是环境监测、土壤墒情、井盖状态、农业大棚这种“隔一段时间看一个数”的场景。像食用菌栽培车间的环境监控，温度湿度本来变化就慢，30分钟甚至1小时上报一次完全够用，完全没有必要让模块一直挂在网上。
3.3 事件触发和NB-IoT的PSM/eDRX怎么选
事件触发是定时上报的补充，典型场景是机房漏水、门窗入侵、烟感报警。平时不报，事件发生才唤醒设备发一条数据。这其实是功耗最优的，因为“什么也不做”就是最低功耗。但你要接受一个现实：设备平时处于离线状态，事件上报的时间取决于唤醒速度，如果事件本身发生在深睡状态，唤醒和搜网有个延时，这个延时必须让下游业务知道。
NB-IoT的PSM（省电模式）和eDRX（扩展非连续接收）是另一条路。PSM下模块注册完就进入深睡，下行数据由核心网缓存，设备下次上报时再取；eDRX则是把监听寻呼的间隔拉长，降低功耗。这两种模式让“远程设备长期离线但随时能报到”成为现实，特别适合水表、气表、烟感这类业务。
表里的数据可以直观看出差距：
| 通信策略 | 典型配置 | 整机日耗估算 | 3400mAh电池估算寿命 | 适用业务 |
|---|---|---|---|---|
| 常连接+短心跳 | 4G Cat.1，30秒心跳 | 约0.96Ah | 约2.5天 | 实时双向控制、在线监控 |
| 定时上报+深度休眠 | 每3小时上报一次，每次15秒 | 约0.0107Ah | 约222天 | 环境监测、数据采集 |
| 定时上报+深度休眠 | 每天4次上报，每次12秒 | 约0.0059Ah | 约403天 | 低频遥测、农业监控 |
| NB-IoT PSM | 每4小时上报一次 | 约0.001Ah以内 | 数年（受电池自放电限制） | 表计类、烟感、井盖 |
有一点要提醒：PSM不是万能药，它的下行实时性很差，网络侧缓存的数据要等设备下一次醒来才能拿到，中间延迟可能几十秒到几十分钟。如果你的业务要求“在线状态下立刻收到告警”，PSM并不合适。
4. 现场实测要比数据手册可靠：低成本测量与统计方法
4.1 串采样电阻抓电流波形
数据手册上的电流参数是在实验室的理想条件下测的，真实信号、真实电源、真实外设都会有偏差。所以我的习惯是所有续航估算都要用实测数据回填，而且必须抓波形而不是只看一个平均值。
低成本测量法很简单：在电池和DTU供电回路之间串一个精密采样电阻，用示波器测电阻两端的电压，再用欧姆定律换算成电流。采样电阻选多少？我建议用0.02Ω到0.1Ω之间的低阻合金电阻，1%精度起步。以0.02Ω为例，模块峰值电流2A时，电阻压降只有40mV，对供电电压影响不大，功耗0.08W，用1W封装很稳。
示波器探头要解决共地问题。最好的方式是示波器用A-B通道做差分测量，或者买一个便宜的差分探头。千万别把示波器地线夹在采样电阻的高压侧再碰低压侧，那等于把电池短接了一条地回路，轻则测量失真，重则烧探头。
抓波形的时候，把示波器设置成滚动模式，采样率不用拉满，能覆盖一个完整上报周期就行。重点看四段电流的持续时间和幅值，尤其要确认“搜网驻网”这一段的时长，它直接决定单次上报耗电量。
4.2 用脚本把波形积分成毫安时
波形抓下来之后，别拿眼看，直接用脚本来积分。把示波器或者电流记录仪的数据导出CSV，每行是“时间、电流”，然后做积分：
import csv # 文件格式：time_sec,current_a rows = [] with open('dtu_current_log.csv') as f: reader = csv.reader(f) for line in reader: if line[0].startswith('time'): continue rows.append((float(line[0]), float(line[1]))) total_ah = 0.0 for i in range(1, len(rows)): dt = rows[i][0] - rows[i-1][0] # 安时 = 电流(安培) × 时间(秒) / 3600 total_ah += rows[i-1][1] * dt / 3600.0 print(f'记录期间总耗电: {total_ah * 1000:.2f} mAh')这个脚本逻辑很直白，就是梯形积分。采样率建议至少在1kHz以上，因为模块的峰值电流尖峰只有几毫秒，采样率太低会漏掉它们，导致平均电流被低估。记录时长至少要覆盖一个完整上报周期，如果要评估长连接策略，最好连续记录24小时，避免心跳周期和数据收发叠加时漏算。
4.3 信号强度的隐藏变量
功耗计算里最容易翻车的就是信号强度。模块的发射功率不是恒定的，它由基站通过功率控制和自适应调制决定，信号越差，PA输出功率越高，电流就越大，而且弱信号下HARQ重传变多，单次上报时长也会拉长。
我整理过一组典型的4G模块数据供参考：RSRP在-80dBm以上的好信号区，上报期间平均电流大约0.15~0.25A；-100dBm时大概0.35~0.5A；到了-110dBm以下，电流能到0.5~0.8A，而且因为重传和调度降速，完成一次上报的时间可能延到好几秒。单次上报耗电量在“最差信号”和“最好信号”之间差出3到8倍是常有的事。
所以现场实测的一大要点是：别捡信号最好的位置测，要在设备真实部署的位置或者最差信号点测。如果项目还没定址，就用P90的概念：把现场多个点位测一遍，取90%点位都能超过的信号强度作为计算基准，剩下的10%就当余量。
5. 把寿命做上去的优化清单：不只是换个更大电池
5.1 上报逻辑与数据打包
换大电池是最直接的思路，但也是最偷懒的思路。多数情况下，通过优化上报逻辑和通信行为，你能省出来的电量远大于多加一块电池。
先说数据打包。原来一个设备采集了100个点，如果每采集一个点就连接一次服务器发一条包，那就要建立100次连接。如果设备本地先把100个点攒起来，一次连接发一条长包，连接次数直接少了两个数量级。业务侧只要能把实时性容忍到“攒一轮再发”，这个优化立竿见影。
再说协议选择。HTTP每次请求都要建立TCP连接，而且应用协议的握手开销大；MQTT和CoAP这类轻量协议针对低功耗场景优化过很多，连接保持、重传机制都比HTTP更适合电池供电设备。同一个4G模块，用MQTT代替HTTP做定时上报，单次传输时长能明显缩短。
重连退避也必须写进固件。模块在弱信号下入网失败，如果立刻重试，那就是一次又一次的全功率搜网，电流直接爆炸。正确的做法是指数退避：第一次失败后等5秒，第二次等20秒，第三次等60秒，之后每隔几分钟再试。哪怕业务上需要尽快恢复连接，最多把退避上限设成30秒，也远好过无限快速重试。
5.2 电源链路和天线系统
电源链路设计的首要原则是：能用电池直供的，就不要过转换。很多4G模块的供电范围是3.4~4.2V，正好落在3.7V锂电平台上，可以直接接电池。主控和外设如果需要3.3V，再单独用DCDC降压。这样避免了两级转换，模块这一路没有额外损耗。
如果必须用DCDC，一定要看“轻载效率曲线”，而不是只看满载峰值效率。低功耗设备的待机电流往往只有几百微安，这时候DCDC如果有几个毫安的静态功耗Iq，模块再省也被拖垮了。选型时要盯住两件事：Iq静态电流够不够低（1μA级别），以及1mA负载时效率还能不能到70%以上。这两个指标不满足的DCDC，再便宜也别用。
天线系统同样影响功耗。同样的模块和信号环境，换一根高增益的天线，上行信号质量提升，模块会被基站调度到更低的发射功率档位，电流自然下降。反过来，天线驻波比偏高或者馈线过长，PA发出的功率有一部分反射回模块，不仅发热，还让电池白白耗电。室外部署就算不是远距离通信，也别省天线那几十块的成本，收益是实打实的续航。
5.3 固件和外围电路的细节
真正做低功耗设备的人都知道，固件里的细节比硬件更能决定成败。
第一是串口日志。调试阶段开着串口打印没问题，量产固件里一定要关掉，或者设置成只有告警才输出。我曾经做过对比：同一个设备，串口每5秒打印一行日志，CPU和外设工作电流能多出10~15mA，而且日志输出时MCU没法进深睡。别小看这个，持续24小时，一天就是240~360mAh，对电池设备是巨大的负担。
第二是LED指示灯。工业DTU外壳上常见的Power、Net、Serial三颗灯，每颗5~10mA，如果全亮或者脉宽很长，一天下来非常可观。正确做法是LED只在调试模式下点亮，量产默认关闭；或者把“网络状态灯”改成1秒亮20ms的低占空比呼吸方式，既能指示状态，耗电也降到了原来的几十分之一。
第三是外设彻底断电。我前面提过RS485接收器，它空闲时也有1.5~3mA的电流。给这一路加一个MOS管开关，深睡时切断，整机待机电流能立刻降下来。传感器也一样，很多温湿度传感器的测量电流虽然小，但在静态测量模式下依然有几十微安到几百微安，深睡时切掉电源，效果立竿见影。
6. 我踩过的三个功耗坑：教训比方法更值钱
6.1 标称待机电流在弱信号下直接失效
回到开头那个果园气象站项目。当时按模块手册上的“平均待机电流”估算续航，结论是两到三年，结果两个月电量剩20%。排查时用电流记录仪连续抓了一晚上，看到的波形让我直接傻眼：设备根本不是平稳待机，而是每隔十几分钟就出现一次0.8A的尖峰，持续5秒左右。
顺着这个尖峰追下去，发现是模块在弱信号区域反复掉线重连。现场RSRP测出来大概-112dBm，属于很差的信号区，模块每一次重连都要经历完整搜网、驻网、附着流程，按满格信号的时长去估，自然完全失真。后来把原来那根1.2米的胶棒天线拆了，换成高增益天线引到杆顶，信号改善之后重连频率掉下来，续航才回到正常水平。
这个坑的教训就是：算功耗不能只看静态参数，必须把“最弱信号下的重连行为”当成一个正常状态去预算。尤其地下管廊、设备井、建筑内部这些信号脆弱的地方，模块的重连频次是续航的头号杀手。
6.2 指示灯和串口日志悄悄吃掉一半电量
另一个项目给我的教训更直接。开箱即用的测试版设备，放在实验室里跑功耗，整机待机电流始终比预期高20mA左右。排查了很久，最后才发现罪魁祸首是外壳上三颗LED全亮，外加调试串口一直在跑后台日志。
当时做了个实验：一组保持LED常亮和串口打印，另一组把LED和日志全部关闭，其他条件完全一样，24小时后电量统计差了45%。这个数字让我很震惊，因为没有任何一个数据手册会告诉你“默认配置”里有这么多隐藏电耗。从此以后，我验收任何DTU样机，第一件事就是看固件默认配置的LED和日志行为，再决定要不要改。
6.3 低价DCDC在轻载时效率惨不忍睹
还有一次是原理图省成本，选了一颗国产DCDC，满载效率标称85%，价格确实便宜。整机调试完测功耗，发现深睡电流怎么都降不到1mA以下，一直在2mA左右晃。换回经验丰富的电源芯片之后，同样测试条件下深睡电流直接降到了0.5mA。
查资料才明白，那颗DCDC在1mA负载时效率只有30%左右，大部分电流都消耗在自己的控制电路和开关损耗上。这个案例给所有做低功耗产品的朋友提个醒：DCDC的效率曲线是随着负载变化的，满载效率高不等于低功耗场景表现好。对电池供电的DTU来说，1mA负载时的效率就是你真实的待机效率，这一项一定要看数据手册里的效率曲线图。
最后再分享一个我的工作习惯：每次做完一个低功耗项目，我都会把“理论计算值—实验室实测值—现场实测值”三列数字填在同一个表格里，标出差异来源。这样一次一次积累下来，你对“余量该留多少”的判断会越来越准。如果你正在做物联网毕业设计或者入门工程开发，做完基本功能之后不妨也照这个思路把功耗分析走一遍，你会发现，这个分析过程的含金量往往比功能本身更值得写进报告里。
