4. mA budget定义与规划流程
TinyML 设备通常由纽扣电池或小型锂电池供电，其能量密度、峰值放电能力和总容量都极为有限。与云端 AI 芯片动辄数十瓦的功耗不同，TinyML 设备的平均功耗往往被限制在毫瓦甚至微瓦级别。这意味着，在项目启动的第一天，我们就必须回答一个核心问题：在既定的电池容量和续航目标下，整个系统（包括传感器、MCU、无线通信和电源管理）允许消耗多少平均电流？ 这个允许值，就是 mA budget（毫安预算）。它不是事后测量的结果，而是事前规划的约束条件，是所有软硬件设计决策的出发点。
上图展示了 mA budget 从推导到分配再到迭代验证的完整闭环。整个过程并非一次性完成，而是随着硬件选型和软件优化的深入不断修正。下面我们将从定义、推导方法、分配原则和迭代流程四个维度展开。
4.1 什么是 mA budget：从系统视角定义电流约束
mA budget 是指在整个产品生命周期内，为满足续航目标而分配给系统各功能模块的平均电流上限。它不是一个单一数值，而是一个多维度的约束集合，包括：平均电流（I_avg）、峰值电流（I_peak）、休眠电流（I_sleep）以及不同工作模式下的时间占比（duty cycle）。
理解 mA budget 需要区分三个层次：
- 系统级预算：整个设备从电池取用的平均电流，这是最顶层的约束，直接由电池容量和续航时间决定。
- 子系统级预算：分配给感知、计算、通信、电源管理等子系统的电流份额。各子系统预算之和必须小于系统级预算。
- 模式级预算：针对每个子系统在不同工作模式（活跃、空闲、休眠）下的电流消耗和时间占比进行细化。
例如，一个使用 200mAh 纽扣电池、目标续航 30 天的温湿度传感器，其系统级平均电流预算为：
I_avg = 可用容量 / 总续航时间
= (200mAh × 0.9) / (30天 × 24小时)
= 180mAh / 720h
= 0.25mA (即 250µA)这 250µA 就是整个系统的平均电流上限。如果 BLE 广播每次消耗 5mA、持续 10ms，那么每小时的广播次数不能超过 18 次（5mA × 0.01s × 18 = 0.9mAs，折合平均 0.25mA）。这就是 mA budget 对设计决策的直接约束。
4.2 从电池容量和续航目标推导平均电流预算
推导过程需要综合考虑电池特性、系统效率和实际使用模式。以下是标准推导流程：
- 确定可用容量：电池标称容量（mAh）乘以放电效率系数。对于碱性电池，系数约为 0.85-0.95；对于锂电池，约为 0.95-0.98。同时要考虑温度影响，低温下容量会显著下降。
- 计算总续航时间：将目标寿命（天）乘以每天工作小时数，得到总小时数。如果设备是 24/7 不间断运行，则直接使用天数×24。
- 推导平均电流：用可用容量除以总续航时间，得到系统级平均电流预算。
- 考虑自放电率：电池在存储和使用过程中会自放电。对于长期项目（超过1年），自放电率可能占初始容量的 10-20%。
- 预留安全边际：建议在理论预算基础上预留 10-15% 的冗余，以应对电池老化、温度波动和测量误差。
| 参数 | 符号 | 示例值 | 说明 |
|---|---|---|---|
| 电池标称容量 | C_nom | 300 mAh | CR2032 纽扣电池典型值 |
| 放电效率 | η_d | 0.9 | 考虑内阻和截止电压 |
| 自放电率 | η_s | 0.95 | 年自放电约5% |
| 可用容量 | C_use | 256.5 mAh | 300 × 0.9 × 0.95 |
| 目标续航 | T | 180 天 | 每天24小时连续运行 |
| 平均电流预算 | I_avg | 59.4 µA | 256.5mAh / (180×24h) |
需要注意的是，这个推导假设设备以恒定电流放电。实际中，TinyML 设备通常以脉冲方式工作：大部分时间处于休眠状态，偶尔唤醒进行采样和推理。因此，我们需要将平均电流预算转化为峰值电流与占空比的组合约束。
4.3 预算分配原则：从系统级到子系统级
获得系统级平均电流预算后，需要将其分解到各个子系统。分配原则遵循“先固定、后弹性”的策略：
- 固定开销优先：电源管理芯片的静态电流、MCU 的深度休眠电流、传感器的最低功耗模式，这些是“无论是否工作都必须消耗”的电流，应首先从总预算中扣除。
- 通信模块弹性最大：无线通信（BLE、LoRa、WiFi）的峰值电流极高（10-100mA），但可以通过降低广播频率、缩短连接窗口来大幅降低平均电流。这是预算调整的主要杠杆。
- 计算模块按需分配：MCU 的推理功耗取决于工作频率、电压和推理时长。TinyML 推理通常只需几毫秒到几十毫秒，因此即使峰值电流 5mA，只要每天只推理几次，平均电流贡献也很小。
- 传感器按采样率分配：传感器的功耗与采样频率成正比。降低采样率是节省预算的最直接手段。
一个典型的分配案例如下（系统预算 250µA）：
| 子系统 | 固定电流 | 平均电流预算 | 占比 | 主要约束 |
|---|---|---|---|---|
| 电源管理 (DC-DC) | 2 µA | 5 µA | 2% | 静态电流 Iq |
| MCU 深度休眠 | 1.5 µA | 3 µA | 1.2% | RTC 唤醒 |
| 传感器 (温湿度) | 0.1 µA | 12 µA | 4.8% | 每10秒采样一次 |
| MCU 活跃推理 | - | 30 µA | 12% | 每天推理100次，每次3ms |
| BLE 广播 | - | 150 µA | 60% | 每秒广播一次，每次5mA/10ms |
| 系统冗余 | - | 50 µA | 20% | 预留调整空间 |
从这个案例可以看出，通信模块占据了预算的 60%，是优化的首要目标。如果 BLE 广播频率从每秒一次降低到每 5 秒一次，平均电流可降至 30µA，释放出 120µA 的预算空间。
4.4 迭代流程：从估算到实测的闭环优化
mA budget 的规划不是一次性的静态活动，而是一个随着项目推进不断迭代的动态过程。标准迭代流程包含以下五个阶段：
- 初始估算：基于数据手册和参考设计，估算各子系统的电流消耗。此时误差可能达到 ±50%，但足以判断方案的可行性。
- 硬件原型验证：使用开发板或第一版 PCB 进行实测。使用高精度万用表（如 Keysight 34461A）或专用功耗分析仪（如 Nordic PPK2、Joulescope）测量各子系统的实际电流。
- 偏差分析：将实测值与预算值对比，找出超支或富余的模块。通常会发现传感器唤醒电流高于预期、MCU 休眠电流比手册高 1-2µA 等问题。
- 策略调整：根据偏差调整软件策略。例如，延长传感器采样间隔、优化 BLE 连接参数、使用 MCU 的低功耗定时器替代 RTC 等。
- 回归验证：在真实使用场景下进行长时间（至少 48 小时）的电流记录，验证平均电流是否满足预算。
以下是一个完整的案例闭环：
背景与约束： 使用 2 节 AA 碱性电池（总容量 2400mAh），目标续航 1 年（365 天），每天采集 4 次土壤数据并通过 LoRa 上报。系统级平均电流预算为 2400mAh / (365×24h) = 274µA。
初始估算： 传感器（土壤湿度+温度）每次采样 20mA 持续 50ms，每天 4 次，平均 0.46µA；MCU 休眠电流 2µA；LoRa 发送每次 40mA 持续 200ms，每天 4 次，平均 3.7µA；DC-DC 静态电流 5µA。总估算约 11µA，远低于预算。
实测发现： 使用 Joulescope 测量后发现，LoRa 模块在发送后进入 idle 模式时仍有 1.2mA 电流，持续 2 秒。这导致每天额外消耗 1.2mA × 2s × 4 = 9.6mAs，折合平均 0.11µA，影响不大。但更严重的是，MCU 在休眠时外接传感器电源未完全切断，导致漏电 15µA，远超预期。
优化措施： ① 在 MCU 休眠前通过 GPIO 控制传感器电源完全断开；② 将 LoRa 模块在发送后立即进入 sleep 模式（通过 AT 指令）；③ 调整 MCU 的时钟源为外部 32.768kHz 晶振，降低休眠电流。
结果： 优化后实测平均电流为 8.2µA，远低于 274µA 的预算。实际续航预计可达 12 年以上（受电池自放电限制）。
复盘经验： 数据手册中的“休眠电流”往往不包括外设漏电。必须在系统层面测量，而不仅仅是模块层面。同时，预算冗余（本例中预算 274µA，实际仅用 8.2µA）为未来增加功能（如更高采样率）留足了空间。
这个案例展示了迭代流程的价值：初始估算看似充裕，但实测暴露了隐藏的漏电路径。通过软件策略调整和硬件优化，最终实现了远超目标的续航表现。
4.5 常见误区与总结
在 mA budget 规划中，工程师常犯以下错误：
- 只关注平均电流，忽略峰值电流：电池在峰值放电时电压会跌落，可能导致 MCU 复位或传感器读数异常。必须确保电池能够提供峰值电流（通常需要 2-3 倍平均电流的裕量）。
- 将数据手册值当作实际值：手册中的电流值是在理想条件下测得的，实际应用中受温度、电压、PCB 布局影响，偏差可达 30-50%。
- 忽略休眠模式的漏电：许多工程师只计算活跃模式的电流，但 TinyML 设备 99% 的时间处于休眠状态。即使 10µA 的漏电，在一年内也会消耗 87.6mAh，占 300mAh 电池的 29%。
- 预算分配过于紧凑：不留冗余的预算在后期几乎必然导致续航不达标。建议至少保留 15-20% 的未分配预算。