蓝牙项目的功耗优化问得最多的就是广播间隔调多大、连接参数怎么配才能让一颗纽扣电池撑一年这个问题听起来基础真上手做会发现坑比想象中多。默认参数跑出来的设备可能两三个星期就没电把参数逐项调完再用同一颗电池硬是能跑出一年半以上的续航。这篇文章把BLE功耗的构成、广播和连接两种工作方式下的参数选择逻辑、以及电池容量估算方法完整讲一遍适合做低功耗传感器、beacon、可穿戴外设的软硬件工程师参考。1. 先说结论一年耗电预算就25μA工况决定一切1.1 一颗纽扣电池一年的平均电流预算先做一个简单的除法。常见CR2032标称容量220mAh一年是365天乘24小时等于8760小时220mAh除以8760小时约等于0.025mA也就是25μA。这个数就是整台设备的红线从MCU、传感器、蓝牙射频到任何一颗电阻的漏电全年平均电流必须控制在25μA以内才可能用CR2032撑一年。如果产品用的是两节AA电池可用容量大概2400到3000mAh预算能放宽到280到340μA如果是一颗3.7V锂聚合物电池500mAh预算大约是57μA。做功耗设计的第一步不是急着选芯片而是先把这个预算数字算出来。后面的广播间隔、连接参数、传感器采样频率全部围绕这个总数做取舍才不会出现参数调了半天续航还是不达标的尴尬。1.2 广播和连接是两种完全不同的功耗模型很多刚接触BLE的人把蓝牙功耗低理解成连上后功耗也低这是最大的误解。BLE低功耗的核心是尽量不工作一旦进入稳定连接无论有没有数据要发射频在每个连接事件都得起来收包这个功耗是持续存在的根本省不掉。广播则是按自己的节奏发完就睡功耗几乎完全由广播间隔决定。所以设计思路要分两条线。纯广播设备比如beacon、防丢器主要调广播间隔和发射功率连接型设备比如传感器上报、遥控器主要调连接间隔、从机延迟、超时时间以及连多久、什么时候断。实际产品里经常两条线混用平时深度睡眠需要上报时短暂广播、连接、传完立刻断开。判断方案是否合理核心看非工作时间的占空比能不能压到足够低。2. 蓝牙功耗的三个去向射频、唤醒、常驻2.1 一个广播事件和一个连接事件到底烧多少电先看射频事件本身。一次广播事件从射频打开到发完包关闭理想状态1ms左右实际加上协议栈开销、低频时钟校准、MCU从睡眠唤醒、晶振起振整个过程要1.2到3ms。事件期间电流不是恒定的TX脉冲瞬间可能冲到十几毫安但用示波器抓整个事件取平均按8到12mA估比较稳妥。一个连接事件也类似从机要提前开RX窗口等主机的包然后可能再回一个包整个窗口通常持续1.5到3.5ms事件期间电流同样在8到12mA量级。关键在于事件多久来一次连接间隔30ms、从机延迟为0时每秒要处理约33个事件从机延迟调到9事件变成每300ms一个每秒只要处理3个多一点功耗直接差一个数量级。从机延迟这个参数存在的意义就在这里。2.2 常驻电流和唤醒开销同样不能忽略射频只是冰山一角。睡眠时MCU和外围的常驻电流、协议栈定时器、低频时钟、GPIO上拉的漏电这些是24小时都在烧的。设计得好的睡眠电流能压到2到5μA不含外部传感器做得差的能到50μA以上单这一项就吃掉全年预算的一半甚至更多。常见的坑包括LDO静态电流太大、DCDC没使能、外部传感器供电脚一直挂着、UART的TX/RX引脚被外部设备拉高、复位电路上的电阻分压过大。只要有一个地方没处理干净前面的参数优化全部白做。唤醒开销的典型问题是高频晶振起振时间。用外部32MHz晶振的芯片从睡眠到可发射需要几百微秒到1到2ms只用内部RC振荡器会快一些但射频性能和稳定度稍差。如果设备每分钟唤醒一次、每次唤醒都要等晶振稳定这部分时间虽然短摊到全年也是一笔不小的开销。建议把唤醒-采集-连接-上报-睡眠整个过程做成时间线每段电流乘时间再求和除以周期才能得到真实的平均电流。3. 广播间隔待机功耗最大的调节旋钮3.1 估算公式和典型参考值广播功耗的快速估算公式很简单I_avg ≈ (I_adv_event × T_adv_event) / T_interval I_sleepI_adv_event是广播事件期间的平均电流按8到12mA估T_adv_event是事件时长按1.2到2.5ms估T_interval是广播间隔。以nRF52832在0dBm发射功率、使用DCDC的场景为例估算结果大致如下广播间隔事件占空比射频平均电流加睡眠3μA后合计CR2032续航估算20ms默认常用7.5%-12.5%900-1500μA约900-1500μA6-10天100ms1.2%-2.5%144-300μA约150-300μA1-2个月500ms0.24%-0.5%29-60μA约32-63μA4-7个月1000ms0.12%-0.25%14-30μA约17-33μA7个月-1.3年2000ms0.06%-0.125%7-15μA约10-18μA1.2-2.5年这个表是粗略估算具体数值每家芯片有差异但趋势一致广播间隔100ms是耗电较快的分界线到1s以上才能进入按年算续航的区间。如果产品是beacon用途用户手机扫描时希望尽快发现设备广播间隔不能太慢否则失配体验变差。这是典型的功耗与发现延迟的权衡没有绝对正确答案只能靠产品定义去定。3.2 可连接广播、不可连接广播和扫码响应广播包类型也直接影响功耗。不可连接广播事件只发一个ADV包就结束可连接广播还要监听一个短暂窗口看有没有扫描请求进来有的话还要回扫描响应。监听窗口意味着即使没人扫描每个广播事件也要多开一段RX功耗因此多出30%到80%。所以和手机配对完成后还一直以可连接模式广播是很浪费的配完对要么直接进连接要么切到不可连接或完全停止广播。另一个经验扫描响应数据能不填就不填。它不会带来额外射频事件但会在收到扫描请求时触发一次额外的TX属于随机事件单独看平均功耗影响不大。可一旦设备处在人流密集区域被频繁扫描这部分功耗会明显上升。如果产品对被发现速度不敏感建议把广播包里的设备信息精简到必要字段减少每次广播的空中时间这也是优化手段。4. 连接参数链路里藏着的大头4.1 连接间隔、从机延迟、超时时间的含义和约束连接间隔是主机每隔多久发起一次连接事件单位1.25ms合法范围7.5ms到4s。从机延迟是从机允许跳过的连续连接事件数范围0到499。监督超时是超过多久没收到主机包就判定链路断开范围100ms到32s且必须满足超时时间大于1加从机延迟乘2再乘连接间隔这是协议栈强制的约束。主机和从机都能发起连接参数更新请求但最终由主机决定。iOS对连接参数有比较硬性的偏好很多老项目总结的经验是连接间隔建议落在30到50ms区间从机延迟建议0到4Android各厂商差别很大。设计从机时最好在GAP服务里填好Preferred Connection Parameters并把主动请求参数更新的频率控制在合理范围频繁发起更新请求容易被手机直接忽略尤其是iOS。4.2 常用参数模板和实测电流前提是连接期间没有大量数据要传只做周期性传感器上报。下面几组组合是实际项目里验证过的场景连接间隔从机延迟超时时间有效事件间隔链路平均电流参考高吞吐透传/固件升级7.5-15ms02-3s7.5-15ms400-900μA常规定时上报分钟级30ms3-54-5s120-180ms60-150μA低频小数据上报50ms95s500ms25-60μA极低功耗保活100ms108s1100ms10-25μA表中链路平均电流只是维持连接的射频开销不含业务数据处理。注意最后一行连接间隔100ms、从机延迟10时约束条件是1加10乘2乘100等于2200ms8s的超时时间满足要求。这类低速保活连接已经接近广播功耗的量级适合需要随时被手机下发的设备但单靠这个仍然很难把CR2032撑满一年必须结合定时深度睡眠、醒来才连接的策略。4.3 按数据量反推最小连接时间连接型设备最优策略不是一直连着而是用最快速度传完、立刻断开。比如一个温湿度传感器每5分钟上报一次每次数据量20字节。用连接间隔30ms、从机延迟0主机连上来后从机在2到3个连接事件内就能把数据发完整个连接过程只需要100到150ms随后从机主动断开。算下来每次消耗约10mA乘0.15s等于1.5mAs折算到5分钟周期只有0.3μA平均电流几乎可以忽略。这就是突发传输加深度睡眠模式。关键点是广播阶段要严格控制时长设备唤醒后以较短广播间隔20到30ms广播但设一个2到3秒的超时手机扫描到并连接进来就立即停止广播进入连接流程超时没连上就果断回去睡等下一个周期再试。很多项目死在唤醒后忘了关广播或者断开后广播还开着导致设备在等待连接和重连期间以高占空比广播功耗直接翻好几倍。5. 电池容量怎么配从平均电流倒推电池规格5.1 建立功耗模型时间线加分段积分正确的电池容量估算不是拿一个mA数直接乘时间而是把设备一次运行周期拆成状态时间线。还是以5分钟上报一次的温湿度传感器为例把一个周期拆成四段深度睡眠 3μA × 297.5s 892.5μA·s 唤醒采集 5mA × 0.05s 250μA·s 广播等待 9mA × 0.2s 1800μA·s 连接传输 10mA × 0.12s 1200μA·s -------------------------------------- 合计 4142.5μA·s四段相加4142.5μA·s除以周期300s平均电流约13.8μA。这个数字低于前面算的25μA红线理论上用CR2032撑一年半是可能的。如果某个环节的时长翻倍比如广播等待从0.2s变成0.4s平均电流会跳到19.8μA左右还在预算内如果广播等待变成2s平均电流直接到73μA一年就泡汤了。把时间线摆出来哪个环节是短板一目了然。5.2 电池的降额和自放电标称容量和实际可用容量不是一回事。CR2032在几十μA的微电流放电下能接近标称容量但设备每次射频发射是毫安级脉冲电池内阻会造成输出电压瞬间跌落跌到MCU最低工作电压以下就会复位。脉冲越猛、电池越旧、温度越低跌落越厉害。所以选电池时要留余量降额系数通常取0.7到0.9。此外纽扣电池自放电大约每年1%到2%库存放了两年的电池220mAh实际到手可能只剩210mAh左右。环境温度每降低10℃电池可用容量可能缩水10%到20%北方冬季室外场景要特别留意。5.3 不同电池方案的续航对比电池方案可用容量参考平均电流上限目标1年适合场景CR2032单节150-220mAh17-25μA低功耗beacon、传感器、防丢器CR2477单节800-1000mAh90-110μA需要稍大发射功率或更长续航AA碱性两节2000-2800mAh230-320μA网关、键盘、鼠标等外设3.7V锂电500mAh400-450mAh45-50μA可充电设备兼具体积和续航锂亚电池ER145052000mAh以上200μA以上工业表计、长期无人维护锂亚电池Li-SOCl2在工业领域很常见自放电极低、容量密度大但瞬时脉冲能力弱必须配合大电容使用。这类场景往往是一年一换甚至八年一换连接参数也必须按低占空比设计否则再大的容量也撑不住高频连接事件。6. 实测案例一个温湿度传感器从三周没电到预计两年6.1 原始设计的功耗拆解之前帮一个团队优化过一款温湿度传感器硬件是nRF52832加CR2032加SHT30软件最初由外包写的。现场反馈换上电池三周左右就没电。拿到样机用示波器一测问题非常典型设备上电后一直以20ms间隔做可连接广播从不上报也不进睡眠SHT30的供电脚直接接在电池上湿度测量周期设成1秒一次。按20ms广播间隔估算平均电流在1mA上下220mAh的CR2032最多撑十天上下现场说三周可能是电池批次容量差异或仓库温度偏高造成的偏差。不管怎么说这个方案完全不可用。本质上这个设计把BLE设备用成了永远在广播的玩具射频占空比高达10%以上什么电池都扛不住。先和产品确认真实使用场景设备摆在仓库里定时上报温湿度并不需要随时被发现。于是优化方向非常明确平时必须深度睡眠只在需要上报时短暂工作。6.2 参数调整和实测结果修改后的逻辑设备每5分钟唤醒一次读SHT30需要50ms随后切换为可连接广播间隔30ms持续2秒等待手机扫描连接手机连上后采用连接间隔30ms、从机延迟0、超时4s的参数从机在2到3个事件里写完温湿度数据主机主动断开断连后立即关闭广播、进入深度睡眠。为了降低广播阶段耗电发射功率从4dBm降到0dBm穿墙距离仍然满足仓库需求。实测各阶段的电流和时间深度睡眠3.2μA持续297.5s唤醒采集5mA持续50ms广播等待9.2mA持续200ms这是平均等待时间实际取决于手机扫描周期连接传输10mA持续120ms。代入分段积分公式平均电流约14μA。以CR2032实际可用容量200mAh、降额系数0.8计算理论续航约1.4年实测压降趋势也吻合。这个案例里最大的感悟很多项目的耗电问题根本不是参数微小调优能救的而是工作模式设计错了。把常驻广播加常连接改成深度睡眠加定时突发之后连接参数反而变得不那么敏感随便给一组合理值都能轻松达标。反过来工作模式不改光把广播间隔从20ms调到100ms续航只够从三周延长到两三个月产品照样没法用。7. 验证与调试不要被平均数骗了7.1 测量方式和工具选型万用表的直流电流挡测平均功耗只能粗看它看不到脉冲的幅度和时序。正确姿势是用示波器加低阻采样电阻测设备供电回路把波形抓下来分析每个阶段的电流和时间。采样电阻压降会给电池供电设备带来几十到几百mV的跌落所以电阻值宁小勿大或者用电流探头。更省事的方式是用Nordic的Power Profiler Kit这类专用功耗分析仪直接出电流曲线和平均电流调试效率高很多。测量时注意开发板上的调试器、LED、USB转串口都会耗电测低功耗必须脱离开发板的调试状态用纯模块或把调试接口相关外围全部断开。我见过太多睡眠电流显示50μA的案例最后查明是调试器还在跑。烧录完成后断开调试器、拔掉LED跳线帽、重新上电再测数据才有参考价值。7.2 常见假象和排查清单第一类假象是算出来30μA实测100μA多半是某个外设没彻底关掉。比如SHT30在测量模式下没关闭、加速度计还开着、flash芯片的CS引脚悬空导致漏电。排查方法是逐个外设断开供电每断开一个测一次睡眠电流很快能定位问题。第二类假象是睡眠电流没问题整机平均电流却偏高。这种情况通常问题出在频繁唤醒或高频定时器。用示波器长时基抓几分钟的电流波形看有没有不该出现的脉冲比如定时器跑成了1ms唤醒而不是1s唤醒或者协议栈的RTC回调把芯片频繁唤醒。第三类假象是换电池后前两周正常之后频繁复位。这往往是电池内阻变大或容量快耗尽时射频脉冲电压跌落触发掉电复位。排查方法是查复位原因寄存器确认是供电跌落的话在电池两端加大电容100μF或更大或者软件上降低发射功率、缩短广播窗口。这个坑在量产验证阶段特别常见提前在设计里留好大电容的位置能省很多事。