一辆车上的两套蓝牙：车规 BLE 数字钥匙 × LE Audio 座舱方案

座舱正在同时变“近”和变“响”。

近，是手机还在口袋里，车门已经解锁、迎宾灯已经点亮；响，是主驾听导航，后排各自听播客，互不抢喇叭。前者靠的是低功耗、可量产的车规级 BLE；后者则越来越离不开 LE Audio（LC3 / CIS / BIS / Auracast），同时还得兼容经典 A2DP / HFP。

很多项目会把这两件事当成两个独立课题：数字钥匙找一颗“能过车规”的 BLE，中控娱乐再找一颗“能出声音”的双模音频方案。结果是射频各做各的、休眠策略各写各的、认证节奏也对不齐。真正该问的不是“有没有一颗芯片同时当钥匙又当音响”，而是：一辆车上，近场鉴权与座舱音频，怎样用两套蓝牙能力协同落地。

座舱无线的困局：钥匙要稳，音频要新，消费级方案两边都扛不住

数字钥匙看起来是一次手机握手，实际链路很长：手机钥匙、实体钥匙、车端控制器、天线、休眠唤醒、OTA、学习配对。任何一环都要在实车电磁环境和宽温环境里稳定工作。消费级 BLE 常见卡点是：温宽过不了验证、静态电流控不住、只有“能连”没有迎宾和多钥匙并发。

座舱音频的压力来自另一侧。用户手机仍是 A2DP / HFP 时代的设备，新耳机却已经在推 LC3 和 Auracast；IVI 既要对接 Linux / Android 主机，又要通过 UART + I2S/PCM 把声音交给 DSP。只上经典蓝牙，做不出后排广播；只上 LE Audio，老手机通话和媒体又会掉链。

把两套需求叠到同一辆车上，困局就变成三句话：

• 钥匙链路要车规、低功耗、可测距、可休眠；
• 音频链路要双模、低时延、可广播、可对接主机音频接口；
• 整车方案要把两者分区：门控 / BCM 一侧负责鉴权，中控 / 功放一侧负责声音，而不是把全部协议塞进同一颗芯片硬扛。

先把原理拆开：车规 BLE 和 LE Audio 解决的不是同一类问题

一句话：BLE 负责“人是不是这辆车的主人”，LE Audio 负责“车里的人怎么听”。两者都叫蓝牙，射频频段相近，但认证、天线、休眠和接口完全不是一条 BOM。

三种架构：只做钥匙、只做音频，还是整车协同

座舱可以先选架构，再选模组。车上同样成立——鉴权走车身侧，声音走座舱侧。完整的汽车无线连接方案往往也是按这个分区来搭。

架构 A：车端只有车规 BLE（数字钥匙优先）

手机 / 实体钥匙 → 车端 BLE → BCM / PEPS → 门锁、迎宾、启动授权。

适合数字钥匙、无感进入、共享出行临时授权。音频仍走原车有线或经典蓝牙，不在本方案里升级。链路短、认证目标清晰；代价是座舱听音体验停在旧协议。更完整的钥匙链路见车规 BLE 5.3 数字车钥匙与无感进入方案。

架构 B：中控只有 LE Audio 双模（娱乐优先）

手机 / 耳机 → IVI 双模蓝牙 → I2S / PCM → DSP / 功放。

适合车载音响、后排娱乐、Auracast 多人同听。钥匙仍用实体钥匙或已量产的 PEPS。音频协议可以一次铺到新耳机生态；近场进入体验则不会一起升级。座舱音频侧可对照蓝牙 5.3 LE Audio 智能座舱模块。

架构 C：钥匙 BLE + 座舱 LE Audio 分区协同（推荐整车方案）

车身侧用车规 BLE 做鉴权和迎宾；座舱侧用 LE Audio 双模做媒体、通话和广播。两套能力通过整车网络交换“已授权 / 已上车 / 已离车”状态，而不是互相抢同一根天线。

落地时建议三条硬规则：

1. 射频分区：钥匙天线靠近门把手或立柱，音频天线靠近中控，避免互为噪声源。
2. 电源分区：钥匙侧跟常电 / 休眠策略，音频侧跟 ACC / 主机唤醒。
3. 状态协同：BCM 输出“合法钥匙在车内”后，IVI 才允许自动连耳机、开 Auracast；离车后主动断开广播，降低功耗和误连。

协同可以写成一条很短的状态机，不依赖具体型号：

1. 钥匙侧判定合法钥匙进入近场，BCM 解锁并上报“驾驶员在车侧”；
2. IVI 上电后，音频侧回连车主耳机，或按配置打开发送端 Auracast；
3. 车辆进入 Ready，HFP 接管来电，A2DP / LC3 接管媒体；
4. 离车闭锁后，BCM 通知 IVI 结束广播、断开音频，钥匙侧进入休眠。

四大场景：从靠近车辆，到坐进后排

场景一：无感进入与迎宾——车规 BLE 的主场

车主手机在口袋里接近车辆，车端完成广播、连接、鉴权，再结合 RSSI 判断近场 / 中场 / 远场：近场解锁，中场点亮迎宾，离开后闭锁并休眠。

