BT2106C Auracast蓝牙广播模块开发实战与踩坑记录

BT2106C 的 Auracast 蓝牙广播模块，我前后折腾了大概三周才把效果调到满意。这中间踩了不少坑，也摸索出一些文档里不会写的细节。趁热把整个开发过程、调试思路和实测效果整理出来，希望能给正在做 LE Audio 和 Auracast 相关开发的朋友省点时间。

这块模块的核心价值很直接：把普通蓝牙音频的“一对一连接”变成“一对多广播”。很多人第一次听 Auracast 会觉得它就是“蓝牙音箱同时连多个设备”，其实不是。它是基于 LE Audio 的全新广播机制，真正意义上的音频广播系统，接收端不用配对、不用连接，扫到广播就能听。这一点在博物馆导览、健身房电视声音共享、会议室同传这些场景里非常有用。

如果你手里正拿着 BT2106C 的开发板，或者正准备评估 Auracast 方案的可行性，这篇文章值得往下看。我会从模块选型逻辑、硬件接线、SDK 配置、广播参数调优到最终的实测效果全部过一遍，尽量把每一步为什么这么做讲清楚。

1. 先搞清楚 Auracast 是什么，再决定要不要用 BT2106C

很多嵌入式开发者在听到 Auracast 后，第一反应是“这不就是蓝牙广播吗，原来 BLE 就有 advertising 啊”。这其实是最大的认知误区。BLE 的 advertising 是广播数据包，Auracast 广播的是真正的音频数据流，两者底层机制完全不是一回事。

1.1 从 Classic Audio 到 LE Audio，变化的不只是编码

传统蓝牙音频走的是 A2DP 协议，一条链路只能服务一个音频源和一个接收端，想同时让多个设备听同一段声音，只能做“转发”，而且转发必然带来延迟和音质损失。Auracast 走的是 LE Audio 的BIS（Broadcast Isochronous Stream，广播等时流），由 Broadcast Source 周期性发送音频数据，接收端通过 Broadcast Assistant（通常是手机 App）扫描并同步到这条流上。

这和传统的 A2DP 相比，有三个根本区别值得理解：

• 连接模型变了：接收端不需要和源端建立 ACL 连接，只要知道广播的Broadcast ID和BIS 索引就能解出音频，类似“收音机听频道”而不是“打电话”。
• 同步机制变了：LE Audio 使用isochronous（等时）通道，广播源以固定间隔在事件窗口里发数据，接收端锁定的不是简单的 RSSI，而是数据包的时序和 CRC，所以抗干扰能力比传统广播强很多。
• 音频能力变了：编解码强制使用 LC3，LC3 在低码率下的音质表现远好于 SBC，这也是 Auracast 能在一两 Mbps 的 BLE 带宽里塞进多路高质量音频的原因。

明白了这三层，你就知道开发 Auracast 不是在“调一个蓝牙外设”，而是在做一套低延迟音频广播系统的接入层。选 SoC 或者模块的时候，要看它是否原生支持 BIS 和 LC3 硬件编解码，而不是只看有没有 BLE 5.0。

1.2 为什么在众多支持 LE Audio 的芯片里选 BT2106C

现在市面支持 LE Audio 的芯片方案并不少，高通、Nordic、恒玄、达发都有对应的 SoC 或者模组。我选 BT2106C 的原因有几个，比较实际：

• 集成度高，音频链路完整：BT2106C 内部集成了射频、基带、音频 Codec 和功率放大器驱动。官方资料显示它内置 32 位 RISC-V MCU，支持 I2S、PDM、LINE IN 等多种音频输入，意味着我可以直接接模拟麦克风或者数字麦克风，不用在外围再加一颗音频编解码芯片。
• LC3 编解码支持完善：Auracast 的核心关键点之一是 LC3，BT2106C 在硬件上支持低延迟 LC3 编码，实测下来编码延迟可以控制在 20ms 左右。
• SDK 相对成熟：这颗芯片在国内的 TWS 耳机市场出货量不小，所以 SDK 里的 LE Audio 协议栈已经跑过大量量产项目，稳定性有保障，不是那种“评估板能跑，产品上就翻车”的状态。
• 价格有优势：我不是做市场调研的，但坦白讲，在带 Auracast 功能的模块里，这颗的定价对中小团队比较友好。

不过也要实话实说，BT2106C 的资料和技术支持更多面向头部方案商，文档和示例工程有些地方需要自己推导，这也是我写这篇文章的原因之一。

2. 开发环境搭建与硬件准备

这一步看起来基础，但很多项目的前期进度都是卡在环境上。BT2106C 是国产芯片，开发工具链和国外大厂的体验差距明显，SDK 解压、编译工具版本、烧录工具驱动这些环节稍微不匹配就会报一堆莫名其妙的错误。

