4、功耗预算基础:功耗单位(mW/uW)、平均功耗与峰值功耗、电池供电与市电供电场景下的功耗预算差异

智能音箱的“低功耗唤醒”设计,本质上是在“永远在线”的体验承诺与“有限能源”的物理约束之间寻找工程平衡点。无论是采用电池供电的便携式音箱,还是依赖市电的桌面设备,功耗预算都是产品定义阶段就必须明确的硬性指标。本章将系统梳理功耗预算的核心概念:从mW与µW的单位认知,到平均功耗与峰值功耗的工程意义,再到不同供电场景下的预算策略差异,帮助你在方案选型和电路设计时建立清晰的量化思维。

智能音箱功耗预算核心框架 功耗单位体系 W(瓦特)→ mW(毫瓦) 1W = 1000mW = 10⁶µW µW级:唤醒监听电路 mW级:主控运行/音频播放 单位选择决定计算精度 功耗类型与工程意义 平均功耗 (P_avg) 决定电池续航/散热设计 峰值功耗 (P_peak) 决定电源/电容/保护设计 动态功耗 (P_dyn) 唤醒瞬间的电流冲击 P_avg × 时间 = 能量消耗 供电场景差异 电池供电(便携) µA级待机,mAh预算 市电供电(桌面) mW级待机,散热优先 混合供电(USB+电池) 需考虑充电/放电切换 预算策略完全不同 核心公式:P_avg = (Duty_cycle × P_active) + ((1 - Duty_cycle) × P_sleep) | 电池容量(mAh) = P_avg(mW) × 时间(h) / 电压(V)

4.1 功耗单位体系:从mW到µW的工程直觉

在智能音箱的低功耗设计中,功耗单位的选择直接反映了设计所处的抽象层级。瓦特(W)是国际单位制中的功率单位,但在嵌入式系统领域,我们更常使用毫瓦(mW)和微瓦(µW)。1W等于1000mW,1mW等于1000µW。这种千进制关系看似简单,但在实际工程中,混淆单位导致的错误可能让电池续航估算偏差达数倍。

理解单位的关键在于建立“量级直觉”:一颗典型的低功耗MCU(如Cortex-M0+内核)在活跃运行时的功耗约为5-20mW;而一颗专用的语音唤醒芯片(如超低功耗DSP)在Always-On监听模式下,功耗可以低至50-200µW。这意味着,唤醒监听电路的功耗比主控全速运行低两个数量级。这种巨大的差异,正是我们设计“分级唤醒”架构的物理基础——让99%的时间停留在µW级监听状态,仅在需要时短暂进入mW级处理状态。

单位换算速查:设计时建议统一使用µW作为待机功耗的计量单位,使用mW作为运行功耗的计量单位。例如,一个完整的监听链路(麦克风+前端放大+唤醒DSP)总功耗为180µW,而主控唤醒后运行VAD算法需要8mW。在计算平均功耗时,务必先将所有数值转换为同一单位(推荐mW),避免因小数点错位导致预算失真。

4.2 平均功耗与峰值功耗:两个维度的设计约束

平均功耗(P_avg)决定了系统的能量消耗总量,直接关联电池续航时间或市电供电下的长期散热需求。计算平均功耗时,需要将系统在不同状态(运行、空闲、睡眠、深度睡眠)下的功耗按时间占比加权求和。对于智能音箱,典型的功耗状态包括:Always-On监听(µW级)、唤醒确认(mW级)、命令执行(几十到几百mW)、待机(µW级)。

峰值功耗(P_peak)则决定了电源系统的瞬时供给能力。当主控从睡眠状态被唤醒时,内核时钟启动、外设上电、Flash读取,这些操作会在极短时间内(微秒到毫秒级)产生比平均功耗高10-50倍的电流冲击。如果电源设计无法满足峰值电流需求,会导致电压跌落(Vdroop),轻则系统复位,重则损坏存储数据。

工程上,我们通常用“功耗包络”来描述系统在不同时间尺度上的功耗变化。设计时需同时满足:

  • 能量约束:P_avg × 工作时间 ≤ 电池可用能量(或市电散热能力)
  • 瞬时约束:P_peak ≤ 电源转换器最大输出功率,且电压跌落在允许范围内(通常<3%)
  • 动态响应:电源系统对负载阶跃的响应时间需小于唤醒电路的建立时间
功耗类型 定义 设计影响 典型测量方法
平均功耗 一段时间内功耗的积分平均值 电池续航、散热器尺寸、能效认证 功率分析仪长时间记录,或电流积分法
峰值功耗 瞬时功耗的最大值 电源IC选型、去耦电容容量、PCB走线宽度 示波器+电流探头捕捉瞬态
待机功耗 系统处于最低功耗状态时的功耗 Always-On监听电路设计、电池待机时间 高精度万用表(nA分辨率)

4.3 电池供电与市电供电:预算策略的根本差异

供电场景决定了功耗预算的“硬约束”和“优化目标”。对于电池供电的便携智能音箱(如带电池的智能闹钟、户外语音助手),功耗预算的核心目标是最大化续航时间。假设采用一颗500mAh的锂电池(标称电压3.7V),可用能量约为1850mWh。如果Always-On监听功耗为200µW(约54µA@3.7V),则仅监听电路就能持续工作约3.4年——但实际系统还需考虑电池自放电、DC-DC转换效率(通常85-90%)、以及偶尔的唤醒处理,因此实际续航会显著缩短。

