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 的BISBroadcast Isochronous Stream广播等时流由 Broadcast Source 周期性发送音频数据接收端通过 Broadcast Assistant通常是手机 App扫描并同步到这条流上。这和传统的 A2DP 相比有三个根本区别值得理解连接模型变了接收端不需要和源端建立 ACL 连接只要知道广播的Broadcast ID和BIS 索引就能解出音频类似“收音机听频道”而不是“打电话”。同步机制变了LE Audio 使用isochronous等时通道广播源以固定间隔在事件窗口里发数据接收端锁定的不是简单的 RSSI而是数据包的时序和 CRC所以抗干扰能力比传统广播强很多。音频能力变了编解码强制使用 LC3LC3 在低码率下的音质表现远好于 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 的核心关键点之一是 LC3BT2106C 在硬件上支持低延迟 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 之后重点确认两件事工具链路径是否写死在 Makefile 或者环境变量里。SDK 里通常有个build.sh或者Makefile里面会有类似CROSS_COMPILE /opt/riscv32-elf-gcc/bin/riscv32-unknown-elf-的配置。路径对不上编译会直接在链接阶段崩溃。底层驱动库通常是 .a 静态库的版本是否配套。BT2106C 的 SDK 里有些库区分了是否带 DSP 算子、是否支持 Auracast 功能编译前需要确认自己拿到的固件库文件和时间戳。装完 RISC-V 工具链后进入到 SDK 根目录直接执行make clean make BT2106C_AUCAST_TX1第一次编译大概需要几分钟主要是中间件层代码量不小。编译成功后会生成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或类似命名的配置文件中。核心配置项包括下面几个参数名称典型值说明Broadcast NameAUCAST-DEMO-01接收端 App 里显示的名称最长 32 字节Broadcast ID随机 24bit 值用于接收端唯一识别这条广播建议每次上电随机生成SDU Interval10000 us10ms每个音频帧的时间间隔决定音频延迟Max SDU Size80 bytes单帧音频数据大小和采样率、码率强相关PHY2MBLE 2M PHY吞吐量更高Tx Power0 ~ 8 dBm广播功率影响覆盖范围BIS 数量1这个案例只用一路音频广播很多人不理解 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插线即用信号干净需要外接音源设备音源是电脑/手机/调音台I2S 数字输入无模拟噪声采样率可控需要外接音频 Codec和对讲机/数字音频板对接模拟 MIC无需外设使用方便需要处理增益和底噪语音广播、现场拾音我这次用的 LINE IN因为要测试 MP3 播放效果直接从播放器输出到开发板。音频采样率配置为 48kHzLC3 编码之后通过 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; } }命令格式就用ATAUCAST_START、ATAUCAST_STOP这种解析简单、可读性强。实际开发中控制指令里一定要加上状态查询命令比如ATAUCAST_STATE?否则你分不清广播是没启动还是启动了被异常断掉。4. 调试流程与实测效果分析开发不是“能播就行”广播的效果必须用数据说话。这一节我会把调试用的工具、评测方法、实测数据全部列出来方便你照着复现。4.1 接收端怎么连接和验证Auracast 的接收验证有两种方式我建议两条腿走路手机 App 验证推荐使用 nRF Connect 或者厂商提供的 Auracast 调试 App。打开 App进入 “Auracast” 或 “Broadcast Assistant” 界面就能扫描到正在广播的设备点击加入收听。这种方式直观能快速确认广播名、编码格式、信号强度等基本信息。接收开发板验证手头如果有另一块支持 Auracast 的接收模组可以用它来锁定数据流。把接收端通过 I2S/模拟输出接到音箱声音正常播放说明整条链路是通的。第一轮调试时我建议播一路 1kHz 正弦波测试音而不是直接放音乐。正弦波的频谱单一用失真仪或者音频分析软件一眼就能看出问题如果听到明显的爆音、断音或者噪声排查范围马上就能缩小。4.2 信号覆盖和音频质量实测实测环境是在普通办公室面积约 80 平米中间有隔断和工位。发射端固定在房间一角接收手机拿在手里沿直线往外走记录信号和播放状态。距离米RSSIdBm播放状态音频延迟估算5-45流畅无断音约 30ms10-58流畅无断音约 30ms15-70基本流畅偶发一声卡顿约 30ms20-79播放断续明显掉字约 30ms25-92丢失同步无法收听N/A这个结果符合预期。在 15 米以内Auracast 广播效果稳定音频基本感觉不到延迟。20 米以上开始进入链路预算边界出现丢包。如果你需要更远的覆盖可以考虑两点提高 TX Power但模块天线是板载的蓝牙的 ERP 有明确限制单纯调大会导致杂散超标除非过认证否则不建议。部署 Broadcast RelayAuracast 规范里带有 Relay 转发机制用第二块 BT2106C 模块做中继能实现几百米的覆盖。这个我在后续项目中验证了效果不错。4.3 延迟与并发性能评估延迟测试方法用一根 Y 型音频线一路接到发射端 LINE IN另一路直接接到双通道示波器的一个通道作为参考信号接收端解码出来的音频接示波器另一个通道两路波形的时间差就是整条链路延迟。实测下来从 LINE IN 输入到接收端音频输出的总延迟大约是26ms 左右这在 Auracast 的典型应用场景里表现是不错的。其中 LC3 编码大概占 7msBLE 传输调度占 10ms 左右解码和 FIFO 缓冲占剩下的部分。并发方面我同时用 3 台手机加入收听三台设备都能正常同步输出没有出现一台卡顿拖累其他设备的问题。这也是 Auracast 相对传统 A2DP 分享方案的最大优势——接收端之间是独立同步的互不干扰。4.4 功耗情况因为做的是便携音频广播设备功耗也是绕不开的指标。我用的是一块 3.7V 锂电池供电加了 TI 的 INA226 采样电流几个状态的数据如下工作状态电流mA说明默认广播4dBm约 18 mA峰值电流平均电流看占空比广播 LINE IN 播放约 46 mA音频编解码和 ADC 使能广播 音量最大约 58 mA内部 Class-D 功放耗电明显Sleep 模式约 0.5 mA只保持 RTC 唤醒如果用 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 常见问题速查表现象可能原因排查动作手机收不到广播Extended Advertising 未开启检查 SDK 宏定义和空中抓包广播能收到但无声音BIS 数量或 SDU 配置与编码不匹配核对 codec_cfg 和 SDU Interval断音明显TX Power 过大造成信号反射调整天线匹配网络或降功率声音发闷LC3 码率太低将 bitrate 提高到 96kbps 或以上可听范围只有几米天线匹配不合格确认天线净空区并检查电感电容匹配手机 App 不稳闪退Broadcast Assistant 版本过旧升级手机 App 到新版模块发热量大内部功放持续输出检查音频源是否输出过高电平这些坑很多是我反复试验才定位的如果你的现象和表格对不上欢迎留言交流。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欢迎在评论区聊聊你的方案和踩坑经历一起把这套生态玩起来。