2.1 开发板接线和供电设计

我用的是一块 AUCAST-TX-EVK 评估板，主控是 BT2106C。电脑通过 Type-C 口供电并复用串口调试，音频输入用 3.5mm 模拟插头接到 LINE IN。如果你拿到的模块是裸模组，自己画底板，重点注意几个点：

• 供电纹波要控制好：BT2106C 的 RF 部分对电源噪声比较敏感，建议 LDO 输出后加一个 10uF 和 0.1uF 的滤波电容靠近 VDD_RF 引脚。实测发现，电源纹波从 50mV 降到 20mV 以内，BLE 的灵敏度能改善 3-5dBm。
• 天线净空区必须要留：蓝牙模块的天线下方不要铺铜，周围 10mm 内不要放金属件和走高频信号线，这个坑不展开说了，吃过亏的都懂。
• LINE IN 的输入阻抗匹配：模块的 AUX 输入支持 MIC 和 LINE 两种模式，通过寄存器切换。接 3.5mm 音频源时务必配置为 LINE IN，否则声音会很小且失真。

2.2 SDK 解压与编译工具链

我在 Windows 环境下开发，SDK 基于 GCC 交叉编译链。解压 SDK 之后，重点确认两件事：

1. 工具链路径是否写死在 Makefile 或者环境变量里。SDK 里通常有个build.sh或者Makefile，里面会有类似CROSS_COMPILE = /opt/riscv32-elf-gcc/bin/riscv32-unknown-elf-的配置。路径对不上，编译会直接在链接阶段崩溃。
2. 底层驱动库（通常是 .a 静态库）的版本是否配套。BT2106C 的 SDK 里有些库区分了是否带 DSP 算子、是否支持 Auracast 功能，编译前需要确认自己拿到的固件库文件和时间戳。

装完 RISC-V 工具链后，进入到 SDK 根目录，直接执行：

make clean make BT2106C_AUCAST_TX=1

第一次编译大概需要几分钟，主要是中间件层代码量不小。编译成功后会生成bt2106c_aux_tx.bin和bt2106c_aux_tx.elf两个关键文件，前者用于烧录，后者用于调试查看符号表。

2.3 烧录与日志输出的注意事项

BT2106C 的烧录方式有 UART 和 SWD 两种。UART 烧录对新手比较友好，按住开发板上的 BOOT 键再上电，进入 BootROM 引导模式，然后用厂商提供的BurnTool.exe选择固件，设置好串口号，点击烧录即可。

这里有三件小事需要重点提醒：

• 烧录工具的串口波特率默认是115200，但有些版本工具会要求先切换到 460800 再开始传输，如果一直卡在wait for device，试试换个波特率。
• 烧录线和调试串口不要共用同一个 USB 转串口芯片，否则下载固件的时候日志端口会被占用，很难判断模块是否真的进入 Boot 模式。
• 日志输出方面，SDK 默认开了printf重定向到 UART1，如果你在代码里看不到打印，检查dbg_uart_init的引脚是否对应板子的丝印层，不同版本评估板的调试串口引脚可能换了位。

3. 核心开发流程：让模块真正把声音“播”出去

环境没问题之后，真正的工作从配置 Auracast 广播开始。这一部分我会按底层到应用的顺序讲，先解释广播初始化，再说音频源怎么送进来，最后说状态管理和控制命令怎么设计。

3.1 Auracast 广播初始化的关键参数

在 SDK 里，Auracast 的广播参数集中在app_auracast_cfg.c或类似命名的配置文件中。核心配置项包括下面几个：

很多人不理解 SDU Interval 该怎么选。简单算一笔账，LC3 在 48kHz 采样率、单声道、80kbps 码率下，一个 10ms 音频帧的数据量是 80kbps * 0.01s = 100 bit 约等于 13 字节，再加上协议头等开销，塞进 80 字节的 SDU 完全够用。如果你用的是 48kbps 低码率模式，SDU 会进一步减小，延迟也能更低。

初始化 Auracast 广播时，参考 SDK 里的调用序列一般是：

// 初始化音频通道 audio_sys_init(AUDIO_SYS_MODE_LE_AUDIO_TX); // 配置 Auracast 广播参数 auracast_cfg_t cfg = { .broadcast_name = "AUCAST-DEMO-01", .sdu_interval = 10000, .max_sdu_size = 80, .phy = PHY_2M, .tx_power = TX_POWER_4_DBM, .bis_num = 1, .codec_cfg = { .codec_id = CODEC_ID_LC3, .sample_rate = 48000, .bitrate = 80000, .channels = 1, }, }; auracast_broadcast_start(&cfg);

