广播模式发送节能优化HiChatBox实践-CSDN博客

广播模式发送节能优化HiChatBox实践

你有没有遇到过这样的情况：一个小小的蓝牙设备，明明只是偶尔“说句话”，结果电池却撑不过几天？🔋 在智能硬件圈子里，这几乎是每个工程师都头疼的问题——尤其是当你的产品像 HiChatBox 这样，既要随时能被发现，又要省电到极致。

HiChatBox 是一款专为语音交互设计的嵌入式通信模块。它不靠屏幕，也不连 Wi-Fi，全靠 BLE（蓝牙低功耗）广播来“喊话”：“嘿，我在这儿！有新消息！”但问题来了：如果一直喊，电量很快就没了；如果不喊或喊得太少，用户又可能根本找不到它。

怎么破？我们搞了一套 广播节能优化组合拳 ，把平均功耗压到了 10μA 以下 ，让待机时间从原来的3天直接拉到 两周以上 ！👏

下面我就带你拆解这套方案，看看我们是怎么在“被发现”和“省电”之间找到那个完美平衡点的。

BLE 广播，到底是怎么吃掉电量的？

先别急着优化，咱们得明白敌人是谁。BLE 广播听着简单，其实暗藏玄机。

它的本质是：外围设备（比如 HiChatBox）每隔一段时间就在三个固定信道（37/38/39 MHz）上“吆喝”一次，把自己的存在感发出去。中心设备（比如手机）通过扫描这些吆喝声来发现它。

但每一次“吆喝”，都要启动射频、打包数据、发射信号……这一套动作下来，哪怕只有几毫秒，电流也会瞬间飙高。而平均功耗，正是由这个“吆喝”的频率决定的——也就是所谓的 广播间隔（Advertising Interval） 。

举个例子：
- 每 100ms 广播一次 → 射频频繁唤醒 → 功耗飙升
- 每 1s 广播一次 → 安静得多 → 电流骤降

Nordic 的 nRF52832 上实测数据显示：
- 100ms 间隔：约 45μA
- 1s 间隔：仅 8μA！

所以， 减少广播次数 = 直接省电 。可问题是，你也不能完全不喊啊，不然谁还能找得到你？

于是我们就想：能不能“看人下菜碟”？有人在附近时多喊两声，没人理我时就安静躺平？

💡 答案就是： 动态广播周期调整（Adaptive Advertising Interval）

聪明地“喊话”：会变节奏的广播

我们给 HiChatBox 加了个“环境感知大脑”。它会根据以下几个信号，自动切换广播节奏：

刚按了按钮？→ 用户可能正在找我 → 进入“高响应模式”，每 100ms 喊一次，持续2分钟。
手机最近扫过我？→ 说明有人关注 → 保持正常频率（500ms）。
电量低于20%？→ 赶紧省电 → 切到 1~3 秒一次，进入“节能甚至极限节能”状态。

模式	广播间隔	典型场景
高响应	100ms	用户刚操作后
正常	500ms	日常待机
节能	1s~2s	夜间或低电
极限节能	3s+	长期离线值守

这样一套策略下来， 广播相关能耗直接下降 70% 以上 。最关键的是，用户体验几乎没受影响——你想连的时候它就在那儿，不想管它的时候它就乖乖睡觉。

实现起来也不复杂，用 Nordic SDK 写个函数就行：

void update_advertising_interval(uint8_t mode) {
    uint32_t interval_ms;

    switch(mode) {
        case MODE_HIGH_RESPONSE: interval_ms = 100; break;
        case MODE_NORMAL:        interval_ms = 500; break;
        case MODE_LOW_POWER:     interval_ms = 1000; break;
        case MODE_ULTRA_SAVING: interval_ms = 3000; break;
        default:                 interval_ms = 500;
    }

    uint16_t adv_int = (uint16_t)(interval_ms * 1000 / 625); // 转成 BLE 单位（0.625ms步进）

    sd_ble_gap_adv_stop();
    ble_advertising_start(BLE_ADV_MODE_SLOW);
}

⚠️ 注意：必须先停再启，否则新间隔不会生效。这点坑了我好几次 😅

