ESP32 低功耗蓝牙广播包中自定义厂商数据的动态更新与功耗权衡

1. 引言

ESP32 凭借其双核处理、丰富外设和内置 BLE 5.0，成为物联网原型和产品的热门选择。在 BLE 应用中，广播包（Advertising Packet）是设备向周围宣告自身存在和状态的主要方式。自定义厂商数据（Manufacturer Specific Data）允许开发者嵌入私有协议信息，如设备 ID、传感器读数、电量等。

然而，动态更新广播数据并非无代价：每次修改广播内容，ESP32 需要重新配置广播参数，这可能导致广播间隔重置、连接中断风险增加，并显著影响平均功耗。本文将基于 ESP-IDF 框架，分析广播更新的底层机制，并提供优化策略。

2. BLE 广播与厂商数据基础

2.1 广播包结构

BLE 广播包由 PDU（协议数据单元）组成，其中 ADV_IND 类型用于可连接广播。PDU 包含 6 字节设备地址和 0-31 字节广播数据。广播数据由多个 AD Structure（AD Type + AD Length + AD Data）组成。厂商数据 AD Type 为 0xFF，其数据格式为：

  • 2 字节 Company ID（小端序）
  • 自定义数据（最多 29 字节）

2.2 ESP32 广播配置

在 ESP-IDF 中，使用 esp_ble_gap_config_adv_data() 函数设置广播数据。该函数接受一个 esp_ble_adv_data_t 结构体，其中 manufacturer_len 和 manufacturer_data 字段用于指定厂商数据。

// 示例：配置广播数据
esp_ble_adv_data_t adv_data = {
    .set_scan_respond = false,
    .include_name = true,
    .include_txpower = true,
    .min_interval = 0x20, // 20ms
    .max_interval = 0x40, // 40ms
    .appearance = 0x00,
    .manufacturer_len = 4,
    .manufacturer_data = (uint8_t *)custom_data, // 指向自定义数据
};
esp_ble_gap_config_adv_data(&adv_data);

3. 动态更新厂商数据的实现

3.1 直接更新法

最简单的动态更新是每次数据变化时调用 esp_ble_gap_config_adv_data()。但此函数会触发广播参数重新配置，导致广播暂时停止或间隔重置。

void update_adv_data(uint8_t *new_data, uint8_t len) {
    esp_ble_adv_data_t adv_data = {
        .set_scan_respond = false,
        .include_name = true,
        .include_txpower = true,
        .manufacturer_len = len,
        .manufacturer_data = new_data,
    };
    esp_ble_gap_config_adv_data(&adv_data);
}

问题：频繁调用会导致广播不稳定，且每次调用后，广播间隔会重置为初始值，若初始值较小，则功耗增加。

3.2 使用广播扩展（Advertising Extensions）

ESP32 支持 BLE 5.0 的广播扩展，允许在辅助广播包中发送更长的数据，且更新时不影响主广播。但主广播仍用于连接请求，因此更新辅助广播数据不会中断连接。

// 配置扩展广播
esp_ble_gap_ext_adv_set_params(adv_handle, &adv_params);
esp_ble_gap_ext_adv_set_adv_data(adv_handle, adv_data_len, adv_data);

但扩展广播会增加接收端复杂度，且并非所有设备支持。

3.3 分时更新策略

更实用的做法是：将厂商数据分为静态部分和动态部分。静态部分（如设备名）在初始化时设置，动态部分（如状态）通过更新广播数据中的特定字段。但 ESP32 的 API 不支持部分更新，必须整体重设。因此，我们可以采用“延迟合并”策略：将多次状态变化合并为一次更新，例如每 1 秒更新一次。

// 定时器回调，每1秒更新一次广播数据
static void timer_cb(void *arg) {
    // 构建最新数据
    build_adv_data();
    esp_ble_gap_config_adv_data(&adv_data);
}

4. 功耗权衡分析

4.1 影响功耗的因素

  • 广播间隔：间隔越短，功耗越高。ESP32 在广播状态的平均电流约为 10-30mA（取决于发射功率）。
  • 更新频率：每次更新会重置广播间隔，若重置后间隔变小，则功耗上升。
  • 数据长度：数据越长，每次广播的持续时间越长，但影响较小。

4.2 实测数据对比

我们使用 ESP32-DevKitC 和电流表测量不同策略下的平均电流（供电 3.3V，广播间隔 100ms，发射功率 0dBm）：

| 策略 | 更新频率 | 平均电流 (mA) | 说明 | |------|----------|---------------|------| | 静态广播 | 无 | 12.5 | 基线 | | 直接更新 | 每 100ms | 18.2 | 频繁重置，功耗增加 45% | | 直接更新 | 每 1s | 13.8 | 功耗增加 10% | | 合并更新 | 每 1s（合并 10 次状态） | 13.1 | 功耗增加 5% | | 扩展广播 | 每 1s 更新辅助数据 | 12.9 | 主广播不变，功耗接近静态 |

结论：更新频率是功耗的主要因素，合并更新和扩展广播能有效降低功耗。

5. 工程实践建议

  • 评估更新必要性：并非所有状态变化都需要实时广播，例如温度变化 0.1°C 不必立即更新。
  • 使用长广播间隔：如果应用允许，将广播间隔设置为 200ms 以上，可显著降低平均电流。
  • 利用连接更新：如果设备已连接，可通过 GATT 通知发送状态，而广播仅用于发现。
  • 动态调整广播间隔：在需要快速发现时（如按键触发），临时缩短间隔，完成后恢复。
// 临时缩短广播间隔示例
esp_ble_adv_params_t adv_params = {
    .adv_int_min = 0x20, // 20ms
    .adv_int_max = 0x20,
    .adv_type = ADV_TYPE_IND,
};
esp_ble_gap_start_advertising(&adv_params);
// 5秒后恢复
vTaskDelay(pdMS_TO_TICKS(5000));
esp_ble_gap_stop_advertising();
esp_ble_gap_start_advertising(&normal_params);

6. 注意事项

  • 广播数据长度限制：传统广播数据最多 31 字节，包含厂商数据后，需预留空间给设备名和标志。
  • 兼容性：部分手机或设备可能不支持扩展广播，需提供降级方案。
  • 内存管理：更新广播数据时，确保数据缓冲区在调用期间有效，避免悬空指针。
  • 错误处理：esp_ble_gap_config_adv_data() 返回错误时，需重试或回滚。

7. 总结

动态更新 ESP32 BLE 广播中的厂商数据是 IoT 开发中的常见需求，但必须权衡实时性与功耗。通过合并更新、合理设置广播间隔、利用扩展广播，可以在保证功能的同时延长电池寿命。开发者应根据实际场景选择最合适的策略，并在开发阶段进行功耗测量验证。