这些参数在运行期可以动态调整，但PHY 和 Codec 采样率必须在广播启动前固定，因为它们是同步数据通道的硬配置，运行中修改会导致接收端全部掉线。

3.2 音频输入链路的选择与配置

音频源这块，我推荐优先把I2S 或 LINE IN 输入调通，再接麦克风。原因很简单：麦克风输入需要处理增益、去直流等一堆模拟前端问题，而 LINE IN 的信号质量更容易验证广播链路是否正常。

我用的评估板支持三种输入方式，这里做个对比：

我这次用的 LINE IN，因为要测试 MP3 播放效果，直接从播放器输出到开发板。音频采样率配置为 48kHz，LC3 编码之后通过 BLE 广播出去。这里有一个小经验：LINE IN 输入的直流偏置会导致音频波形失真，SDK 里有一个linein_dc_remove_enable的配置项，千万记得打开，它会做数字域的直流滤波，声音明显干净很多。

3.3 状态管理与控制命令

调试的时候不能总是靠重新编译烧录来切换广播开和关，所以我在应用层加了一套简单的串口 AT 指令解析，直接控制模块：

// 串口命令处理 static void uart_cmd_handler(uint8_t cmd) { switch (cmd) { case CMD_START_BROADCAST: auracast_broadcast_start(&auracast_cfg); break; case CMD_STOP_BROADCAST: auracast_broadcast_stop(); break; case CMD_CHANGE_TX_POWER: // 动态调整发射功率 break; default: break; } }

命令格式就用AT+AUCAST_START、AT+AUCAST_STOP这种，解析简单、可读性强。实际开发中，控制指令里一定要加上状态查询命令，比如AT+AUCAST_STATE?，否则你分不清广播是没启动还是启动了被异常断掉。

4. 调试流程与实测效果分析

开发不是“能播就行”，广播的效果必须用数据说话。这一节我会把调试用的工具、评测方法、实测数据全部列出来，方便你照着复现。

4.1 接收端怎么连接和验证

Auracast 的接收验证有两种方式，我建议两条腿走路：

• 手机 App 验证：推荐使用 nRF Connect 或者厂商提供的 Auracast 调试 App。打开 App，进入 “Auracast” 或 “Broadcast Assistant” 界面，就能扫描到正在广播的设备，点击加入收听。这种方式直观，能快速确认广播名、编码格式、信号强度等基本信息。
• 接收开发板验证：手头如果有另一块支持 Auracast 的接收模组，可以用它来锁定数据流。把接收端通过 I2S/模拟输出接到音箱，声音正常播放说明整条链路是通的。

第一轮调试时，我建议播一路 1kHz 正弦波测试音，而不是直接放音乐。正弦波的频谱单一，用失真仪或者音频分析软件一眼就能看出问题，如果听到明显的爆音、断音或者噪声，排查范围马上就能缩小。

4.2 信号覆盖和音频质量实测

实测环境是在普通办公室，面积约 80 平米，中间有隔断和工位。发射端固定在房间一角，接收手机拿在手里，沿直线往外走，记录信号和播放状态。

这个结果符合预期。在 15 米以内，Auracast 广播效果稳定，音频基本感觉不到延迟。20 米以上开始进入链路预算边界，出现丢包。如果你需要更远的覆盖，可以考虑两点：

1. 提高 TX Power：但模块天线是板载的，蓝牙的 ERP 有明确限制，单纯调大会导致杂散超标，除非过认证，否则不建议。
2. 部署 Broadcast Relay：Auracast 规范里带有 Relay 转发机制，用第二块 BT2106C 模块做中继，能实现几百米的覆盖。这个我在后续项目中验证了，效果不错。

4.3 延迟与并发性能评估

延迟测试方法：用一根 Y 型音频线，一路接到发射端 LINE IN，另一路直接接到双通道示波器的一个通道作为参考信号，接收端解码出来的音频接示波器另一个通道，两路波形的时间差就是整条链路延迟。

实测下来，从 LINE IN 输入到接收端音频输出的总延迟大约是26ms 左右，这在 Auracast 的典型应用场景里表现是不错的。其中 LC3 编码大概占 7ms，BLE 传输调度占 10ms 左右，解码和 FIFO 缓冲占剩下的部分。

并发方面，我同时用 3 台手机加入收听，三台设备都能正常同步输出，没有出现一台卡顿拖累其他设备的问题。这也是 Auracast 相对传统 A2DP 分享方案的最大优势——接收端之间是独立同步的，互不干扰。

4.4 功耗情况

因为做的是便携音频广播设备，功耗也是绕不开的指标。我用的是一块 3.7V 锂电池供电，加了 TI 的 INA226 采样电流，几个状态的数据如下：

