BLE功耗优化：广播间隔与连接参数怎么配？纽扣电池续航一年

蓝牙项目的功耗优化，问得最多的就是：广播间隔调多大、连接参数怎么配，才能让一颗纽扣电池撑一年？这个问题听起来基础，真上手做会发现坑比想象中多。默认参数跑出来的设备可能两三个星期就没电，把参数逐项调完再用同一颗电池，硬是能跑出一年半以上的续航。这篇文章把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_sleep

I_adv_event是广播事件期间的平均电流，按8到12mA估；T_adv_event是事件时长，按1.2到2.5ms估；T_interval是广播间隔。以nRF52832在0dBm发射功率、使用DCDC的场景为例，估算结果大致如下：

这个表是粗略估算，具体数值每家芯片有差异，但趋势一致：广播间隔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到4；Android各厂商差别很大。设计从机时，最好在GAP服务里填好Preferred Connection Parameters，并把主动请求参数更新的频率控制在合理范围，频繁发起更新请求容易被手机直接忽略，尤其是iOS。

4.2 常用参数模板和实测电流

前提是连接期间没有大量数据要传，只做周期性传感器上报。下面几组组合是实际项目里验证过的：

表中链路平均电流只是维持连接的射频开销，不含业务数据处理。注意最后一行，连接间隔100ms、从机延迟10时，约束条件是（1加10）乘2乘100等于2200ms，8s的超时时间满足要求。这类低速保活连接已经接近广播功耗的量级，适合需要随时被手机下发的设备，但单靠这个仍然很难把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 不同电池方案的续航对比

锂亚电池（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或更大，或者软件上降低发射功率、缩短广播窗口。这个坑在量产验证阶段特别常见，提前在设计里留好大电容的位置能省很多事。