4. 功耗模型分析：LTE与BLE的能耗解剖
功耗模型这东西，说白了就是给芯片的“耗电行为”拍一张X光片。你得知道它什么时候在喘气、什么时候在睡觉、什么时候在猛跑。我在做第一个低功耗项目时，就是没仔细看模型，结果电池续航直接砍半。嗯，从那以后，我养成了一个习惯——先建模，再调参。
这一章，咱们把LTE和BLE的功耗状态机拆开来看。你会发现，协同唤醒的真正优化空间，就藏在这些状态切换的缝隙里。
4.1 LTE的功耗模型与状态机
LTE模块的功耗，不是一条直线。它更像一个阶梯——你待在不同的状态，耗电差好几个数量级。
4.1.1 核心状态定义
我习惯把LTE的功耗状态分成三个层级：
| 状态 | 典型电流 | 进入条件 | 退出条件 |
|---|---|---|---|
| RRC_IDLE | 1-5 mA | 无数据活动超时 | 寻呼周期到达或上行数据触发 |
| RRC_CONNECTED | 50-200 mA | 建立RRC连接 | 不活动定时器超时 |
| PSM (省电模式) | 5-15 µA | TAU周期内无活动 | TAU定时器到期 |
关键洞察：从IDLE到CONNECTED的切换，需要消耗约300-500 mJ的能量。这个“跳变成本”是协同唤醒要重点规避的。
4.1.2 状态机流转与时间参数
LTE的状态机，其实是一个“超时驱动”的模型。我记得有一次调试，发现模块频繁在IDLE和CONNECTED之间来回跳，电池掉得飞快。后来一查，是不活动定时器设得太短了。
几个关键时间参数：
- T3324：从CONNECTED进入PSM的等待时间，典型值2-10秒
- T3412：PSM状态下的TAU周期，典型值54分钟到310小时
- 寻呼周期：IDLE状态下监听网络的间隔，通常1.28秒或2.56秒
你想想看，如果设备每5秒发一次数据，它根本进不了PSM，一直卡在CONNECTED状态，功耗直接拉满。这就是为什么很多NB-IoT设备要刻意把上报间隔拉到10分钟以上。
4.1.3 功耗计算公式
我个人习惯用这个简化公式来估算LTE的平均功耗：
P_avg = (T_idle * I_idle + T_conn * I_conn + T_psm * I_psm) / T_total其中，T_idle、T_conn、T_psm分别是各状态的驻留时间。注意，这里没算入状态切换的瞬态功耗，实际项目中要加一个10-15%的裕量。
避坑指南：我曾经在项目中直接用芯片手册上的典型电流值做计算，结果实测偏差了30%。原因是手册给的是“稳态电流”，没算入射频发射时的峰值脉冲。建议你至少用示波器抓一次实际波形，校准模型参数。
4.2 BLE的功耗模型与状态机
BLE的功耗模型，比LTE简单得多。它的核心思想是“短时爆发，长时休眠”。说白了，就是猛干一下，然后睡大觉。
4.2.1 核心状态定义
| 状态 | 典型电流 | 说明 |
|---|---|---|
| 广播态 (Advertising) | 5-15 mA (峰值) | 发送广播包，持续约1-3 ms |
| 连接态 (Connected) | 3-10 mA (峰值) | 按连接间隔收发数据 |
| 休眠态 (Sleep) | 1-5 µA | 仅RTC运行，等待唤醒事件 |
4.2.2 连接间隔与功耗的关系
BLE的功耗，几乎完全由连接间隔决定。间隔越短，延迟越低，但功耗越高。我做过一个测试：
- 连接间隔 7.5 ms：平均电流约 1.2 mA
- 连接间隔 100 ms：平均电流约 150 µA
- 连接间隔 1000 ms：平均电流约 20 µA
你看，把间隔从7.5ms拉到100ms，功耗直接降了8倍。但代价是响应延迟从几毫秒变成了上百毫秒。这就是典型的“功耗-延迟”权衡。
4.2.3 BLE的功耗计算公式
BLE的平均功耗，可以用这个公式估算：
P_avg = (T_event * I_event + T_sleep * I_sleep) / (T_event + T_sleep)其中，T_event是每次连接事件的时间（包括收发和准备），I_event是事件期间的电流。T_sleep是休眠时间。
我的经验：BLE的功耗模型里，最容易忽略的是“唤醒准备时间”。芯片从休眠到射频开启，通常需要100-300 µs，这期间的电流是线性上升的。如果连接间隔很短，这部分开销占比会很大。我建议你在模型里加一个“唤醒开销系数”，大概乘1.1-1.2。
4.3 协同唤醒的功耗优化空间
好了，现在我们把LTE和BLE的功耗模型放在一起看。你会发现，协同唤醒的核心思路其实就一句话：用BLE的低功耗监听，替代LTE的高频寻呼。
4.3.1 优化空间量化分析
咱们算一笔账。假设一个设备每小时需要检查一次是否有下行数据：
- 纯LTE方案：每小时唤醒一次，每次从IDLE到CONNECTED再回到IDLE，消耗约500 mJ。平均功耗 = 500 mJ / 3600 s ≈ 0.14 mW
- 协同唤醒方案：LTE进入PSM深度休眠，BLE每5秒监听一次广播包。BLE平均功耗约20 µA × 3.3V = 0.066 mW。LTE只在BLE触发时才唤醒，假设每小时触发一次，功耗还是0.14 mW，但BLE的0.066 mW是持续开销。
等等，这么算下来，协同唤醒反而更耗电？
别急，这里的关键是触发频率。如果下行数据不是每小时一次，而是每天一次呢？
- 纯LTE：每天唤醒一次，500 mJ / 86400 s ≈ 0.0058 mW
- 协同唤醒：BLE持续监听，0.066 mW + LTE每天一次0.0058 mW ≈ 0.072 mW
嗯，还是BLE方案更耗电？
你想想看，问题出在哪？出在BLE的监听间隔太短了。如果我把BLE的监听间隔从5秒拉到60秒呢？
- BLE优化后：平均电流降到约5 µA，功耗 = 5 µA × 3.3V = 0.0165 mW。加上LTE的0.0058 mW，总共约0.022 mW。
这下，协同唤醒比纯LTE省了约4倍。而且，BLE的监听间隔还可以根据业务需求动态调整——业务繁忙时缩短，空闲时拉长。
核心结论：协同唤醒的优化空间，取决于两个因素：1) BLE监听间隔的合理设置；2) 下行数据触发频率。当触发频率低于每10分钟一次时，协同唤醒的优势开始显现。频率越低，优势越大。
4.3.2 状态机协同的优化点
我个人认为，协同唤醒最大的优化空间，不在单个模块的功耗，而在状态切换的时机对齐。举个例子：
- LTE进入PSM的时机：应该在BLE确认网络无下行数据后，立即让LTE进入PSM，而不是等不活动定时器超时。这可以节省几十秒的CONNECTED状态功耗。
- BLE唤醒LTE的时机：应该在BLE收到有效唤醒包后，立即触发LTE唤醒。如果BLE在监听周期内没收到包，LTE继续睡。
- 联合休眠策略：当LTE进入PSM时，BLE可以同步进入深度休眠（只保留RTC），只在约定的监听窗口唤醒。这样，两个模块的休眠周期完全对齐，没有额外开销。
我曾经踩过的坑：在第一个协同唤醒方案里，我让LTE和BLE各自独立管理休眠。结果LTE睡了，BLE还在高频监听；BLE睡了，LTE又醒了。两个模块的休眠窗口完全错开，总功耗比单用LTE还高。后来我加了一个“休眠同步控制器”，才把这个问题解决。
4.3.3 功耗优化空间总结
我把协同唤醒的优化空间整理成了一张表，方便你对照：
| 优化维度 | 优化前 | 优化后 | 节省比例 |
|---|---|---|---|
| LTE唤醒频率 | 每小时1次 | 每天1次 | 96% |
| BLE监听间隔 | 5秒 | 60秒 | 92% |
| 休眠同步 | 独立休眠 | 联合休眠 | 30-50% |
| 状态切换时机 | 定时器超时 | 事件驱动 | 20-40% |
你看，每个维度都有不小的优化空间。但要注意，这些优化不是简单叠加的。比如，你把LTE唤醒频率降到每天一次，但BLE监听间隔还是5秒，那总功耗可能反而更高。所以，协同唤醒的功耗优化，是一个系统级的权衡问题。
4.4 本章小结
功耗模型分析，说白了就是搞清楚“电都去哪了”。LTE的功耗大头在状态切换和CONNECTED态，BLE的功耗大头在监听间隔和连接事件。协同唤醒的优化空间，本质上是用BLE的低功耗监听，换取LTE的高频唤醒。但要注意，这个“交换”不是免费的——BLE本身也在耗电。只有把BLE的监听间隔拉到足够长，把LTE的唤醒频率压到足够低，协同唤醒才能真正省电。
嗯，这一章的内容就到这里。下一章，咱们会深入具体的硬件选型和电路设计，看看怎么把这些功耗模型落地到实际板子上。