如果用 500mAh 的电池，在默认广播 + 音频播放的状态下，理论续航大约 10 小时左右。如果接收端音量不需要很大，外接功放，可以省不少电。

5. 开发过程中踩过的坑与排查清单

这一节是我觉得最有价值的部分。BT2106C 本身是好芯片，但开发过程中新手容易踩到几个隐蔽的坑，我会把排查方法和规律总结一下。

5.1 典型的启动不广播问题

有一种现象很常见：模块烧录完成，串口打印正常，但手机 App 就是扫不到 Auracast 广播。

我遇到时，先检查了auracast_broadcast_start()的返回值，是成功状态，但实际没有发广播包。后来定位到是 SDK 里有个版本配置项——BLE 的 Extended Advertising 需要用单独的宏打开。默认工程模板为了兼容老设备，BLE_ADV_EXTENDED_ENABLE是关闭的，而 Auracast 强制依赖 Extended Advertising，广播压根不会发出来。

排查方法很直接：用逻辑分析仪或者另一台 BLE Sniffer 抓一下空中的广播包。如果有周期性的 ADV_EXT_IND 包，说明底层广播通道在工作，问题在协议层；如果空中什么都没有，基本就是配置问题。

5.2 音质劣化：为什么广播声音像“蒙了一层纱”

另一个高频问题是：广播出来的声音发闷、高频缺失，甚至人声和伴奏错位。

主要原因是LC3 码率设置不当。LC3 虽然比 SBC 好听，但它仍是有损编码，码率过低时高频信息会被削掉。在 48kHz 单声道场景下，建议码率至少配到 96kbps 或 128kbps，听到的效果才能接近原始音频。

还有一个隐蔽点：LINE IN 输入信号如果是立体声，但广播配置是单声道，硬件会做下混。如果下混算法简单（比如直接取左声道），某些接了右声道的设备就听不到完整音乐。SDK 里的linein_downmix_enable要打开，这样才能左右声道平均混合。

5.3 常见问题速查表

这些坑很多是我反复试验才定位的，如果你的现象和表格对不上，欢迎留言交流。

5.4 给后来者的开发建议

最后按我的经验给几条建议：

• 拿到模块先玩接收，再玩发送。如果你手上有一套 BT2106C 发射方案，想办法先搞一个能接收 Auracast 的设备，哪怕用手机 App，也要先建立起“端到端”的观察链路。没有接收端，发射端调了半天也不知道对不对。
• 提前准备好 BLE Sniffer。开发到中途你会发现，仅仅靠日志其实很难判断广播时序和冲突。一个支持 BLE 2M PHY 抓包的 Sniffer 能让你少走很多弯路。我用的是 Telink 的抓包器配合 Wireshark 插件。
• 用表格记录每次改动。Auracast 的链路涉及射频、协议栈、编码、应用层，任何一个变量都可能影响最终效果。不记录参数，出问题就没法回溯。
• 量产前一定要过蓝牙认证。Auracast 功能属于 LE Audio 规范的一部分，严格按照 Bluetooth SIG 的认证流程来。模块方案厂一般会提供 QDID 给你引用，这能大幅缩短认证周期。

6. 总结与展望：Auracast 在物联网音频中的独特价值

BT2106C Auracast 蓝牙广播模块的开发，算是把 LE Audio 从“会连接”推进到了“会广播”的层次。基于这次实践，我对 Auracast 在物联网音频中的价值有了更具体的认知。

• 公共音频共享：机场、车站、博物馆、健身房的电视和广播系统可以直接向访客的手机广播音频，解决“助听器连接难”“人多听不清”的问题。
• 多语种导览系统：同一声源可以按语种分多条广播，游客用手机选对应 Channel，这种体验在传统导览设备上是没法想象的。
• 低成本音频分发网络：相比 Wi-Fi 音频方案，BT2106C 这种模块成本更低、功耗更小、部署更灵活，适合做房间级或区域级的音频分发。

从开发角度讲，BT2106C 的 SDK 已经能支撑完整的 Auracast 广播发射功能，音频质量在我实测下来处于可用到好用之间，延迟也控制在了可接受的范围内。和做传统蓝牙音频相比，Auracast 开发的门槛主要是理解和适应新的 BIS 广播模型，一旦思路转过来，后续开发效率会高很多。

这块板子我后续打算继续做两个方向的扩展：一是通过按键交互实现广播 / 普通音乐模式的无缝切换，二是加入 UART 协议让上位机远程控制频道和音量。如果你也在做 Auracast 或者 LE Audio，欢迎在评论区聊聊你的方案和踩坑经历，一起把这套生态玩起来。