无线抓包功耗优化指南 - 第3节

抓包模式设计：主动抓包 vs 被动监听

做无线抓包优化，第一个要拍板的问题就是：到底让设备主动去抓，还是让它老老实实待在那边听？

这两种模式，说白了就是「主动出击」和「守株待兔」的区别。我刚开始做低功耗抓包时，总觉得主动抓包更可控，结果电池撑不过半天。后来才明白，选错模式，功耗直接翻倍。

主动抓包：轮询式扫描

主动抓包模式下，设备会定期唤醒，主动发送探测请求（Probe Request），然后等待周围设备的响应。这种方式适合需要快速发现网络、或者需要与特定设备建立连接的场景。

但代价也很明显——每次主动发送请求，射频发射器都要全功率工作。我测过一个项目，主动抓包时的峰值电流高达 120mA，而被动监听只有 30mA 左右。

对比项	主动抓包	被动监听
唤醒频率	可控，但每次需全功率发射	由空中信号决定
峰值电流	高（80-150mA）	低（20-40mA）
发现速度	快（毫秒级）	依赖信号到达
功耗可控性	好（可调节扫描间隔）	差（被动等待）

被动监听：嗅探式接收

被动监听就简单了——设备只开接收机，不发射任何信号。它像一只「耳朵」，只收不说。

我有个经验：如果只是做数据采集或环境监测，被动监听永远是功耗最优解。 因为接收机的功耗通常只有发射机的 1/3 到 1/5。

混合模式：动态切换

实际产品中，我更推荐混合模式。平时设备处于被动监听状态，只有当检测到关键事件（比如信号丢失超过阈值）时，才临时切换到主动抓包。

我曾经在一个智能门锁项目里用过这种方案：门锁平时被动监听门磁信号，功耗只有 5μA。只有当门被打开时，才主动扫描一次周围的蓝牙设备，确认是不是主人回来了。这样既保证了实时性，又把平均功耗压到了 10μA 以下。

抓包触发条件设计

抓包不能「瞎抓」。触发条件设计得好，功耗能省一大半。

时间触发：定时唤醒

最简单的触发方式。设备每隔固定时间醒来，抓一次包，然后继续睡。

// 伪代码示例：定时触发抓包
void timer_trigger_capture() {
    if (time_elapsed >= CAPTURE_INTERVAL_MS) {
        enter_active_mode();
        capture_packets(MAX_PACKETS);
        enter_sleep_mode();
        time_elapsed = 0;
    }
}

这里有个坑：间隔设得太短，功耗飙升；设得太长，数据丢失。 我一般建议根据业务容忍度来定。比如温度传感器，5 分钟抓一次就够了；但门磁传感器，1 秒不抓可能就漏了事件。

事件触发：中断唤醒

事件触发更智能。设备平时深度睡眠，只有外部中断（比如 GPIO 电平变化、RTC 闹钟、或者射频能量检测）才唤醒抓包。

信号触发：RSSI 阈值

这个比较高级。设备持续监听信道，只有当检测到的信号强度（RSSI）超过设定阈值时，才开始抓包。适合那些「只关心强信号」的场景。

我做过一个停车场车位检测器，平时 RSSI 阈值设在 -80dBm。只有车辆经过（信号突然变强）时才开始抓包。这样 99% 的时间设备都在睡，平均功耗不到 2μA。

抓包深度与功耗的权衡

抓包深度，就是每次抓多少数据。抓得越深，信息越全，但功耗也越高。

浅抓包：只抓头部

只抓 MAC 帧头（约 24-34 字节），不抓 Payload。适合只需要知道「谁在发信号」的场景。

• 优点：功耗低，处理快
• 缺点：无法获取数据内容
• 典型功耗：每次抓包约 0.5mJ

深抓包：全包捕获

抓取完整的 MAC 帧，包括 Payload。适合需要分析数据内容的场景。

• 优点：信息完整
• 缺点：功耗高，存储压力大
• 典型功耗：每次抓包约 2-5mJ

自适应深度：动态调整

我比较推荐的做法是：先浅抓，发现感兴趣的内容再深抓。

比如设备先抓头部，如果发现源地址在预设的白名单里，才继续抓 Payload。这样既保证了关键数据不丢，又避免了无意义的全包抓取。

三种模式的决策流程

下面这张图是我做项目时常用的决策流程，帮你快速选型：

总结一下我的经验

抓包模式设计没有银弹。我的习惯是：先被动，后主动；先浅抓，后深抓。 用最少的功耗，抓最需要的数据。

你想想看，如果设备 99% 的时间都在空转抓包，那跟没优化有什么区别？