上一篇我们用 nRF54L15 做了 CS 测距 + LED 距离条。【NRF54L15|信道探测】2、用nRF54L15做一个"距离指示灯"-电子产品世界论坛。

功能跑通后面临真正的 产品化问题：Tag 工作电流约 2mA，一颗 CR2032（约 220mAh）只能撑 4~5 天。 本文记录如何把电流压下去，以及顺手解决的一个隐蔽 Bug （主机复位后 Tag 长达 46 秒无法重连）。

环境：NCS v3.3.0，nRF54L15-DK（Initiator）+ 自研 nRF54L15 Tag（Reflector， CR2032 供电）。

1. 先算账：2mA 花在了哪里

CS Reflector 样例（ras_reflector）是"能跑就行"的演示代码，对功耗毫无优化。 逐个排查，电流主要流向四个地方：

可以看到，最冤的是那颗 LED——它比 CS 测距本身还耗电。

2. 优化措施（按性价比排序）

2.1 干掉常亮 LED：从"常亮"到"5 秒眨一下"

完全砍掉 LED 固然最省，但现场没法判断 Tag 死活。折中方案：每 5 秒闪 30ms。

平均电流 ≈ 30ms / 5000ms × 2mA ≈ 12 µA，只有常亮方案的百分之一。

cs_tag/src/main.c：

static void alive_led_off_handler(struct k_timer *timer)
{
 ARG_UNUSED(timer);
 dk_set_led_off(DK_LED1);
}

static K_TIMER_DEFINE(alive_led_off_timer, alive_led_off_handler, NULL);

static void alive_blink_handler(struct k_timer *timer)
{
 ARG_UNUSED(timer);
 dk_set_led_on(DK_LED1);
 k_timer_start(&alive_led_off_timer, K_MSEC(30), K_NO_WAIT);
}

static K_TIMER_DEFINE(alive_blink_timer, alive_blink_handler, NULL);

/* main() 中 dk_leds_init() 之后： */
k_timer_start(&alive_blink_timer, K_SECONDS(5), K_SECONDS(5));

2.2 关闭串口控制台和日志

电池供电的 Tag 没人看串口，全部关掉（cs_tag/prj.conf）：

CONFIG_SERIAL=n
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_LOG=n
CONFIG_PRINTK=n

UART 外设挂着会让高频时钟域一直开着，这是 nRF 低功耗应用的经典漏点。

2.3 广播降速：100ms → 1~1.2 秒

Tag 未连接时一直在广播。样例用的 BT_LE_ADV_CONN_FAST_2（100~150ms 间隔） 是"开发期友好、电池不友好"的参数。改成慢速档：

#define CS_TAG_ADV_PARAM BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONN, \
      BT_GAP_ADV_SLOW_INT_MIN, \
      BT_GAP_ADV_SLOW_INT_MAX, NULL)

/* bt_le_adv_start(CS_TAG_ADV_PARAM, ...) */

注意这个 NCS/Zephyr 版本里没有现成的 BT_LE_ADV_CONN_SLOW_* 宏，需要用 BT_GAP_ADV_SLOW_INT_MIN/MAX（1.0s/1.2s）自己拼。实测对发现速度的影响 可以接受（对端 50% 占空比扫描时，几秒内能匹配上）。

2.4 测距频率：10Hz → 2Hz

CS 测距过程（procedure）是一串密集的射频收发，是连接状态下的耗电大头。 LED 距离条演示其实不需要 10Hz——每秒更新 2 次足够跟手。

旋钮在 Initiator 侧（CS 的调度由发起方说了算），cs_anchor/src/main.c：

/* Procedure interval counts connection events (conn = 20 ms):
 * 5 gave ~10 Hz measured; 25 targets ~2 Hz.
 */
uint16_t desired_procedure_interval = 25;

这里有个坑：样例原代码是 realtime_rd ? 5 : 10，我们的 Reflector 支持 realtime ranging data，所以永远走 5 那个分支。第一次只改了 else 分支 （10→50），频率纹丝不动，白烧了一次固件。改代码前先确认分支真的会被走到。

