Rockchip BLE低功耗唤醒：广播扫描与GPIO唤醒源实践

做电池供电的音频类产品那阵子最头疼的不是音质也不是配网而是待机功耗和唤醒手感这对天生的冤家。产品要求待机一周以上又要求用户从手机点一下连接机器两秒内亮屏响应。把 Rockchip BLE 低功耗唤醒这套东西真正跑通中间踩的坑比写业务代码多得多。所谓 Rockchip BLE 低功耗唤醒说白了就是让 RK 主控尽量睡着把有没有人找我这件事交给蓝牙控制器去扛通过广播扫描Advertising Scan在射频层识别特定报文再用一根 GPIO 把主控捅醒。它解决的是设备长期在线但几乎不耗电这个矛盾适合做便携音箱、智能面板、手持终端、电池门铃这类 RK 平台的低功耗产品。下面这套方案是我在几个项目里反复打磨后沉淀下来的包含硬件接线约束、设备树改法、广播协议设计、可直接编译运行的扫描程序以及实测出来的功耗账照着做基本能少走两三个月的弯路。1. 方案总览把判断逻辑下沉到射频层1.1 三条唤醒路径的功耗与响应账在 RK 平台上做低功耗唤醒实际只有三条路可走选错方向后面全是徒劳。第一条是纯主机侧轮询主控定期从休眠中醒来跑一次扫描扫完再睡。第二条是连接态保活设备一直维持一条 BLE 连接靠链路层心跳判断对端是否还在。第三条就是本文要讲的控制器侧广播扫描主控彻底睡着蓝牙控制器独立维持扫描窗口命中条件后拉 GPIO。先看功耗账。主机轮询的问题在于醒来本身很贵——RK 平台从 suspend 恢复一次DDR 重新上电、时钟树重建、驱动 resume整套下来少说 60 到 150 毫秒峰值电流能冲到 150 毫安以上。如果每 3 秒轮询一次平均电流就被拉到了 3 到 8 毫安这还没算恢复过程中外设的浪涌。连接态保活更糟BLE 连接间隔即使放到 2 秒射频收发加主机侧协议栈处理平均也要 1 毫安上下而且一旦对端离开设备还得自己判超时重建逻辑复杂。控制器侧扫描则是把占空比压到极致扫描窗口占空比通常只有 2% 到 5%射频接收电流按 6 到 8 毫安算平均摊下来不到 0.4 毫安主控全程保持 suspend只留 PMU 静态电流和 DDR 自刷新。三条路的量级差异直接决定了产品能不能宣称长待机。方案主控状态平均电流典型值唤醒时延实现复杂度适用场景主机侧轮询反复 suspend/resume3 到 8 mA0.5 到 2 s低唤醒实时性要求不高的场合连接态保活主控需定期处理链路事件0.8 到 1.5 mA仅 BLE 部分主控仍要醒20 到 200 ms中需要双向通信的常连设备控制器侧广播扫描持续 suspend主控 suspend 电流 0.2 到 0.4 mA0.8 到 3 s高电池供电、事件驱动的唤醒这张表里有个容易被忽略的细节控制器侧扫描那一行的平均电流只是 BLE 部分的增量主控 suspend 电流要单独算。很多人做功耗预算时把两者相加搞混最后实测差一倍就是因为把 BLE 控制器的休眠电流当成了射频电流。1.2 Rockchip 上的唤醒链路到底怎么走一条完整的唤醒链路是手机发出携带自定义载荷的广播包BLE 控制器在扫描窗口内收到控制器固件或我们的扫描程序比对载荷命中后把 WAKE_HOST 引脚拉高这个引脚接到 RK 主控的某个 GPIO 上该 GPIO 在设备树里被注册为wakeup-sourcePMU 检测到唤醒事件后给主控上电、恢复 DDR、跑 resume 流程最后用户态程序收到事件开始干活。这条链路上有四个环节任何一环断了都唤不醒而它们的排查手段完全不同射频层有没有收到包、控制器层有没有正确比对、电气层GPIO 电平有没有真的翻转、系统层这个 GPIO 有没有被注册成唤醒源。我在项目里养成的习惯是每次调不通就先分层定位别一上来就改代码。用手机上的调试 App 看广播有没有发出去、用逻辑分析仪抓 WAKE 引脚有没有翻转、用/proc/interrupts看中断计数有没有涨三分钟就能锁定是哪一层的问题。Rockchip 的电源管理架构里suspend 流程由 PMU通常是配套的电源管理芯片配合主控进入mem状态后除了保留域always-on domain之外大部分电源域断电。这就带来一个硬约束蓝牙控制器绝不能挂在主控可控的电源轨上。我见过太多板子把 BLE 模组的供电接到主控的某个 LDO 使能脚上suspend 的时候 LDO 一关模组直接断电这时候再怎么调软件都是白费。1.3 为什么选广播扫描而不是连接态保活连接态保活的思路很自然——手机和设备一直连着手机一操作设备就知道。但放在电池产品上它有三个绕不过去的硬伤。第一是功耗不可控。BLE 连接的心跳由连接间隔决定手机侧发起连接后间隔参数被手机主导Android 上常见 30 到 50 毫秒iOS 更激进。设备每个连接事件都得醒来收发射频和协议栈的功耗摊下来很难低于 0.8 毫安而且这个值不受你控制用户换台手机功耗就变了产品没法给出稳定的续航承诺。第二是状态机的坑。设备 suspend 之后连接会断resume 后要重连重连过程中如果手机已经走远设备会陷在超时重试里反而更费电。要做优雅处理必须引入状态持久化和重连退避代码量比扫描方案大得多。第三是并发问题。一个 BLE 控制器同时只能维持有限条连接如果设备还要被多个手机控制连接数一满就出问题。而广播扫描是无状态的来多少个手机发广播都能收谁先命中谁说了算逻辑简单得多。广播扫描的代价是单向——设备只能听不能主动回。所以产品设计上要做一次握手设备被唤醒后主动广播自己的服务手机端监听到再发起连接。这个先醒后连的两段式流程响应时间会比常连方案多 1 到 2 秒但换来的续航提升是数量级的值。2. 硬件与系统底座让 WAKE 引脚真能把主控叫醒2.1 电路上的三条命脉接线这块我把它归纳成三条命脉缺一条整套方案就跑不通。第一条是供电必须常开。BLE 模组的 VBAT 要直接挂到电池或常开的电源轨上或者挂在一个不受主控 suspend 控制的 LDO 后面。判断方法很简单主控进入mem之后拿万用表量模组 VBAT 脚电压不能掉。如果掉了说明供电设计有问题得改板或者改 PMU 配置。同时要注意模组的休眠电流便宜的模组休眠电流能到 200 微安直接吃掉你一半的预算选型时一定要看 datasheet 里的 sleep current目标控制在 50 微安以内。第二条是UART 双向握手要齐。除了 TX/RX硬件流控 CTS/RTS 最好也接上。BLE 模组在扫描期间会突发上报大量广播事件如果主控这边处理不过来又没有流控串口 FIFO 溢出会导致丢包丢的恰好是你要的那个唤醒包那就很难受。流控引脚在 suspend 期间的状态也要确认——有些模组要求 RTS 保持某个电平才不休眠这些细节必须翻模组的硬件设计手册。第三条是WAKE_HOST 引脚极性要固定不能悬空。这个引脚是模组输出、主控输入模组没上电的时候是高阻态如果主控侧没有下拉电阻引脚会浮在一个不确定电平上运气不好就一直触发唤醒待机功耗直接爆炸。我的做法是在主控侧加一个 100k 下拉把默认电平钉死模组拉高才有效。如果模组是低有效输出那就加上拉。极性在设备树里用GPIO_ACTIVE_HIGH或GPIO_ACTIVE_LOW标清楚别指望软件去猜。另外提醒一个容易忽略的点WAKE_HOST 这根线如果走线太长和 UART 或者射频走线平行距离过远容易耦合进干扰导致偶发误唤醒。板子上至少要保证它和射频天线之间有个地平面隔离长度控制在 10 厘米以内比较稳妥。2.2 设备树改造把 GPIO 注册成唤醒源硬件没问题之后软件第一件事是把这根 GPIO 变成系统认可的唤醒源。RK 平台的常见做法是借用gpio-keys驱动它的好处是不用自己写驱动注册、上报、唤醒一条龙都有了。/* 1. 先把引脚复用成 GPIO 功能加上下拉 */ pinctrl { bt_wake_pin: bt-wake-pin { rockchip,pins 0 RK_PA5 RK_FUNC_GPIO pcfg_pull_down; }; }; /* 2. 用 gpio-keys 注册成唤醒源 */ / { bt_wake: bt-wake { compatible gpio-keys; pinctrl-names default; pinctrl-0 bt_wake_pin; wakeup-source; status okay; bt_wake_btn: bt-wake-btn { label bt_wake; gpios gpio0 RK_PA5 GPIO_ACTIVE_HIGH; linux,code KEY_WAKEUP; linux,input-type EV_KEY; wakeup-source; }; }; };这段设备树有三个地方必须确认。pcfg_pull_down是下拉配置对应刚才说的硬件下拉双保险。wakeup-source属性在父节点和子节点上都要写只写一个在部分内核版本上不生效——这个坑我踩过当时只写了子节点结果/sys/class/input/inputX/device/power/wakeup里永远是 disabled查了半天。linux,code用KEY_WAKEUP而不是普通按键码避免和真实的物理按键在事件上报时混淆。如果产品里不想让用户态看到按键事件只想安静地唤醒也可以用rockchip,gpio-wakeup之类的私有绑定或者干脆自己写个极简的 platform driver 只注册device_init_wakeup()和enable_irq_wake()。但我的经验是能用现成驱动就别自己写gpio-keys 稳定、经过大量验证出问题的概率低得多。设备树编译烧录之后第一件事是验证注册是否成功# 找到对应的输入设备 ls /sys/class/input/ # 查看唤醒能力应该是 enabled cat /sys/class/input/input3/device/power/wakeup # 查看能否被当作唤醒源计数 cat /sys/class/input/input3/device/power/wakeup_count如果wakeup显示disabled先echo enabled .../power/wakeup手动打开试试。能手动打开说明驱动注册没问题只是默认没使能手动也打不开那就是设备树里wakeup-source没生效回去检查属性写的位置。2.3 内核选项与运行时开关内核配置里有几项是必须打开的漏一个就会出现能唤醒但醒不透或者根本进不去 suspend的怪现象。CONFIG_PM_SLEEPy # suspend to RAM 的基础 CONFIG_PM_WAKELOCKSy # 部分 RK 内核版本依赖 CONFIG_PM_WAKELOCKS_LIMIT0 # 不限制 wakelock 数量 CONFIG_KEYBOARD_GPIOy # gpio-keys 驱动 CONFIG_BTy CONFIG_BT_HCIUARTy CONFIG_BT_HCIUART_H4y # 大多数 UART BLE 模组走 H4 CONFIG_BT_HCIUART_3WIREy # 如果硬件流控接了就一起开 CONFIG_BT_LEy # BLE 支持CONFIG_PM_WAKELOCKS这一项要特别留意。有些 RK 的 BSP 内核默认用它有些默认用标准CONFIG_PM_SLEEP的主线机制两者的用户态接口不同。如果你发现/sys/power/wake_lock这个文件不存在说明内核没开 wakelock 框架那 suspend 的时机就只能靠autosleep或者手动触发脚本写法要跟着改。运行时还有一组开关值得调# 允许自动进入 suspend部分系统用这个 echo mem /sys/power/autosleep # 或者手动控制 echo 0 /sys/power/pm_async # 关掉异步 suspend方便调试时序 echo 1 /sys/power/pm_print_times # 打印每个设备的 suspend 耗时 # 确认唤醒源列表 cat /sys/kernel/debug/wakeup_sourcespm_print_times这个开关在调 suspend 卡住的问题时特别好用它会把每个设备 suspend 花了多少毫秒打出来谁拖后腿一目了然。我遇到过一次 suspend 要 4 秒才进去打开这个之后发现是某个外设的驱动在 resume/suspend 里做了 3 秒的延时等待砍掉之后就正常了。2.4 唤醒源自检三步法装好系统先别急着写扫描程序先做一次假唤醒测试确认电气和系统链路是通的。方法是用一根杜邦线手动短接 WAKE_HOST 到 VCC模拟模组拉高。第一步进 suspendecho mem /sys/power/state屏幕黑掉、串口无输出说明进去了。第二步拉高引脚。如果板子上不方便短接也可以用另一个 GPIO 输出高电平模拟# 前提是有个可控的 GPIO 输出脚接到 WAKE_HOST gpioset gpiochip0 121第三步观察是否恢复。正常的话串口会立刻打印 resume 日志。如果没反应去查两件事/proc/interrupts里那个 GPIO 的中断计数在 suspend 前后有没有变化有变化但没唤醒说明是唤醒源没使能没变化说明信号根本没到。这个三步测试做完硬件和系统层就基本可信了后面所有问题都可以怀疑到蓝牙和协议这一层排查范围一下子小了很多。3. 广播报文协议设计一次可校验的握手3.1 字段布局怎么定广播包的空间很紧张。传统 BLE 广播 PDU 的 payload 最多 31 字节扣掉 flags、设备名、服务 UUID 这些占位留给自定义数据通常只有 20 字节出头。BLE 5.0 的扩展广播能到 254 字节但手机侧的支持度参差不齐做兼容性优先的产品还是按 31 字节规划比较稳。我用的布局是这样的总共 14 字节塞进 Manufacturer Specific DataAD type 0xFF里前面再加 2 字节的 Company ID偏移长度字段说明02Company ID低字节在前选一个自用段别撞知名厂商24Magic固定值比如0x52 0x4B 0x42 0x57快速筛掉 99.99% 的无关广播61Version协议版本方便后续升级兼容71Cmd唤醒命令字0x01 普通唤醒0x02 强制唤醒0x03 配对模式82Seq16 位递增序号防重放102Nonce随机数进一步降低碰撞概率122CRC16前 12 字节的 CCITT 校验为什么先放 Magic 再放别的因为扫描程序在收到每个广播包时都要做一次快速判断Magic 放在最前面比较可以直接用 32 位整数一次搞定省掉逐字节循环。扫描期间每秒可能收到几十上百个包这点优化累积起来是可观的尤其是在性能本来就弱的低端 RK 芯片上。Cmd 字段留着很有用。产品后期往往会加配网模式、OTA 模式、工厂测试模式这些都可以通过不同的 Cmd 值区分设备被唤醒后读一下 Cmd 就知道该干什么不用再建立连接问一遍。3.2 为什么不能只靠 MAC 白名单新手最容易想到的方案是把手机的 MAC 地址加到白名单只认这个地址。听起来天衣无缝实际上现代手机和操作系统默认都开了随机私有地址RPA每次连接或每隔一段时间就换一个你的白名单第二天就失效了。更麻烦的是白名单机制本身的功耗优势也不明显。控制器做地址过滤确实比上报所有包省电但省的是主机侧的处理功耗射频接收的功耗一分不少——因为控制器还是得把每个包收下来解出地址才能比对。所以我的做法是MAC 地址不用来做身份认证只用来做进一步确认。也就是说广播载荷里的 Magic CRC 是主要判据MAC 地址在载荷校验通过之后如果用户配置了绑定设备再比对一次进一步降低误触发。但绝不能反过来。如果产品确实需要强身份认证正规做法是用 BLE 的隐私特性手机上存设备的 IRK设备侧维护 Resolving List控制器用 IRK 解析 RPA 后再做白名单匹配。这套机制在 HCI 上有对应的命令LE Add Device To Resolving List但实现复杂度不低而且需要手机端配合写入 IRK对普通消费类产品来说属于过度设计。3.3 防重放与防误触发误唤醒是低功耗产品最致命的敌人。一次误唤醒主控醒 3 秒按 120 毫安算就是 0.1 毫安时的额外消耗一天误醒 50 次续航就少了好几个百分点。更别说用户半夜被设备莫名其妙亮灯吓到。防误触发我分了四层。第一层是 Magic4 字节固定值随手写的测试 App 撞上的概率是 2 的负 32 次方可以忽略。第二层是 CRC16能挡住射频误码和部分随机数据。第三层是 Seq 和 Nonce前者单调递增设备记录上次收到的最大 Seq收到比它小的直接丢弃防止别人录下来重放后者是随机数配合 Seq 一起校验。第四层是产品级的频率限制设备被唤醒后记录时间戳如果 60 秒内又收到同一个 Seq 的包直接忽略。这四层加起来误唤醒率能压到每月个位数。但要注意Seq 的记录必须放在非易失存储里否则设备一断电重启Seq 归零之前录的包全都能重放了。我用的是主控的一块 eMMC 分区里的小文件或者更轻量的做法是用 RTC 备份寄存器存一个 32 位值掉电不丢读写也快。还有一个现实问题多个手机同时想控制设备怎么办如果每台手机各自生成 Seq设备的最大 Seq记录就会互相打断。解决办法是放宽到按 Magic 设备绑定标识分组记录或者干脆只对已绑定的手机做 Seq 校验未绑定的只做 Magic CRC 校验被唤醒后走配网流程。产品逻辑怎么定取决于你的安全等级要求。3.4 载荷生成与校验代码手机端生成载荷我不写 App 代码给一段可以直接在 PC 上跑的 C 参考实现方便造测试包#include stdint.h #include string.h #include stdio.h static uint16_t crc16_ccitt(const uint8_t *data, size_t len) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { crc ^ (uint16_t)data[i] 8; for (int b 0; b 8; b) crc (crc 0x8000) ? (uint16_t)((crc 1) ^ 0x1021) : (uint16_t)(crc 1); } return crc; } /* 返回载荷长度写入 outout 至少 14 字节 */ size_t build_wake_payload(uint8_t *out, uint8_t cmd, uint16_t seq, uint16_t nonce) { memcpy(out, \x52\x4B\x42\x57, 4); /* Magic RKBW */ out[4] 0x01; /* Version */ out[5] cmd; out[6] seq 0xFF; out[7] (seq 8) 0xFF; out[8] nonce 0xFF; out[9] (nonce 8) 0xFF; /* 这里只是演示布局真正上产品时把 Company ID 也算进 CRC */ uint16_t crc crc16_ccitt(out, 10); out[10] crc 0xFF; out[11] (crc 8) 0xFF; return 12; } int main(void) { uint8_t buf[32]; size_t n build_wake_payload(buf, 0x01, 1001, 0xA5C3); printf(payload len%zu:, n); for (size_t i 0; i n; i) printf( %02X, buf[i]); printf(\n); return 0; }编译gcc -o gen_payload gen_payload.c跑出来的十六进制串可以直接贴进手机上的广播模拟工具里发出去。设备侧用同一份 CRC 实现校验两边一致就能通信。实际项目里我把 Company ID 也计入了 CRC 覆盖范围这样能防止别人用相同的 Company ID 撞车。上面的示例为了简洁省掉了你在真正落地的时候记得加上覆盖范围在设备侧和手机侧要严格对齐改一处必须改两处否则会出现手机侧发出来校验不过的经典问题。4. 从验证到产品扫描程序怎么写4.1 先用 btmgmt 十分钟把链路打通写代码之前先用现成工具把手机发广播、设备扫到这条链路验证一遍这一步能省掉后面大量的自我怀疑。# 确认控制器存在并上电 hciconfig -a btmgmt --index 0 power on # 只做 LE 扫描不发现经典蓝牙 btmgmt --index 0 find -l # 如果系统里是 bluetoothctl bluetoothctl --timeout 20 scan onbtmgmt find -l会在终端里刷出扫到的每一个广播和它的载荷十六进制你拿手机发一条自定义广播从这里就能看到载荷长什么样。看到了说明射频和控制器都正常问题只会出在后面的过滤逻辑上看不到先排查天线、供电、控制器固件。顺便记录一下扫描时的电流。这时候主控是满负荷运行的电流读数会是几百毫安但没关系这个阶段看的是有没有收到而不是省不省电。等程序写好了再测功耗。4.2 C 版 HCI 扫描守护进程产品里不能依赖 BlueZ 那一大堆进程我用的是直接打开 HCI 通道的方式HCI_CHANNEL_USER会把控制器从内核协议栈手里接管过来完全由我们的程序控制。前提是先把bluetoothd停掉、hci0down 掉否则 bind 会返回EBUSY。/* ble_wake_scan.c * 编译: gcc -O2 -o ble_wake_scan ble_wake_scan.c -lbluetooth * 运行: hciconfig hci0 down systemctl stop bluetooth ./ble_wake_scan */ #define _GNU_SOURCE #include stdio.h #include stdlib.h #include stdint.h #include string.h #include unistd.h #include errno.h #include signal.h #include sys/socket.h #include bluetooth/bluetooth.h #include bluetooth/hci.h #include bluetooth/hci_lib.h #define SCAN_INTERVAL 0x0800 /* 2048 * 0.625ms 1280ms */ #define SCAN_WINDOW 0x0040 /* 64 * 0.625ms 40ms */ #define MATCH_MAX 4 static volatile sig_atomic_t g_stop 0; static void on_sig(int s) { (void)s; g_stop 1; } static uint16_t crc16_ccitt(const uint8_t *d, size_t len) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { crc ^ (uint16_t)d[i] 8; for (int b 0; b 8; b) crc (crc 0x8000) ? (uint16_t)((crc 1) ^ 0x1021) : (uint16_t)(crc 1); } return crc; } static int hci_open_user(int dev) { int fd socket(AF_BLUETOOTH, SOCK_RAW | SOCK_CLOEXEC, BTPROTO_HCI); if (fd 0) { perror(socket); return -1; } struct sockaddr_hci a; memset(a, 0, sizeof(a)); a.hci_family AF_BLUETOOTH; a.hci_dev (uint16_t)dev; a.hci_channel HCI_CHANNEL_USER; if (bind(fd, (struct sockaddr *)a, sizeof(a)) 0) { perror(bind HCI_CHANNEL_USER); close(fd); return -1; } return fd; } static int hci_cmd(int fd, uint16_t opcode, uint8_t plen, const uint8_t *param) { uint8_t buf[260]; buf[0] 0x01; /* HCI Command */ buf[1] opcode 0xFF; buf[2] (opcode 8) 0xFF; buf[3] plen; if (plen) memcpy(buf 4, param, plen); return (int)write(fd, buf, 4 plen); } static int scan_start(int fd) { uint8_t sp[7]; sp[0] 0x00; /* 被动扫描省电 */ sp[1] SCAN_INTERVAL 0xFF; sp[2] (SCAN_INTERVAL 8) 0xFF; sp[3] SCAN_WINDOW 0xFF; sp[4] (SCAN_WINDOW 8) 0xFF; sp[5] 0x00; /* Public 地址 */ sp[6] 0x00; /* 接受所有广播 */ if (hci_cmd(fd, 0x200B, sizeof(sp), sp) 0) return -1; /* LE Set Scan Parameters */ uint8_t en[2] { 0x01, 0x00 }; /* 开扫描不过滤重复 */ if (hci_cmd(fd, 0x200C, sizeof(en), en) 0) return -1; /* LE Set Scan Enable */ return 0; } /* 在 AD 结构里找 Manufacturer Specific Data并校验载荷 */ static int match_payload(const uint8_t *ad, uint8_t adlen) { uint8_t i 0; while (i adlen) { uint8_t len ad[i]; if (len 0 || i len adlen) break; const uint8_t *p ad i 1; if (p[0] 0xFF len 1 12) { const uint8_t *d p 1; /* 跳过 AD type */ if (memcmp(d, RKBW, 4) ! 0) return 0; uint16_t crc crc16_ccitt(d, 10); uint16_t got (uint16_t)(d[10] | (d[11] 8)); if (crc ! got) { fprintf(stderr, crc mismatch: calc%04X got%04X\n, crc, got); return 0; } uint16_t seq (uint16_t)(d[6] | (d[7] 8)); fprintf(stderr, match! cmd0x%02X seq%u nonce%04X\n, d[5], seq, (unsigned)(d[8] | (d[9] 8))); return 1; } i len 1; } return 0; } int main(int argc, char **argv) { int dev (argc 1) ? atoi(argv[1]) : 0; int timeout_s (argc 2) ? atoi(argv[2]) : 120; signal(SIGTERM, on_sig); signal(SIGINT, on_sig); int fd hci_open_user(dev); if (fd 0) return 1; if (scan_start(fd) 0) { close(fd); return 1; } fprintf(stderr, scan started, interval%ums window%ums\n, SCAN_INTERVAL * 625 / 1000, SCAN_WINDOW * 625 / 1000); uint8_t buf[1024]; int hits 0; time_t deadline time(NULL) timeout_s; while (!g_stop hits MATCH_MAX time(NULL) deadline) { ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { if (errno EINTR) continue; perror(read); break; } if (n 4 || buf[0] ! 0x04) continue; /* 只处理 Event */ uint8_t evt buf[1]; uint8_t plen buf[2]; if (n 3 plen) continue; /* LE Meta Event */ if (evt ! 0x3E || plen 2) continue; const uint8_t *p buf 3; if (p[0] ! 0x02) continue; /* Advertising Report */ uint8_t num p[1]; const uint8_t *q p 2; const uint8_t *end buf 3 plen; for (uint8_t k 0; k num q 9 end; k) { uint8_t dlen q[8]; if (q 9 dlen 1 end) break; if (match_payload(q 9, dlen)) hits; q 9 dlen 1; /* 1 是 RSSI */ } } /* 停扫描避免退出后控制器还在耗电 */ uint8_t off[2] { 0x00, 0x00 }; hci_cmd(fd, 0x200C, sizeof(off), off); close(fd); fprintf(stderr, exit, hits%d\n, hits); return hits 0 ? 0 : 2; }这段代码有几个地方值得细说。扫描参数SCAN_INTERVAL 0x0800对应 1280 毫秒SCAN_WINDOW 0x0040对应 40 毫秒占空比 3.125%。这两个值是功耗和检出率的平衡点后面第五节会细算。注意 BLE 规范要求 window 不能大于 interval且两者都必须是 0.625 毫秒的整数倍写之前算好。扫描类型选了0x00被动扫描。主动扫描会发 SCAN_REQ 去要 scan response多一次收发功耗高不说还可能暴露设备存在。被动扫描只听不说对唤醒场景完全够用因为唤醒载荷放在广播包里就够了不需要 scan response。read()是阻塞读这是好事——没有数据时进程完全休眠不占 CPU。所以整个程序的功耗基本就是射频的功耗用户态几乎为零。千万别写成轮询read加usleep那样光是检查循环就能吃掉好几毫安。事件解析里q 9 dlen 1这个步进要仔细核对每个 report 的头部是 Event_Type(1) Address_Type(1) Address(6) Data_Length(1) 共 9 字节然后 dlen 字节数据最后 1 字节 RSSI。算错一步后面全乱。最后退出前一定要发LE Set Scan Enable(0)把扫描停掉。我见过程序异常退出没有停扫描控制器还在那扫整机功耗莫名其妙高了 0.3 毫安查了两天才定位到。4.3 编译、部署与 systemd 托管gcc -O2 -Wall -o ble_wake_scan ble_wake_scan.c -lbluetooth strip ble_wake_scan install -m 0755 ble_wake_scan /usr/local/bin/用 systemd 托管方便开机自启和崩溃重启[Unit] DescriptionBLE wake scan daemon Beforebluetooth.service Aftermulti-user.target [Service] Typesimple ExecStartPre/bin/sh -c hciconfig hci0 down || true ExecStart/usr/local/bin/ble_wake_scan 0 0 Restarton-failure RestartSec1 Nice-10 IOSchedulingClassrealtime [Install] WantedBymulti-user.targetExecStart的第二个参数是超时秒数传 0 表示一直扫不超时产品形态下通常是常驻。Nice-10和实时 IO 调度是防止低优先级时被其他进程抢占导致丢包——虽然被动扫描对实时性要求不算极致但控制器的缓冲有限读得慢了会丢事件。还要注意Beforebluetooth.service避免 BlueZ 抢控制器。如果产品本身不需要经典蓝牙干脆把bluetooth.service禁用掉省得开机时两边打架。4.4 suspend 前后钩子脚本真正让设备省电还得让主控睡着钩子脚本负责在睡眠前后做该做的事#!/bin/sh # /usr/lib/systemd/system-sleep/50-ble-wake.sh PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin case $1 in pre) logger -t ble-wake suspend prepare # 确保唤醒源使能 for f in /sys/class/input/input*/device/power/wakeup; do [ -w $f ] echo enabled $f 2/dev/null done # 停掉不必要的外设降低 suspend 后的漏电 [ -d /sys/class/net/wlan0 ] ip link set wlan0 down 2/dev/null ;; post) logger -t ble-wake resume done # 唤醒后 3 秒内保持 wakelock等业务起来 if [ -w /sys/power/wake_lock ]; then echo btwake /sys/power/wake_lock ( sleep 3; echo btwake /sys/power/wake_unlock ) fi ;; esacpost里那个 3 秒 wakelock 很关键。设备被唤醒后如果业务进程响应慢主控可能在你还没处理完事件的时候又自动睡回去了表现出来就是设备亮了一下又灭了用户以为坏了。加个短暂的 wakelock 把这段时间锁住等业务接管之后再释放。写完记得chmod xsystemd 只执行有可执行权限的文件少这一步脚本会静默不生效很难查。5. 功耗实测与调参5.1 预算怎么算功耗预算不靠感觉靠公式。整机平均电流可以拆成四块I_total I_ap_suspend I_ble_sleep I_rf_avg I_leak I_rf_avg (W / I) * I_rx其中W是扫描窗口I是扫描间隔I_rx是射频接收时的瞬时电流。以本文参数为例W 40ms、I 1280ms占空比 3.125%I_rx按 6.5 毫安算射频平均就是 0.203 毫安。I_ble_sleep按模组手册取 30 微安I_ap_suspend在 RK 平台上实测 15 到 25 毫安不等取决于 DDR 容量和外设漏电取 18 毫安。加起来约 18.23 毫安。拿 2000mAh 电池算理论续航约 110 小时也就是 4 天半。这个数字很可能低于产品宣称的待机一周差距主要在主控 suspend 电流上。我做过对比同一块板子把 DDR 从 2GB