3. 软件排查：驱动版本检查、固件参数配置、省电模式设置、DTIM间隔调整
硬件排查做完，功耗问题还在？别急。我见过太多人一上来就换天线、改电路，结果折腾半天，最后发现是驱动版本太老，或者某个固件参数压根没对齐。软件层面的排查，往往是见效最快、成本最低的切入点。
这一章，咱们就聚焦四个关键点：驱动版本、固件参数、省电模式、DTIM间隔。说白了，就是让芯片“该睡的时候睡，该醒的时候醒，别瞎忙活”。
3.1 驱动版本检查：别让老代码拖后腿
驱动是芯片和系统之间的翻译官。翻译官水平不行，功耗自然高。我个人习惯，拿到一个新平台，第一件事就是查驱动版本。
3.1.1 为什么驱动版本影响功耗？
驱动里藏着大量的功耗控制逻辑。比如：
- 省电状态机：驱动决定芯片何时进入Doze、何时唤醒。
- TX/RX调度：低效的调度会让芯片频繁空转。
- 中断合并：老驱动可能每个小包都触发中断，CPU和WiFi芯片都累。
我在项目中遇到过，某款芯片用v4.1驱动时，待机功耗是15mA；升级到v4.3后，直接降到8mA。厂商的Release Notes里写着“优化了PS-Poll处理流程”——就这一行，省了一半电。
3.1.2 如何检查驱动版本？
Linux系统下，最直接的方法：
# 查看WiFi驱动信息
ethtool -i wlan0
# 或者
cat /proc/net/wireless
# 或者直接看内核模块
lsmod | grep cfg80211
modinfo <驱动模块名>拿到版本号后，去芯片厂商官网比对。别只看主版本号，小版本和补丁号也很关键。我建议建立一个版本对照表：
| 芯片型号 | 推荐驱动版本 | 最低可用版本 | 已知功耗问题版本 |
|---|---|---|---|
| BCM43455 | v5.10.20 | v5.8.0 | v5.6.x（PS-Poll异常） |
| QCA6174 | v3.8.2 | v3.6.0 | v3.4.x（DTIM唤醒异常） |
| MT7668 | v2.1.4 | v2.0.0 | v1.9.x（空口扫描频繁） |
3.2 固件参数配置：芯片的“出厂设置”不一定最优
驱动之上，还有固件。固件是跑在WiFi芯片内部的小系统。很多功耗参数，其实是在固件侧控制的。驱动只是传话的。
3.2.1 关键固件参数
不同芯片的固件参数名不同，但核心逻辑相似。我整理了几个最常见的：
- Beacon Listen Interval：芯片每隔几个Beacon醒来一次。值越大，越省电，但可能丢包。
- PS-Poll / U-APSD：省电收包机制。U-APSD比PS-Poll更高效，但需要AP支持。
- TX Power Backoff：发射功率回退。信号好时，没必要满功率发射。
- Scan Interval：后台扫描间隔。默认可能每30秒扫一次，改成120秒能省不少电。
3.2.2 如何调整？
以Linux的cfg80211工具为例：
# 查看当前参数
iw dev wlan0 get power_save
iw dev wlan0 get listen_interval
# 设置省电模式
iw dev wlan0 set power_save on
# 设置Beacon Listen Interval（单位：Beacon间隔，通常100ms）
iw dev wlan0 set listen_interval 10 # 每1秒醒来一次如果是高通平台，通常用wpa_cli或iwpriv：
# 高通私有命令示例
iwpriv wlan0 setPowerSave 1
iwpriv wlan0 setRxFilter 13.3 省电模式设置：三种模式，三种命运
WiFi省电模式，不是只有“开”和“关”。实际上，主流芯片支持三种模式：
| 模式 | 功耗 | 延迟 | 适用场景 |
|---|---|---|---|
| Continuous Active Mode (CAM) | 高（~200mA） | 低（<10ms） | 视频通话、在线游戏 |
| Power Save Mode (PSM) | 中（~50mA） | 中（~100ms） | 网页浏览、消息推送 |
| Deep Sleep Mode (DSM) | 低（<5mA） | 高（>1s） | 待机、后台同步 |
说白了，没有万能的模式。我见过一个智能门锁项目，工程师把PSM开到最大，结果门锁响应开门指令要等3秒——用户投诉“门锁反应慢”。后来改成动态切换：待机时DSM，触发门铃时切回CAM。
3.3.1 动态切换策略
我个人推荐的做法是：
- 默认使用PSM：平衡功耗和延迟。
- 检测到活跃流量时，临时切到CAM：比如TCP连接建立、视频流开始。
- 空闲超过5秒，退回PSM：再空闲30秒，进入DSM。
代码层面，可以用nl80211的NL80211_CMD_SET_POWER_SAVE命令动态切换。嗯，这里要注意：频繁切换本身也会消耗功耗。我一般设置一个“滞回时间”，比如至少保持当前模式2秒，避免乒乓效应。
3.4 DTIM间隔调整：AP端的“闹钟”设置
DTIM（Delivery Traffic Indication Message）是AP端的一个参数。它告诉WiFi芯片：“你睡吧，有数据时我喊你。” DTIM间隔越大，芯片睡的时间越长，但数据延迟也越大。
3.4.1 DTIM与功耗的关系
你想想看：如果DTIM=1，每个Beacon都包含DTIM信息，芯片每个Beacon（约100ms）都要醒来一次。如果DTIM=10，芯片每10个Beacon（约1秒）才醒来一次。功耗自然降了。
但代价是什么？如果AP在芯片睡着时收到了数据，最多要等1秒才能发下来。对于实时性要求高的应用（比如语音），这个延迟不可接受。
3.4.2 如何调整DTIM？
DTIM是在AP端设置的。如果是自己管理的AP：
# OpenWrt / LEDE 系统
# 编辑 /etc/config/wireless
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'MyWiFi'
option encryption 'psk2'
option key 'password'
option dtim_period '3' # 默认1，改为3如果是家用路由器，通常在无线高级设置里能找到“DTIM间隔”或“信标间隔”。
3.4.3 客户端侧的配合
客户端也可以设置自己的Listen Interval。但要注意：客户端的Listen Interval不能大于AP的DTIM间隔，否则可能收不到广播/组播数据。
| AP DTIM | 客户端Listen Interval | 实际唤醒间隔 | 典型功耗（待机） |
|---|---|---|---|
| 1 | 1 | 100ms | ~15mA |
| 3 | 3 | 300ms | ~8mA |
| 10 | 10 | 1s | ~3mA |
3.5 本章知识体系
下面这张图，帮你理清软件排查的四个维度：
软件排查，说白了就是“对参数、调策略、看匹配”。驱动版本不对，后面调再多也是白费。固件参数没对齐，省电模式再强也发挥不出来。DTIM间隔不匹配，客户端和AP各睡各的，数据就丢了。
我个人习惯，每次排查都按这个顺序来：先确认驱动版本，再检查固件参数，然后设置省电模式，最后调整DTIM。每一步都记录原始值和修改值，方便回退。嗯，这样虽然慢一点，但不会漏掉问题。