这里不能用消费级方案硬搬上车。温宽、静态电流、多钥匙学习和 OTA，决定的是能不能量产，而不是 Demo 能不能连上。蓝牙模组只输出连接与距离相关事件，门锁逻辑仍由 BCM 执行。

场景二：主驾导航 + 后排各自听——LE Audio / Auracast 的主场

传统 A2DP 基本是“一对一、占住喇叭”。LE Audio 的 CIS 可做低时延点对点，BIS / Auracast 则可让后排多人同时加入同一路广播，或各听各的，不必抢车载扬声器。

对 IVI 来说，关键不是“支持蓝牙音频”六个字，而是：LC3 + 经典 A2DP / HFP 双栈、I2S / PCM 进 DSP、Linux / Android 可调协议栈。老手机仍走 HFP 通话，新耳机走 LC3，同一块中控不用切两套硬件。

场景三：手机互联与中控娱乐——双模兼容决定投诉率

导航、通话、媒体，大量用户仍然从手机投到中控。CarPlay / Android Auto 之外，蓝牙仍是最低公分母：HFP 负责通话，A2DP / AVRCP 负责媒体，SPP / GATT 负责部分车机数据。

如果中控只做 LE Audio、丢掉经典音频，车主第一周就会在“连不上旧手机”上投诉。双模的意义，是把新旧耳机、新旧手机放在同一条导入曲线里。

场景四：共享出行与车队——钥匙权限和座舱音频要成套交付

分时租赁、试驾车、车队管理，不只是“远程下发一把数字钥匙”。取车时要鉴权开门，上车后希望一键连上司机耳机或车内广播说明；还车后要收回权限、断开音频会话、清掉临时配对。

架构 C 在这里最省事：钥匙侧管权限生命周期，音频侧管会话生命周期，运营平台只对整车状态机下指令，不必在云端分别调两套互不相干的蓝牙栈。

选型怎么走：先定场景，再定接口

不要从芯片型号倒推。按这辆车要先完成哪几件事来选：

1. 只做数字钥匙 / PEPS / 迎宾 → 架构 A。优先看车规、休眠电流、天线与 RSSI。
2. 只做车载音响 / 后排娱乐 / Auracast → 架构 B。优先看双模、LC3、I2S / PCM、主机协议栈。
3. 新车型要同时上数字钥匙和新座舱听音 → 架构 C。两套蓝牙分区部署，用 BCM ↔ IVI 做状态同步，而不是找“全能单芯片”。
4. 已有 PEPS、只升级中控 → 保留原车钥匙链路，座舱单独上 LE Audio 双模，避免把已认证的钥匙方案推倒重来。
5. 已有经典蓝牙音响、只补数字钥匙 → 车身侧补车规 BLE，音频侧维持现状，等下一代 IVI 再升级听音协议。

工程上还有三条共用清单：天线远离高速数字线和电机噪声；钥匙射频按 50Ω 短走线；音频侧做好 BT / Wi-Fi 共存。任何一边的 Demo 距离，都不能直接当实车指标。

FSC-BT3721V / FSC-BT1211 在座舱中的技术定位

以上原理落到具体器件，飞易通 FSC-BT3721V 与 FSC-BT1211 是车规数字钥匙与座舱 LE Audio 方向较典型的一对模组，便于理解架构 C 的实际参数水平：

在架构 C 中，它们适合这样分工：

• 车身侧 · FSC-BT3721V：UART / SPI 接 BCM，跑 BLE 鉴权与距离相关事件，负责手机钥匙、实体钥匙学习、迎宾触发和休眠唤醒
• 座舱侧 · FSC-BT1211：HS-UART + I2S / PCM 接 IVI 与 DSP，跑 LE Audio 与经典音频双栈，负责通话、媒体和 Auracast 广播
• 整车网络：BCM 与 IVI 同步“已授权 / 已上车 / 已离车”，钥匙侧不管声音，音频侧不负责开锁

需要强调的是：模块选型只是第一步，座舱体验还取决于主控算力、天线布局、并发电测与整车认证。这两颗模组的价值在于把车规 BLE 与 LE Audio 双模分别封装为可量产的无线子系统，适合数字钥匙控制器和 IVI 音响等产品形态，而非替代完整的系统设计验证。

三点结论

• 数字钥匙和座舱音频都叫蓝牙，但不能用同一套指标选型。 前者看车规、功耗和测距，后者看双模、LC3 和音频接口。
• 整车更适合架构 C：车身 BLE 与座舱 LE Audio 分区，用状态同步，而不是单芯片硬兼。 射频、电源、休眠策略分开，认证节奏才可控。
• 落到器件时，可以用一对现成模组对照参数水平： 钥匙侧 FSC-BT3721V，座舱侧 FSC-BT1211。选型只是第一步，天线、休眠和整车认证仍然要按实车做完。

座舱体验的差距，最终不会写在参数表第一行，而会写在两件用户无感知的事上：走近时门开得够不够干脆，坐下后声音连得够不够稳。把车规 BLE 和 LE Audio 当成一套技术方案来做，这两件事才能在同一辆车上同时成立。