1. 某次续航翻车之后我把功耗账重新算了一遍三年前我刚接手一款蓝牙模块的功耗优化时一直有个错觉只要选了一颗标称待机电流只有1微安的BLE SoC产品续航就不会差。结果样机在老化架上跑了不到两个月电池电压就开始跳水用户反馈的实际续航连标称的一半都不到。后来我把整条链路拆开重新测了一遍才发现问题根本不在芯片而在我对平均电流的理解太粗糙。这大概是我在自有制造兜底能效这件事上交的第一笔学费。这篇文章把这段经历里真正有用的东西整理出来BLE设备的功耗由哪些部分组成、硬件和协议栈各有哪些优化空间、制造环节又是怎么决定批量一致性的。适合刚接手低功耗无线产品、以及被标称续航坑过的硬件工程师参考。我尽量少讲空话直接给方法和数据。1.1 BLE功耗模型的三张面孔做低功耗无线产品脑子里要同时装三组电流数据不是只看芯片手册上的一个数就够了。第一组是待机电流Sleep Current。设备99%的时间都在睡觉这个电流直接决定了续航的地板。现代BLE SoC在RTC唤醒、RAM保持的情况下待机能做到1微安甚至更低。但芯片待机不等于整板待机板上还有传感器、上拉电阻、电源芯片、指示灯每一路漏电都会叠加。第二组是事件峰值电流。一次广播一次连接事件一次传感器采样加Flash写入都是毫秒级的电流尖峰。峰值电流本身不决定续航但它决定了你的电池能不能扛得住电压会不会瞬间跌到复位阈值以下。很多纽扣电池设备续航算得很好实际却不断重启就是因为峰值电流把电池电压拉崩了。第三组才是决定续航的平均电流。平均电流不是三个数简单取平均而是把所有周期性的电流波形对时间做积分再除以周期。BLE设备的工作状态高度碎片化真正决定平均电流的是事件电流 × 事件时长 / 事件周期这个占空比公式。我习惯在项目一开始就建一张功耗预算表把每个周期的每个状态都列出来睡眠多久、醒来多久、射频开多久、传感器转多久、Flash写多久。这张表从立项到量产会不断修订它是我判断“某处优化值不值得做”的唯一依据。1.2 先学会估算再谈优化拿一个最常见的BLE温湿度标签举例。电池是CR2032容量按220毫安时算。设备每10秒醒来一次读传感器并广播一包数据。我们先粗算假设每次唤醒加广播事件需要5毫秒事件期间平均电流8毫安传感器加射频睡眠期间平均电流3微安。那么一个10秒周期内的平均电流大概是8mA × 0.005s ÷ 10s 3µA ≈ 4µA 3µA 7µA。220mAh ÷ 7µA ≈ 3.5年。听起来很不错。但这个估算是理想的。CR2032在持续几个毫安的脉冲负载下实际可用容量会打折扣低温下掉得更快产线上每台设备的待机电流也不会都恰好是3微安可能有的板子是5微安有的是8微安。所以我的经验是预算表里永远给自己留30%的电流裕量。上面这个例子如果平均电流算出来是7微安我会把产品目标定在10微安以内否则后患无穷。这也是自有制造兜底的意义所在实验室里一台样机做到7微安很容易但量产一百台、一千台都能稳定落在7微安附近靠的是制造端的测试、筛选和校准。没有产线数据功耗预算表就永远只是PPT。1.3 测平均电流为什么不能拿万用表串联很多第一次做BLE的工程师喜欢拿数字万用表的电流档直接串进电池回路看一个读数就算完事。这个操作在纯直流电路里没问题但在BLE设备上是灾难。BLE的射频事件只有几毫秒峰值电流十几毫安而数字万用表电流档的采样率通常只有每秒2到5次积分窗口又长它对这种短脉冲的响应几乎全是低通滤波后的平均结果且误差极大。更麻烦的是万用表电流档的内阻通常有几十到几百欧姆串进电池回路后设备在射频事件期间可能直接欠压复位。你测到的不是设备真正的功耗而是设备被测量工具搞得不断重启的功耗。我现在的标准做法是用高侧采样电阻加差分放大配合示波器抓电流波形或者直接用功耗分析仪它的动态范围能同时覆盖微安级睡眠电流和毫安级射频脉冲。测平均电流时示波器记录至少10个完整工作周期用数学通道做积分平均。还有一个人人都踩过的坑调试器没拔。芯片的SWD引脚被调试器拉高SoC永远进不了深度睡眠待机电流从1微安直接飙到几百微安。所以每次测待机电流之前先确认设备已经物理断开调试器并且用电流波形确认睡眠状态确实进去了。2. 硬件设计里的隐形耗电电源拓扑、漏电路径与射频链路软件配置确实是BLE功耗优化的大头但硬件设计里的隐形消耗往往更阴险。它不是一次性吃掉几十毫安而是让设备的地板电流悄悄抬高几微安你很难从功能表现上察觉只能靠高精度测量发现。我复盘过不少项目发现硬件侧的功耗问题集中在三个方向电源转换拓扑选择不当、外围无源器件漏电、射频天线失配。这三个问题有一个共同特征它们几乎不会在单台样机上暴露而是等到批量生产或温度变化时才集中爆发。2.1 DC-DC在轻载时可能比LDO更费电BLE设备经常是睡10秒、醒5毫秒的工作模式平均负载电流很小只有几微安到几十微安。很多工程师一看电池供电下意识就选DC-DC降压觉得开关电源效率高。这个想法在平均负载几十毫安以上没错但在微安级负载下可能完全反过来。DC-DC的静态电流Quiescent Current和开关损耗在那里摆着哪怕没有任何负载它本身也要消耗几微安到几十微安。LDO虽然转换效率低但静态电流通常只有几百纳安到几微安。如果设备平均电流只有10微安DC-DC在轻载下可能从电池吃掉20微安而LDO加一个低功耗SoC可能总共只吃掉12微安。账一算LDO反而更省。我在某个低功耗门磁项目里就遇到过这种情况硬件上用了某国产DC-DC空载静态电流标称5微安实际低温下漂到15微安整机待机电流比预期多了将近10微安。后来把方案改成传感器用LDO、射频峰值期间靠大电容缓冲待机电流才降回来。当然如果设备的射频事件频次很高、平均负载达到几百微安以上DC-DC的优势就很明显。这里没有绝对答案只有针对你的占空比算出来的答案。2.2 一颗电容在低温下改写了整个功耗曲线有两类电容问题在量产阶段最容易爆雷。第一类是滤波电容和储能电容的漏电。陶瓷电容的绝缘电阻理论上很高但不同介质、不同厂家的实际漏电差别很大。我们曾经在产线上抽检待机电流发现同一批板子中有大约5%待机电流比平均值高出3到5微安。逐板排查最后定位到一颗X5R材质的100nF电容在板子清洗不干净时会形成微小的漏电通道。换用漏电流更低的C0G电容并改进清洗工艺之后问题消失。第二类是射频匹配电容的温度特性。X5R、Y5V这些高介电常数陶瓷电容容值会随温度和直流偏置电压大幅变化。Y5V在低温下容值可能掉到标称值的50%以下。放在射频匹配网络里一颗电容容值变了整个匹配就偏了反射损耗变大发射功率上不去设备只能拿更高的PA电流去补偿或者干脆不断重传。电流多出来多少我们实测过一个项目匹配电容在零下20度漂移后同样信号强度下发射电流增加了约2毫安重传率也明显上升。所以射频匹配电路里我坚持只用C0G/NP0电容贵一点但值。2.3 天线效率比发射功率更容易被忽视很多团队把射频功耗等同于改发射功率等级却忽略了天线效率才是最值得抠的地方。设一个简单场景某模块在0dBm发射功率下PA电流是13毫安天线效率50%时实际对外辐射的等效功率大约是-3dBm如果把天线效率做到70%同样0dBm传导功率下对外辐射变成-1.5dBm效果相当于白赚了1.5dB链路预算。反过来如果天线效率只有30%辐射功率就变成-5.2dBm为了找回这2.2dB你可能要把发射功率从0dBm调到4dBm以上PA电流跟着往上跳。我在设计阶段就养成了一个习惯不光看传导功率指标还要看整机天线效率。天线周围有没有金属件、结构件介电常数多少、净空区是否被PCB铺铜侵占都会影响效率。用网络分析仪看S11只是第一步更靠谱的是在暗室里测整机效率或者至少在近场用标准天线做对比测试。天线效率差的设备还有一个隐藏代价接收灵敏度也差。灵敏度差主机收不到包从机就得重发重发又拉高平均电流。所以很多设备功耗高的根源不在软件配置而在天线周围那一小片PCB的物理设计。3. 协议栈与固件配置同样的芯片能差出10倍电流硬件底子定好之后BLE协议栈的配置就是最大的功耗变量。同一颗SoC、同一块板子广播间隔从20毫秒改成1秒平均电流能差出一个数量级。连接参数调得好不好又能让设备在同样的工作内容下差出几倍电流。这一块不需要改硬件是所有项目里性价比最高的优化点。但协议配置没有万能最优参数它永远是在功耗、实时性、可靠性之间做取舍。下面把几个关键旋钮逐个拆开讲。3.1 广播间隔的固定开销BLE广播不是只发一个包就结束每个广播事件里设备会在三个广播信道上依次发送还要留出接收扫描请求或连接请求的窗口。这意味着每个广播事件都有一个固定开销射频前端打开、锁相环稳定、按事件收发、再关上。这个开销通常持续1到3毫秒期间电流是毫安级的。如果广播间隔是100毫秒每个事件2毫秒、事件期间10毫安那么广播带来的平均电流大约是10mA × 2ms ÷ 100ms 200微安。把间隔改成1秒同样的事件平均电流直接降到20微安。这是10倍的差距。所以对于不要求被秒发现的应用广播间隔尽量拉长到1秒以上。对于需要快速配网的产品可以做成启动后先用短间隔广播30秒然后再切到长间隔而不是一直用短间隔烧电。另一个容易被忽略的是可连接广播与不可连接定向广播的区别。可连接广播会在每个事件后打开一小段接收窗口等连接请求可扫描广播还会额外接收扫描请求并回复扫描响应。这些额外的射频接收和发送都会增加事件时长。如果设备只需要单向上报而且不需要被扫描就选择最简的广播类型把事件窗口压到最短。3.2 连接间隔与Slave Latency是一把双刃剑建立连接之后从机每次都要在连接事件里醒来接收主机的包、回复自己的数据。连接间隔越短设备越勤快功耗越高间隔越长数据延迟越大。折中的经典工具是Slave Latency允许从机跳过若干个连接事件只在第N个事件才真正醒来。举个例子连接间隔30毫秒Slave Latency设为0从机每30毫秒醒来一次一个连接事件按3毫秒算事件期间电流10毫安平均电流约1毫安——这已经很高了。如果把Slave Latency调成9从机可以每300毫秒才醒一次平均电流降到约100微安省了一个数量级但主机发来的数据要被延迟到下一个有效事件才能收到。对于上报型传感器这个延迟完全可接受对于实时控制类设备就不行。这里要提醒一句连接参数是由主机发起请求的从机可以建议但最后拍板的是主机。很多手机APP在建立连接时用默认的快速参数从机只能接受。如果产品是和自研网关配合记得在网关侧把连接参数设计好如果是要兼容别人的主机可以配置从机请求更新连接参数但不是所有主机都会理你。3.3 外设往往比射频更耗电传感器与Flash的功耗画像我见过太多团队死磕广播间隔和发射功率却忽视了板上传感器和Flash才是真正的电老虎。很多数字传感器标称工作电流1毫安但如果你让它一直上电、一直测量它比BLE射频还费电。正确做法是用一个GPIO当开关给传感器单独供电。只在采样前的10毫秒内上电采完立刻断电。这个操作可以把传感器的平均电流从几毫安降到几微安。Flash写入更是典型的毫安级短脉冲。一次页擦除加写入可能要消耗10到20毫安持续几到几十毫秒。如果每一条日志都立刻写Flash平均电流会被拉得很高。我通常把数据先缓存在RAM里攒够一整页再一次性写入写完后立即把Flash切到深度掉电模式。这个看似简单的改动经常能省下几十微安的平均电流。还有一类坑是I2C上拉电阻。传感器断电后如果I2C上拉电阻还挂在VCC上上拉电阻到传感器引脚之间可能形成漏电路径电流虽然只有几微安但在睡眠状态下占比不小。设计时我倾向于把传感器电源控制和I2C上拉一起考虑要么上拉电阻也受同一个GPIO控制要么确保传感器在断电时引脚处于高阻态。4. 自有制造兜底产线校准、一致性与功耗筛选我在文章开头说过研发样机功耗低不算本事量产一百台都低才算。蓝牙模块的功耗优化离开了制造环节的兜底就是一座随时可能塌的沙塔。传统的购买公版模块方案你能做的就是选一个宣称低功耗的模块至于模块里的校准参数、天线匹配状态、物料批次一致性你全都控制不了。而自有制造的最大优势就是能在产线上用自己的测试体系把每一台设备的功耗和射频参数都兜住。这一章讲产线上实际怎么落地。4.1 研发样品能跑不代表产线每台都能跑我第一次做量产功耗抽检时发现一个很扎心的现象研发阶段的十台工程样机待机电流都在1.5微安左右非常漂亮。到了小批量试产待机电流的分布拉得很开有三分之一的板子超过3微安个别甚至到8微安。逐台排查下来原因五花八门有的板子在清洗后助焊剂残留导致微短路有的电容来料批次绝缘电阻偏低有的SoC内部LDO配置在烧录时被意外改过还有的板子GPIO悬空引脚在程序里没配成输入下拉导致漏电。这些问题的共同点是什么都不是设计上的致命错误而是制造过程中必然出现的随机波动。没有产线测试兜底这些小毛病就会变成用户的续航投诉。所以我在产线上坚持做整机功耗筛选而不是只在研发阶段测一台样机。4.2 产测项目怎么设计才能兜住功耗产线测试不可能像实验室那样精细但有几道测试是必须加的缺一不可。首先是烧录后的静态电流抽测。整机烧录完成后不进老化先在功耗分析仪上测一遍睡眠电流。这道测试能发现大部分漏电和配置问题。标准可以定在产品平均值的上限比如目标3微安以内超过的直接返修。千万别小看这一步一台多3微安的设备在220毫安时电池下会少活一年多。其次是射频校准。每一台设备都要做发射功率校准和频偏校准。PA的增益在不同芯片之间本来就存在离散温度也会影响频率精度。通过生产校准把每台设备的功率和频偏调到目标范围内既能保证通信质量也能避免为了凑合弱天线而被迫提高发射功率这种隐性功耗浪费。最后是高低温抽样。我通常会在每批产品里抽几台放到-20度和55度下测待机电流和发射功率看有没有温度敏感的物料混进来。这个测试不用全检但能提前预警来料批次问题。这里多说一句产测数据一定要带序列号存数据库。后面售后如果出现某批设备功耗异常能直接回溯到产线数据判断是批次物料问题还是测试设备漂移。4.3 天线匹配一致性射频功耗的制造变量天线匹配是无线产品里制造一致性最脆弱的一环。PCB板材的介电常数有公差电容电感有精度结构件和电池靠近天线的位置有装配误差这些都会让天线的谐振频率发生偏移。同样的匹配网络不同供应商的同一规格电容在2.4GHz下的表现可能差得远。我们在一个项目里遇到过贴片电容换了一个供应商标称值都是1pF但实际在2.4GHz下的等效串联电阻不一样匹配损耗多了将近0.5dB。0.5dB听起来不大但如果你的产品对续航极其敏感这就是白白多耗的电流。所以射频匹配电路在设计阶段就要预留调焊盘典型做法是π型网络保留串联和并联电容位置产线调试时可以通过更换元件把阻抗调回目标。如果产能和成本允许射频部分每台都做校准是最好的。不能每台校准的话至少每批抽取前几台用网络分析仪看S11或者直接测整机灵敏度。结构件的影响也要提前验证。很多产品塞进外壳之后天线谐振频率会偏几十兆赫辐射效率和接收灵敏度双双下降。我遇到过最夸张的一次外壳里有一根金属加强筋正好压在天线净空区上方整机灵敏度掉了5dB设备为了维持连接不断重传平均电流翻了一倍。这种问题在研发阶段不用整机做一次射频测试根本发现不了。5. 一次实测复盘平均电流从32微安降到8.7微安的完整过程前面讲了一堆原则这一章用一个我最近跟进的模拟项目——某款BLE温湿度记录仪——把排查和优化流程完整走一遍。这个项目最初的平均电流是32微安目标是压到10微安以下电池是一颗240毫安时的锂亚电池客户期望续航两年以上。按32微安算240毫安时的理论续航约是8500小时不到一年。所以这个问题不解决产品连交付门槛都过不去。5.1 电流波形上的毛刺一顿定位排查拿到样机后我没有急着改代码而是先在功耗分析仪上挂了24小时。电流波形显示大部分时间设备确实在深度睡眠底电流约3微安很干净。但每隔30秒就会出现一个持续约20毫秒、电流平均8毫安的尖峰尖峰里还套着两个小峰。第一个怀疑对象是温湿度传感器。看代码传感器每30秒唤醒一次模块上电后要等待稳定然后连续做两次测量再通过I2C读取整个过程大约15毫秒。我把传感器供电引脚用飞线断开波形上的第一段尖峰消失了坐实了传感器是第一个罪魁祸首。第二个小峰在传感器数据读取之后出现高度更高、持续时间更短。我顺着代码查发现每次采样完成后程序会把一条带时间戳的记录写入外部Flash。Flash擦写就是那个更高更短的第二段尖峰。到这里两个元凶都定位了。5.2 每一项优化各自贡献了多少微安定位之后我做了几个硬件和固件改动每改一步都在功耗分析仪上重新测至少一小时记录平均电流的变化。第一项传感器供电改GPIO控制。原来传感器始终由主电源供电现在改成采样前10毫秒才开启采完立刻关闭同时把I2C总线上拉电阻也改由同一GPIO控制防止断电漏电。这一项优化后平均电流降了约9微安。第二项Flash写入合并。原来每30秒写一条12字节记录Flash擦写一次耗电很大。我改成在RAM里攒够16条再一次性写入并且只在整页写入时消耗一次擦写电流。这一项降了约8微安。第三项广播和连接参数调整。这个产品平时是被网关主动连接的原来的连接间隔是30毫秒Latency为0。我们和网关端协商把运行时的连接间隔改成60毫秒Slave Latency设为4数据上报改为事件触发不要求秒级实时。这一项又降了约5微安。第四项射频匹配微调。在暗室对比测试时发现有一批板子在0dBm下的实际辐射效率比研发阶段低1.8dB原因是外壳结构件离天线太近。我们在匹配网络里调整了一颗并联电容把失配拉回来同时把产线校准的目标从0dBm调整到0.5dBm保证整机等效辐射功率不降。这一项没有直接让平均电流下降但它避免了重传率上升带来的隐性电流上升。在重传率从8%降到2%之后平均电流又降了约1微安。做完这四步平均电流落在8.7微安240毫安时的电池理论续航约2.7年达到了客户的预期。5.3 这套排查流程你可以直接抄走复盘下来真正有价值的不是那几个参数而是排查的顺序第一先看波形再动手改。没有24小时的电流曲线你连问题出在哪都不知道。很多工程师上来就调广播间隔属于打地鼠。第二按硬件漏电、外设功耗、射频功耗、协议功耗的顺序挨个排除。硬件问题不解决后面改协议全是白费。第三每次只改一个变量改完至少测一个完整周期。同一个周期内同时改三个地方你永远不会知道哪个改动真正有效。第四把产线抽测数据拉出来看分布。如果只盯着研发样机你永远不知道批量制造里的功耗方差有多大。这台记录仪在产线上后来加了一道睡眠电流全检超过12微安的板子直接隔离那些板子主要是传感器上电时序和电容漏电问题修完之后整批平均电流稳定在9微安以内。6. 边界在哪功耗优化不是无脑压低所有参数做了几年低功耗产品有个体会越来越深功耗优化做过头比不做更危险。低功耗是一个系统约束不是唯一目标。为了省几个微安把可靠性和通信余量全部牺牲掉最终会在售后数据上付出更大的代价。这一章聊聊我理解的边界。6.1 射频功率过低反而会让电池死得更快很多入门工程师一看发射电流随发射功率上升就想把TX Power调到最低档觉得这样一定省电。这在实验室里看单次发射确实省了但在真实环境里不一定。链路余量不足数据包在远一点的地方就解不出来设备于是不断重传。重传一次射频事件就多一次平均电流反而上去了。我们实测过某个标签设备把发射功率从0dBm降到-8dBm单次发射电流降了约3毫安但在15米距离上的重传率从2%涨到20%以上整机平均电流反而从12微安涨到18微安。你说这是省了还是费了我的经验是先根据产品最远通信距离和路径损耗算链路预算留出至少6到8dB的余量再定最低发射功率。不要为了省电牺牲掉最基本的通信可靠度。接收窗口也是一样的道理。Slave Latency调太大、接收窗口压太窄主机发的包经常错过就会触发重传机制。重传的电流开销远大于你省下来的那点接收电流。协议参数的设计要基于数据到达率和延迟要求来定而不是单纯追求数字好看。6.2 电池自身的脾气比你想的多最后说一下电池这个被动的耗电参与方。纽扣电池和软包锂电池的可用容量和放电电流强相关。CR2032在微安级负载下能放出220毫安时但在20毫安脉冲负载下实际可用容量可能只剩60%到70%而且内阻会造成明显的电压跌落。如果设备的事件峰值电流太高容量再大也没用因为电压在脉冲期间就塌了。我见过一个项目把电池从CR2032换成同尺寸的锂锰电池容量差不多但脉冲负载能力好很多设备不再出现射频事件期间复位的情况。这提醒我做低功耗设计时一定要把电池的脉冲放电曲线拉出来看不能在平均电流的数字上自嗨。温度对电池的影响同样被严重低估。锂亚电池在低温下电压平台会下降内阻会增大设备低温通信距离变短、功耗升高经常被误判为射频问题。我们后来在低温测试规范里明确规定-20度环境下的待机电流测试必须用在该温度下平衡过的电池否则测出来的数据会误导整个优化方向。6.3 我保留的一个习惯给功耗预算留负数裕量聊到这儿我想把最后一个习惯分享出来功耗预算表里我不光算平均值还会算最差情况和期望情况两个版本并且用最差情况来定电池容量和保质期。最差情况包括睡眠电流取产线分布的95分位、射频事件重传率按满载场景估算、传感器每次转换时间取上限、电池容量按数据手册最小值再打八折。算完如果还能满足续航目标这个产品才有底气说自己在极端场景下不至于翻车。如果算下来最差情况超标我会优先回到制造端找答案是不是待机电流的分布太宽是不是天线效率的一致性太差通过产线筛选把分布收窄比在固件里拼命压参数要靠谱得多。自有的制造能力在这里就是最后一道保险你有能力校准、筛选、返修才有资格对客户负责任。这几年做下来我的体会是蓝牙模块功耗优化从来不是某一个工程师、某一份代码、某一颗芯片的独角戏而是硬件设计、协议栈配置、制造测试和电池选型共同配合的结果。一个产品能不能把标称续航兑现给用户关键看你在研发阶段有没有把制造端的不确定性提前纳入设计并在产线上真正兜住它。