小身材大能量：11字节搞定所有信息

你以为这就完了？还没呢。

BLE 广播包最多只能塞 31 字节的有效数据。如果你傻乎乎地把设备名 "HiChatBox_Voice_Alert" 全写进去，光名字就占了 20 多字节，剩下啥也干不了。

我们的做法是： 精简 + 压缩 + 编码

不传名字，传“指纹”

我们不再广播完整名称，而是计算一个 4 字节的 CRC32 截断哈希作为“昵称指纹”。手机端有个本地缓存表，看到这个指纹就知道你是谁。

🤔 会不会冲突？概率极低。万一真撞了，App 提示用户手动确认即可。

UUID 也要瘦身

标准 128 位服务 UUID 太占地方？我们用自定义的短格式（比如 24 位），配合主机映射还原，省下宝贵的字节空间。

状态信息打包装

音量、充电状态、未读消息……这些原本可以单独字段传输的信息，我们统统编码成一个 1 字节的状态位域（bitfield） ：

bit0: 是否有未读语音消息  
bit1-bit2: 音量等级（0~3）  
bit3: 是否正在充电  
bit4-bit7: 预留扩展

再加上 RSSI Hint（粗略距离提示），整个广播负载压缩到 仅 11 字节 ，腾出近 20 字节留给未来功能扩展。

好处不止是省电——更短的数据意味着更短的空中传输时间，抗干扰能力也更强，丢包率明显下降 ✅

让“扫描”变成一次轻量对话

很多人不知道，BLE 广播其实是可以“互动”的。

当你使用“可扫描非连接广播”（Scannable Undirected Advertising）时，手机不仅可以听你喊话，还能反问一句：“兄弟，最近有啥新鲜事吗？”——这就是 Scan Request 。

而你可以回复一条 Scan Response ，最多再传 31 字节数据，且无需建立连接！

我们充分利用了这一点：平时广播里只放静态信息（如设备类型、哈希值），一旦收到 Scan Request，立刻动态组装一条响应，包含：

最新语音消息 Token（4 字节）
更新时间戳（低16位）
当前电量百分比（1 字节编码）

整个过程耗时不到 1ms，MCU 处理完马上又能睡了。每次唤醒成本才 0.3mC 左右 ，却能让手机精准判断是否需要进一步连接下载语音包。

相当于：你不问我，我就不说；你一问，我就告诉你最新的情况。

这种“按需拉取”机制，彻底避免了为了同步状态而频繁刷新广播内容的浪费行为。👏

代码也很简洁，注册个回调就行：

static void on_scan_req_received(ble_evt_t const * p_ble_evt) {
    if (p_ble_evt->header.evt_id == BLE_GAP_EVT_SCAN_REQ_RECEIVED) {
        uint8_t scan_rsp[31];
        int len = 0;

        // 返回名称哈希
        scan_rsp[len++] = 0x09;
        scan_rsp[len++] = 0x08;
        memcpy(&scan_rsp[len], device_name_hash, 4);
        len += 4;

        // 动态生成状态字节
        uint8_t status_byte = 0;
        if (has_unread_message()) status_byte |= (1 << 0);
        status_byte |= (get_volume_level() & 0x03) << 1;
        if (is_charging())       status_byte |= (1 << 3);

        scan_rsp[len++] = 0x02;
        scan_rsp[len++] = 0xFF;
        scan_rsp[len++] = status_byte;

        sd_ble_gap_adv_data_set(NULL, 0, scan_rsp, len);
    }
}

利用硬件中断快速响应，处理完立马休眠，干净利落。

实战效果：从3天到14天的飞跃

回到最开始的问题：原来待机只有3天，现在怎么样了？

来看看实际对比👇

问题	优化手段	效果
长时间广播耗电快	动态调节广播周期	待机提升至 14 天
手机不知是否有新消息	Scan Response 返回状态	支持免连接查询
广播包大易丢包	数据压缩与精简	包大小 ↓60%，稳定性 ↑
多设备互相干扰	随机化广播定时偏移（±10%）	碰撞率 ↓40%