实测效果：串口打印频率从 ~10Hz 降到 2.07Hz，正好是设计值。

3. 顺手修掉的 Bug：主机复位后 46 秒找不到 Tag

现象

DK（Initiator）按复位键后，Tag 长时间连不回来，必须抠电池重启 Tag。

排查过程

1. 复位 DK 并抓串口日志：DK 在 2.4s 就开始扫描了，但直到 48.6s 才 第一次匹配到 Tag 的广播。

2. 说明 Tag 一直没在广播——它还以为自己连着（僵尸连接），要等 BLE 连接监督超时（supervision timeout）到期才会断开、重启、重新广播。

3. 样例里这个超时设的是 4 秒（BT_GAP_MS_TO_CONN_TIMEOUT(4000)），但叠加 慢速广播（1~1.2s 间隔）和扫描窗口的时机错位，实际拖到 46 秒。

修复

Initiator 侧把监督超时从 4s 改为 1s：

.conn_param = BT_LE_CONN_PARAM(0x10, 0x10, 0, BT_GAP_MS_TO_CONN_TIMEOUT(1000)),

Tag 侧不用改（断连即 sys_reboot 是样例原有逻辑，很合理）。修复后实测 两次：DK 复位 → 重新连上只需 2.3s / 4.3s。

教训：电池设备的"广播降速"和"断连检测速度"是一对耦合参数，改一个的 时候一定要验证另一个。

另一个反复踩的坑（硬件）

Tag 插在 DK 的 DEBUG OUT 排针上时，板载调试器的 SWD 会路由到 Tag 而不是 DK。今天因此烧错目标不止一次。铁律：

• 烧 DK 之前：拔下 Tag

• 烧 Tag：插上 Tag，并且用 -r jlink --dev-id <序列号> 显式指定调试器

4. 优化效果

实测仪器：社区版 PowerAnalyzer（稀饭放姜开源功耗仪），Tag 供电 3.29V， 连接 DK 保持 2Hz CS 测距状态下连续测量 35 分钟取平均：

说明：BLE 射频脉冲是毫秒级窄脉冲，对功耗仪采样率要求高；本文采用 35 分钟长时间积分平均来抑制采样误差。读者复现时建议用 PPK2 等 100kS/s 级仪器交叉验证。

电池寿命粗算（CR2032 按 220mAh）：平均电流每降 100µA，续航多约 90 天量级 的变化——对这个量级的设备，每一百微安都值得抠。

5. 复现要点

source /c/ncs/ncs-env.sh
cd /c/ncs/v3.3.0

# Tag 低功耗固件（nrf54l15tag 自研板）
west build -b nrf54l15tag/nrf54l15/cpuapp cs_tag -d build/cs_tag_lp -p always
# Tag 插 DK 的 DEBUG OUT 上烧录：
west flash -d build/cs_tag_lp -r jlink --dev-id 1057728457

# DK 锚点固件（2Hz 测距 + 1s 监督超时 + LED 距离条）
west build -b nrf54l15dk/nrf54l15/cpuapp cs_anchor -d build/cs_anchor_l15dk -p always
# 烧 DK 前先把 Tag 拔下来！
west flash -d build/cs_anchor_l15dk --dev-id 1057728457

（Windows 跨盘符构建需要 junction 把工程挂进 NCS workspace，见上一篇。）

6. 还能再压吗？

目前还没做的方向，按预期收益排序：

1. 加大 BLE 连接间隔（20ms → 100ms）：连接事件越稀，平均电流越低； 代价是 CS 调度和 GATT 响应变慢。

2. 空闲超时自动断开 + System OFF：长时间测不到就彻底睡死，按键唤醒； 适合"防丢器"这种大部分时间不需要测距的场景。

3. 测距频率跟着场景动态调：静止时 0.5Hz，移动时 2Hz（需要加运动检测 或按距离变化率自适应）。