对于市电供电的桌面智能音箱,功耗预算的约束则完全不同。市电供电意味着能量近乎无限,但散热和能效法规成为新的约束。例如,欧盟ErP指令要求待机功耗不超过0.5W,而美国能源之星对智能音箱的待机功耗也有类似限制。此时,功耗预算的重点转向:降低待机功耗以满足法规、优化运行功耗以减少发热、以及确保峰值功耗不会导致电源适配器过载。

关键误区:不要将电池供电的功耗优化策略直接套用到市电设备上。电池设备追求“极低平均功耗”,而市电设备更关注“峰值功耗与散热平衡”。例如,在电池设备中,我们可能牺牲唤醒响应速度(增加50ms延迟)来换取更低的监听功耗;但在市电设备中,这种延迟优化毫无必要,反而应该优先保证唤醒的即时性和准确性。

4.4 实战案例:一款便携式语音助手的功耗预算拆解

我们以一款内置2000mAh锂电池的便携式智能音箱为例,完整演示功耗预算的制定过程。该产品要求:Always-On唤醒监听、支持10米远场唤醒、连续播放音乐8小时以上、待机(不播放)续航30天。

第一步:建立功耗模型。系统主要功耗模块包括:

  • 麦克风阵列(4颗MEMS麦克风):每颗约100µA@1.8V,共0.72mW
  • 音频编解码器(Codec):监听模式1.2mW,播放模式25mW
  • 唤醒DSP(专用低功耗芯片):Always-On监听180µW,唤醒确认时8mW
  • 主控SoC(应用处理器):深度睡眠50µW,运行VAD 15mW,播放音乐时120mW
  • 电源管理(DC-DC+LDO):转换效率85%

第二步:计算平均功耗。假设用户每天唤醒交互20次,每次交互平均10秒(包括唤醒确认+命令执行+语音反馈),其余时间处于Always-On监听状态。则:

每日监听时间 = 24h - (20次 × 10s/3600) ≈ 23.94h
监听功耗 = (0.72 + 1.2 + 0.18 + 0.05) mW ≈ 2.15mW
交互功耗 = (8 + 15 + 120) mW × (200s/86400s) ≈ 0.33mW(平均)
P_avg ≈ 2.15 + 0.33 = 2.48mW(系统总功耗)
考虑DC-DC效率85%:P_avg_battery = 2.48 / 0.85 ≈ 2.92mW

第三步:验证续航目标。电池可用能量 = 2000mAh × 3.7V = 7400mWh。理论续航 = 7400 / 2.92 ≈ 2534小时 ≈ 105天。但实际需考虑电池老化(80%容量保持率)、温度影响(低温容量下降)、以及自放电(每月约3%),因此实际待机续航约为60-70天,满足30天的设计目标。

第四步:峰值功耗验证。最恶劣情况是:唤醒DSP检测到关键词后,主控从深度睡眠唤醒并启动VAD,同时Codec切换到播放模式。此时峰值电流 = (8 + 15 + 25 + 120) mW / 3.3V ≈ 50mA。加上系统其他外设,总峰值约80mA。选择DC-DC转换器时,需确保其最大输出电流≥200mA(留足裕量),并在主控电源引脚旁放置10µF+100nF去耦电容,以应对<10µs的瞬态电流需求。

复盘经验:该案例中,Always-On监听功耗(2.15mW)占总平均功耗的74%,是续航的主要消耗源。若想进一步延长续航,应优先优化监听链路:例如选用更低功耗的MEMS麦克风(每颗50µA)、将Codec切换至“直通模式”绕过内部DSP、或采用事件驱动的麦克风(仅在检测到声音能量超过阈值时才唤醒DSP)。这些优化可将监听功耗降至1.2mW以下,续航提升近一倍。

4.5 常见误区与设计复盘

在功耗预算实践中,工程师常犯以下错误:

  1. 忽略转换效率:电池电压(3.7V)与系统电压(1.8V/3.3V)之间的DC-DC转换效率并非恒定,轻载时效率可能降至60%以下。计算平均功耗时必须使用实际负载下的效率曲线。
  2. 混淆“待机”与“关机”:真正的关机(切断所有电源)功耗为0,但用户期望的“待机”通常意味着仍能响应唤醒词,因此必须保留监听电路供电。设计时应明确区分这两种状态。
  3. 峰值功耗测量不充分:使用普通万用表无法捕捉微秒级的电流尖峰,必须使用带带宽限制的电流探头或功率分析仪。建议在原型阶段测量以下场景:上电瞬间、唤醒瞬间、Wi-Fi连接瞬间、音频播放启动瞬间。
  4. 温度对功耗的影响:锂电池在低温(0°C以下)时内阻增大,可用容量下降20-30%;同时,DC-DC转换器在高温下效率下降。预算时应考虑-10°C至+45°C的工作温度范围。

总结而言,功耗预算不是一次性的计算,而是贯穿产品生命周期的持续优化过程。建议在项目启动时建立功耗预算表,列出每个模块的功耗参数、工作状态、时间占比,并随着硬件迭代不断更新。只有将功耗预算作为与功能、成本同等重要的设计约束,才能真正实现“Always-On”与“低功耗”的兼得。