蓝牙模块的功耗问题几乎是每个做便携式蓝牙产品的硬件工程师都会撞上的墙。尤其是当产品定义里写着“纽扣电池供电、续航半年以上”的时候你会发现选型阶段看不上的那零点几毫安到了量产阶段就是压死项目的最后一根稻草。我前后做过几款低功耗蓝牙标签和传感器节点从最初迷信大厂通用模块到后来转向自有制造方案做能效兜底中间踩的坑足够写一本小册子。这篇内容就把这套“功耗优化加自有制造兜底”的思路完整拆开从为什么通用模块会翻车到怎么在自有方案里把每一微安抠出来再到实测排查的完整流程尽量讲透。适合正在做低功耗蓝牙产品、被续航指标卡住、或者正在犹豫要不要走自研模块路线的硬件和固件工程师参考小白也能顺着思路看懂每一步在干什么。1. 为什么通用蓝牙模块在低功耗场景下会翻车1.1 通用模块的功耗账本其实很难看很多人第一次做低功耗蓝牙产品思路很直接找一个出货量大、资料齐全的通用模块 datasheet 上写着休眠电流零点几微安广播电流几毫安看起来完全够用。但真正把模块焊到板子上、跑起完整固件之后实测待机电流往往是手册值的五到十倍。这不是模块厂商虚标而是通用模块的设计目标本来就不是极致低功耗而是“通用、好上手、认证齐全”。通用模块为了兼容各种应用场景内部通常集成了不少“冗余”电路LDO 稳压、电平转换、外部晶振的驱动电路、甚至一些默认开启的调试接口。这些电路在单独看的时候功耗都不大但叠加起来再加上模块出厂固件里默认打开的各种广播间隔、连接参数、外设时钟整体静态功耗就上去了。我实测过一款市面上很常见的模块手册标称休眠 1.2 微安实际在只保留广播、没有连接的状态下整板电流稳定在 80 微安左右差了将近七十倍。这里的关键在于通用模块的功耗是“整机功耗”而不是“芯片功耗”。芯片本身的低功耗能力可能确实很强但模块作为一个成品把芯片、外围、固件打包在一起之后你能控制的只有固件层面的一小部分硬件层面的漏电、稳压损耗、上拉电阻这些你基本动不了。1.2 功耗失控的三个典型来源把通用模块的功耗拆开看失控主要来自三个地方。第一个是稳压与电源路径损耗。很多模块内部用的是低压差线性稳压器静态电流本身就有几微安到几十微安而且当输入电压和输出电压差得比较多的时候这部分损耗是持续存在的跟芯片睡不睡觉没关系。第二个是默认外设与引脚状态。模块出厂固件往往把一些没用到的外设时钟开着或者把某些 GPIO 默认拉高如果这些引脚外面接了上拉电阻就会形成持续的漏电流。第三个是广播与连接参数过于保守。为了兼容性通用模块默认的广播间隔通常很短比如 20 毫秒到 100 毫秒广播本身是射频发射电流是毫安级的广播越频繁平均功耗越高。这三个来源里第一个和第二个是硬件层面的通用模块用户基本无能为力第三个是固件层面的可以调但调整空间受限于模块厂商开放的接口。所以当你发现续航怎么都达不到指标的时候往往不是你的固件写得不好而是模块本身的底子就决定了上限。1.3 自有制造兜底能效的核心逻辑所谓“自有制造兜底能效”说白了就是不再依赖通用模块的封装而是自己选芯片、自己画板、自己写固件把功耗控制的每一个环节都握在自己手里。这样做的好处是你可以针对自己的应用场景做极致的裁剪不需要的外设全部关掉不需要的引脚全部配置成最低功耗状态电源路径用最省电的方案广播和连接参数按实际需求调到最稀疏。但自有制造不是没有代价的。你需要自己处理射频匹配、天线设计、认证测试还要自己承担固件开发的全部工作量。所以这套方案并不是所有项目都值得上它更适合那些对功耗有硬性指标、出货量足够摊薄研发成本、并且团队有射频和低功耗设计经验的情况。如果只是做个demo或者小批量通用模块加固件优化可能更划算。我下面讲的这套方法核心是把“自有制造”当成一个能效兜底的手段而不是盲目追求自研。2. 自有方案的核心器件选型与电源架构设计2.1 芯片选型先看休眠电流再看外设可控性选芯片的时候很多人第一眼看的是射频性能和协议栈支持但对于低功耗场景第一眼应该看的是休眠电流和外设时钟的可控性。休眠电流决定了你产品在待机状态下的功耗下限这个值通常是芯片厂商在特定条件下测出来的比如所有外设关闭、RAM 保持、RTC 运行。你要关注的是这个条件下电流是多少以及从休眠唤醒到广播的时间有多长。外设可控性同样重要。有些芯片虽然休眠电流很低但某些外设的时钟在低功耗模式下无法完全关闭或者关闭之后唤醒需要重新初始化导致你不得不在休眠时保留一部分电路。我一般会优先选那些能把每个外设独立关时钟、并且 GPIO 在休眠时能保持确定电平的芯片。另外芯片的唤醒源要足够灵活最好能支持 GPIO 唤醒、定时器唤醒、比较器唤醒等多种方式这样你可以根据实际场景选择最省电的唤醒策略。2.2 电源架构LDO 还是 DC-DC账要算清楚电源架构的选择直接决定了静态功耗的大头。LDO 的优点是简单、噪声低、外围少缺点是效率低尤其是输入输出电压差大的时候多余的功率全部变成热。DC-DC 效率高但开关噪声可能影响射频性能而且轻载效率需要特别关注。对于纽扣电池供电的场景我一般会算一笔账。假设用 CR2032标称容量 220 毫安时标称电压 3 伏。如果系统平均电流要控制在 5 微安以内才能撑一年那么电源部分的静态电流就必须压到 1 微安以下。这个级别的 LDO 不是没有但价格和供货都不太友好。DC-DC 在轻载下如果能把静态电流做到几百纳安效率优势就很明显了。但要注意DC-DC 的开关频率如果落在射频接收频段附近可能会干扰接收灵敏度所以布局和屏蔽要做足。我实际项目里用过的一种折中方案是主电源路径用超低静态电流的 DC-DC然后在射频部分单独用一个小 LDO 做二次稳压保证射频供电干净。这样整体静态电流能控制在 2 微安左右同时射频性能不受影响。这个方案的成本比纯 LDO 高一些但比纯 DC-DC 加复杂滤波要简单。2.3 外围电路的漏电排查清单自有方案的一个好处是你可以完全控制外围电路。但这也意味着任何一处漏电都是你自己的责任。我整理了一份外围漏电的排查清单每次画完板子都会对着过一遍。排查项常见问题处理方式上拉/下拉电阻阻值偏小休眠时形成持续漏电改用 1 兆欧以上或直接去掉未使用引脚浮空导致输入级振荡漏电配置为输出低或带上拉的输入调试接口默认使能占用引脚和时钟量产固件中彻底关闭晶振电路负载电容偏大起振电流高按芯片手册选最小可用负载电容传感器供电常供电休眠时仍在耗电用 MOS 管做电源门控LED 指示灯限流电阻偏小或漏电流用高阻值或加门控这份清单看起来简单但每一条我都见过实际翻车的案例。尤其是未使用引脚的处理很多新手会直接不管结果芯片进入休眠后浮空引脚上的电平在中间值附近输入级电路就会持续振荡电流可能达到几十微安。3. 固件层面的功耗优化实操3.1 广播参数间隔、信道与发射功率的取舍广播是低功耗蓝牙设备在未连接状态下最大的功耗来源。广播的本质是射频发射每次广播都会在三个信道上依次发送数据包发射电流通常在几毫安到十几毫安持续时间几百微秒到几毫秒。所以平均功耗取决于广播间隔和每次广播的持续时间。广播间隔的选择要结合应用场景。如果是需要快速被发现的设备比如防丢器广播间隔可以短一些比如 100 毫秒到 300 毫秒。如果是周期性上报数据的传感器广播间隔可以拉长到 1 秒甚至几秒。我实测过把广播间隔从 100 毫秒拉到 1 秒平均电流能降一个数量级。发射功率也不是越大越好。很多场景下设备离接收端很近比如几米以内发射功率降到 0 分贝毫瓦甚至负 20 分贝毫瓦都够用。发射功率每降 3 分贝电流大约减半。所以如果你的应用场景允许把发射功率调到刚好够用的水平省下来的电非常可观。信道选择也有讲究。低功耗蓝牙广播默认在 37、38、39 三个信道上轮发。如果某个信道环境特别拥挤重传次数增加功耗也会上去。在可控的环境里可以只在一个信道上广播但这样会牺牲被发现的速度和可靠性。我一般会保留三个信道但把广播数据包做到最短减少每次广播的持续时间。3.2 连接参数让从机说了算连接状态下的功耗优化核心是连接参数。低功耗蓝牙的连接参数包括连接间隔、从机延迟、监督超时。连接间隔决定了主从机多久通信一次从机延迟允许从机跳过若干次连接事件而不响应监督超时则是判断连接丢失的时间。在低功耗场景下从机应该主动向主机请求有利于省电的连接参数。比如连接间隔可以设到 1 秒甚至更长从机延迟设到 4 到 8 次这样从机平均几秒才需要唤醒一次。但要注意连接间隔太长会影响数据传输的实时性从机延迟太大则可能导致主机认为从机失联。我一般会根据数据上报频率来反推如果传感器每 10 秒上报一次数据连接间隔设 1 秒、从机延迟设 9 次这样从机每 10 秒才真正响应一次连接事件中间九次都可以跳过。这里有个坑不是所有主机都愿意接受从机请求的连接参数。有些手机或网关会拒绝或者协商到一个折中值。所以固件里要做好参数协商失败的兜底逻辑比如先请求一个激进省电的参数如果被拒绝再请求一个温和一点的。3.3 休眠策略什么时候睡睡多深休眠策略的核心是“能睡就睡睡就睡到最深”。芯片通常有多个低功耗模式从浅睡到深睡功耗依次降低但唤醒时间和状态保持能力也依次变差。选择哪个模式取决于你下次唤醒需要多快、需要保留多少状态。我的经验是如果下次唤醒是定时器触发的而且不需要保留 RAM 数据那就直接进最深休眠唤醒后重新初始化。如果需要在休眠期间保持连接那就只能进浅睡因为射频和协议栈的状态需要保持。如果只是等待外部事件比如按键或传感器中断那可以用中间档的休眠GPIO 唤醒RAM 保持。休眠时还有一个细节把不需要的外设时钟全部关掉把 GPIO 配置成确定电平把射频前端也关掉。有些芯片的射频前端在休眠时如果不断电会有漏电。这个要在芯片手册里确认必要时用外部 MOS 管做射频前端的电源门控。4. 实测与排查把每一微安都找出来4.1 功耗测量工具与测量方法功耗测量最忌讳的是用万用表直接串在电源里测。万用表的采样率太低根本抓不到广播瞬间的电流脉冲而且万用表的内阻会引入压降影响芯片正常工作。正确的做法是用专门的功耗分析仪或者用高采样率的电流探头配合示波器。如果没有专业设备可以用一个简单的方法在电源路径上串一个小阻值的采样电阻比如 10 欧姆然后用示波器测电阻两端的电压。这样可以看到电流的实时波形包括广播脉冲和休眠电流。采样电阻的阻值要选得合适太大影响供电太小信号太弱。10 欧姆在微安级电流下产生几十微伏的压降对 3 伏系统来说可以忽略。测量的时候要注意区分不同状态的电流休眠电流、广播瞬间电流、广播平均电流、连接状态电流。每个状态的测量条件要记录清楚比如广播间隔、发射功率、供电电压。我一般会做一个表格把不同配置下的电流都记下来方便对比。4.2 常见功耗异常与排查思路功耗异常的表现通常是实测电流远高于预期。排查的时候我一般按“先断后连”的思路先把所有能断的外设都断掉看基础电流是多少然后一个一个接回来看哪个外设接上之后电流跳变。异常现象可能原因排查方法休眠电流偏高GPIO 浮空、外设时钟未关逐个配置 GPIO关外设时钟广播电流偏高发射功率过大、广播包过长降功率缩短广播数据连接后电流偏高连接间隔太短、从机延迟为 0请求更省电的连接参数电流随时间上升某处漏电随温度或电压变化检查电容漏电、焊接残留唤醒后电流不降唤醒后未重新进入休眠检查固件休眠逻辑排查的时候要有耐心一次只改一个变量改完测一次记录结果。我见过有人一次改好几个地方结果电流降了也不知道是哪个改动起的作用下次遇到同样问题还是不会。4.3 从实测数据反推优化方向实测数据最大的价值是告诉你优化方向在哪里。比如你测出来休眠电流是 5 微安广播平均电流是 50 微安那总平均电流就是两者按时间加权。如果广播占空比是 1%那广播贡献 0.5 微安休眠贡献 5 微安总电流 5.5 微安。这时候你要优化的重点显然是休眠电流而不是广播。反过来如果休眠电流只有 1 微安但广播平均电流 200 微安占空比 5%那广播贡献 10 微安休眠贡献 1 微安总电流 11 微安。这时候优化广播参数的效果就明显得多。所以每次优化之前先算清楚各个部分的贡献占比把力气花在占比最大的地方。5. 自有制造兜底能效的边界与取舍5.1 什么情况下值得走自有方案自有方案不是万能药它有明确的适用边界。我总结下来以下几种情况值得考虑自有制造第一功耗指标是产品的核心卖点通用模块怎么调都达不到第二出货量足够大能摊薄射频认证和研发的成本第三团队有射频设计和低功耗固件开发的经验或者愿意投入时间学习第四产品形态对尺寸有严格要求通用模块的封装太大放不进去。反过来如果只是做个原型验证或者出货量只有几百几千那通用模块加固件优化是更务实的选择。通用模块的认证是现成的射频性能有保证你只需要专注在应用层和固件优化上。等产品验证成功、出货量上来了再考虑切换到自有方案降本增效。5.2 自有方案的隐性成本自有方案的隐性成本往往被低估。除了芯片和外围的物料成本你还要承担射频匹配调试、天线设计、认证测试、产线校准等一系列工作。射频匹配调试需要网络分析仪和暗室认证测试需要送样到认证机构产线校准需要设计校准工装和流程。这些成本加起来可能比物料成本的节省还要高。还有一个隐性成本是时间。通用模块拿过来就能用自有方案从画板到量产中间可能要经历两三版改板每版改板加上调试和认证周期可能多出几个月。如果产品上市时间很紧这个时间成本可能比物料成本更致命。5.3 混合策略通用模块验证自有方案量产我实际项目里用得最多的是一种混合策略前期用通用模块做功能验证和固件开发把应用逻辑、功耗策略、连接参数都调好等产品定义冻结、出货量明确之后再切换到自有方案把通用模块上验证过的固件移植过来硬件上做极致的功耗裁剪。这样既能快速验证产品概念又能在量产阶段把功耗和成本都压下来。移植的时候要注意通用模块的固件往往依赖模块厂商的 SDK 和库移植到自有芯片上可能需要重写一部分驱动和协议栈适配层。所以前期做固件的时候尽量把应用逻辑和硬件相关的部分解耦用抽象层隔开这样移植的工作量会小很多。6. 几个容易忽略的细节与实操心得6.1 电池自放电与寿命估算很多人算续航的时候只算系统功耗忘了电池的自放电。纽扣电池的自放电率通常在每年百分之一到百分之三看起来不大但如果你的系统功耗已经压到很低自放电的占比就不可忽略了。比如系统平均电流 2 微安一年耗电 17.5 毫安时而 CR2032 容量 220 毫安时自放电按百分之二算就是 4.4 毫安时占比超过百分之二十。所以做寿命估算的时候要把自放电加进去而且要考虑温度对自放电的影响。高温环境下自放电会加快如果产品用在户外或者靠近热源的地方寿命估算要留足余量。我一般会在理论计算的基础上打七折作为实际续航的保守估计。6.2 温度对功耗的影响温度对功耗的影响来自两个方面芯片的漏电流随温度升高而增大电池的内阻和容量随温度变化。芯片漏电流在常温下可能只有几百纳安到了 85 度可能变成几微安翻了几十倍。所以如果你的产品有高温工作场景休眠电流的指标要按最高工作温度来定。电池方面纽扣电池在低温下内阻增大放电能力下降可能导致系统在低温下无法正常启动或射频发射失败。如果产品有低温场景要么选低温性能好的电池要么在固件里做低温降功率策略比如低温时降低发射功率保证能发出去。6.3 固件升级与功耗的平衡低功耗产品通常也需要固件升级能力而升级过程往往需要保持连接、接收数据、写 Flash这些都是耗电大户。如果升级频繁对续航的影响不可忽视。我的做法是把升级功能做成按需开启平时关闭需要升级的时候通过特定触发方式进入升级模式。升级模式下的功耗不做优化因为升级是偶发事件对整体续航影响很小。另外升级固件的存储要规划好。如果芯片的 Flash 空间紧张可能需要外挂 Flash而外挂 Flash 在休眠时如果不断电也会有漏电。所以外挂 Flash 的电源最好也做门控不用的时候彻底断电。6.4 产线测试中的功耗筛查量产阶段功耗筛查是保证一致性的关键。如果产线上不做功耗测试到了客户手里才发现个别产品功耗超标返修成本会很高。我一般会在产线测试工位加一个功耗测试项让产品进入休眠模式测静态电流超过阈值就判不合格。这个阈值怎么定要根据设计值和实测分布来定。比如设计休眠电流是 2 微安实测分布是 1.8 到 2.5 微安那阈值可以定在 3 微安留出一定余量。如果个别产品测出来 10 微安那肯定是焊接或者物料有问题直接挑出来分析。产线测试的另一个要点是测试条件要一致。供电电压、温度、测试时间都要固定否则测出来的数据没有可比性。我见过有的产线今天用 3 伏测明天用 3.3 伏测结果数据对不上排查了半天才发现是测试条件变了。7. 从项目实践看功耗优化的优先级7.1 先做减法再做优化功耗优化的第一原则是“先做减法”。很多功耗问题不是因为你没优化而是因为你做了太多不需要的事。比如一个温度传感器节点如果只需要每十分钟上报一次数据那就没必要保持连接广播上报完就休眠这样功耗最低。如果非要保持连接那连接间隔和从机延迟就要调到最省电的组合。减法还包括硬件层面的裁剪。不需要的外设全部去掉不需要的指示灯去掉不需要的调试接口在量产固件里关掉。每去掉一个器件就少一个漏电点少一份功耗预算。7.2 优化顺序从占比最大的部分下手做减法的同时要算清楚各部分功耗的占比。我一般会先测出休眠电流、广播平均电流、连接平均电流然后按实际工作的时间占比加权算出总平均电流。然后看哪个部分贡献最大优先优化哪个部分。比如一个设备休眠电流 3 微安广播平均电流 100 微安广播占空比百分之二连接平均电流 50 微安连接占空比百分之十。那休眠贡献 3 微安广播贡献 2 微安连接贡献 5 微安总电流 10 微安。这时候连接部分的贡献最大应该优先优化连接参数而不是去抠休眠电流那 3 微安。7.3 迭代验证每次只改一个变量功耗优化是一个迭代过程每次只改一个变量测一次记录一次。这样你才能知道每个改动的实际效果也才能在出问题的时候快速定位。我一般会做一个优化日志记录每次改动的配置、实测电流、以及改动前后的对比。这个日志在项目后期排查问题的时候非常有用。迭代的时候还要注意有些优化是相互影响的。比如你把广播间隔拉长功耗降了但被发现的时间也长了可能影响用户体验。所以每次优化都要评估对功能的影响不能只看功耗数字。8. 写在最后的几点个人体会做低功耗蓝牙产品这些年我最大的体会是功耗优化没有银弹只有一笔一笔算清楚的账。通用模块有它的价值自有方案也有它的边界关键是要根据项目实际情况做取舍。我见过太多项目在选型阶段就埋下了功耗的隐患后面怎么调都调不回来最后只能改产品定义或者换方案代价很大。自有制造兜底能效这套思路核心不是盲目自研而是把功耗控制的主动权握在自己手里。当你对每一个微安的去向都清清楚楚的时候你才能对产品的续航做出可靠的承诺。这个过程很磨人但当你看到实测电流从几百微安降到几微安续航从几周变成几年的时候那种成就感是实实在在的。最后分享一个小技巧如果你不确定某个外设或者某个配置对功耗的影响最直接的办法就是把它关掉测一次电流再打开测一次电流差值就是它的贡献。这个方法虽然笨但最可靠。我到现在还经常用这个办法来验证一些拿不准的配置。