数字钥匙系统架构
数字钥匙中，蓝牙协商出UWB的参数后，开始测距任务，当测距任务完成后，就进入低功耗吗 ？当下次拿着钥匙走到车旁边时，钥匙被车里面的蓝牙广播唤醒，是这个逻辑吗 ？
我给你讲行业真正在用的数字钥匙（CCC / Qorvo / Decawave 标准流程），
不讲虚的，完全对应你腰带 + nRF52 + DW3000 场景，一看就懂。
一句话总流程
BLE 全程低功耗待机 → 检测靠近 → BLE 安全鉴权 → 通过 BLE 唤醒 UWB → UWB 测距 → 结果通过 BLE 回传 → 解锁/执行动作
一、硬件结构（车 + 钥匙）
- 车辆端： BLE主机 + UWB Anchor
- 数字钥匙端（手机/卡片）：
- BLE（nRF52832/833）
- UWB（DW3000/DW3110）
- 共用一个MCU控制两者
BLE 负责：发现、唤醒、安全、通信
UWB 负责：高精度测距（厘米级）
二、完整真实协同流程（最标准）
阶段1：全系统深度休眠（极低功耗）
- 车：BLE 扫描监听，UWB 关闭
- 钥匙：BLE 低功耗广播 / 待机，UWB 完全断电
- 电流：几 µA
这一步只能靠 BLE，UWB 根本不开。
阶段2：靠近 → BLE 发现彼此
- 车主靠近车辆
- 钥匙 BLE 广播 / 车辆 BLE 扫描
- 双方通过 BLE 建立连接
- 连接后，BLE 进入低延迟连接间隔
→ 这一步叫：** proximity detection（接近检测）**
阶段3：BLE 安全鉴权（核心！UWB 干不了这个）
- 车 ↔ 钥匙通过 BLE 做
- 身份认证
- 加密会话密钥协商
- 防中继攻击校验
- 鉴权成功 → 才允许开启 UWB
- 鉴权失败 → 永远不开 UWB
→ 安全完全由 BLE 保障。
阶段4：BLE 指令唤醒 UWB（你问的核心）
- 车通过 BLE 下发指令 给钥匙：
开始UWB测距 → 信道5 / 帧间隔20ms / 测距5次 - 钥匙端 MCU 收到 BLE 指令后：
- 给 DW3000 上电
- 初始化 SPI
- 配置 UWB 信道、帧结构
- 启动 UWB 测距流程
这就是：
BLE 唤醒 UWB
阶段5：UWB 开始测距（和蓝牙无关）
- 车端 Anchor 发 UWB Poll
- 钥匙 Tag 回 Response
- 最终在钥匙端算出距离
- 连续测多帧，滤波，得到稳定值
UWB 自己完成，蓝牙不参与测距。
阶段6：测距结果通过 BLE 回传车辆
- 钥匙得到最终距离：55cm
- 钥匙通过 BLE Notify 发给车辆
- 数据加密、带序号、带校验
→ UWB 自己不能传结果，必须靠 BLE
阶段7：车辆判断距离 → 执行解锁
- 车收到距离 ≤ 1米
- 判定：合法钥匙在旁边
- 执行：解锁车门 / 允许启动
阶段8：离开后休眠
- 远离车辆
- BLE 断开
- 钥匙端 MCU 关闭 UWB 电源
- 回到深度休眠
三、为什么必须这样协同？（核心原因）
1. UWB 不能一直开
- UWB 工作电流 80~150mA
- BLE 待机 1~10µA
差 10000 倍
→ 必须 BLE 唤醒，不能常开
2. UWB 不能做安全
UWB 只有测距，没有加密体系
→ 必须 BLE 做鉴权
3. UWB 无法传输测距结果
UWB 是测距用的，不是长距离通信用的
→ 必须 BLE 传数据
4. 多设备定位必须蓝牙同步
车辆多天线 UWB 需要同步时隙
→ 同步信息由 BLE 下发
四、对应到你的智能腰带
流程一模一样：
- 主机 BLE 连接 从机 BLE
- 主机通过 BLE 下发指令：启动 UWB 测距
- 从机 nRF52 唤醒 DW3000
- DW3000 双向测距
- 从机算出距离
- 从机通过 BLE Notify 发给主机
- 主机上传云端
完全就是简化版数字钥匙系统。
五、最精炼总结（可直接写方案）
- BLE 负责低功耗待机、设备发现、安全鉴权、指令下发、数据回传
- UWB 负责厘米级测距
- BLE 是指挥官，UWB 是士兵
- BLE 唤醒 UWB，UWB 测距，结果再由 BLE 带走
- 两者缺一不可，这就是数字钥匙/穿戴UWB设备的标准架构。
不管是智能腰带，还是数字钥匙，nordic都是做从机。车上面的蓝牙设备是主机。
浙公网安备 33010602011771号