基于BT2106C的Auracast蓝牙广播模块开发实战与避坑指南

最近花了大概两周多时间，把手头这块BT2106C Auracast蓝牙广播模块从评估板一路调到了能小批量打样的状态。先说结论：公共广播和加密广播两条链路都跑通了，空旷环境下手机接收距离实测约40米，隔一堵砖墙大概15米左右，从音源到耳机出声的体感延迟在60-80ms之间。用一句话来概括这个项目，就是利用支持LE Audio的BT2106C芯片，做了一颗只干Auracast广播这一件事的小模块，把外部音频采集进来、用LC3编码后以BIS广播流发出去，让范围内的手机、耳机、助听器直接收听。

这篇文章不是产品发布会通稿，我把这次开发过程中的选型思路、硬件设计、软件配置、实测数据以及踩过的坑都整理出来。如果你正打算做蓝牙音频广播、助听器TV发射器、展厅导览、会议室同传这类设备，这篇应该能帮你少走不少弯路。

1. 选型与整体设计：为什么是BT2106C，Auracast解决什么问题

1.1 Auracast在现有蓝牙音频版图里的位置

先说点背景知识。传统蓝牙音频走的是A2DP，一对一的连接模式。手机连耳机、连音箱，一个源只能对应一个接收端。带着无线耳机走到电视机旁边想换着听，得先断开重连，整个过程非常折腾。Auracast把这件事改成了广播制式，相当于在一个无线电频段上持续播放音频，谁在覆盖范围内谁就能接收。基于LE Audio里的BIS（Broadcast Isochronous Stream，广播同步流），一个发射端可以把多路音频流同时广播出去，接收端只需同步到这个广播流，不需要建立传统意义上的蓝牙连接。

这个特性对应的典型场景非常明确：医院叫号、博物馆导览、健身房电视机音频、高铁候车大厅广播、助听器用户直接拾取公共场所的音频信号。甚至会议室里做同声传译，也可以通过Auracast通道对外广播多语言音频，听众用手机或耳机自由选择信道。和传统一对一蓝牙音频相比，Auracast最大的价值就是“一对多、低延迟、免配对”。

1.2 BT2106C这颗芯片到底强在哪

选BT2106C之前，我把市面上支持Auracast的方案大致扫了一遍。大致分两类：一类是手机主控芯片自带的蓝牙音频方案，功能强但外围复杂，做产品要支付高昂的授权和BOM成本；另一类是面向音频外设的BLE音频SoC，集成了射频、MCU、DSP和音频编解码器，一片就能干活。BT2106C属于后者。

这颗芯片是中科蓝讯的产品，支持蓝牙5.4和LE Audio，内部集成了射频收发器、32位MCU和用于LC3编解码的音频DSP。对我这个项目来说极具吸引力的一点是单芯片方案：外部只需要一颗晶振、供电电路、天线和一个音频输入接口，不需要再挂单独的蓝牙协议栈芯片或者音频编解码芯片。布线面积能压到非常小，很适合做得像U盘那么大。

另外值得说的一点是功耗和整套SDK的学习成本。BT2106C在纯广播模式下的电流实测在个位数毫安级别，这对手持或者电池供电的产品非常友好。SDK层面，中科蓝讯已经提供了LE Audio相关的协议栈和Auracast示例工程，不太需要从零去啃BLE Audio规范，开发者可以把主要精力放在应用层和射频调试上。

1.3 系统级设计是纯发射端还是收发一体

项目刚开始我犯过纠结，要不要做成“收发一体”——既能发射Auracast广播，又能接收Auracast广播，一个模块两个角色。后来想明白了：模块的定位是“广播信号源”，用于替代市场上传统的FM调频发射器或者红外导览设备，所以必须优先保证发射链路的稳定和音质。接收能力只在调试阶段临时开启，用来做往返测试。这样做也简化了软件状态机，避免了收发模式切换时可能带来的协议栈冲突。

所以最后的系统框架是：外部音频进模块，经ADC采样后交给DSP做LC3编码，按BIS时隙打包到空口，模块自身不做解码不播声音。整个系统的工作流程是单向的，这对代码逻辑、内存占用和功耗控制都友好得多。

2. 硬件设计细节：原理图、PCB和天线那些事

2.1 最小系统搭建：供电、晶振、复位

BT2106C的最小系统并不复杂。供电部分我用了一颗低噪声LDO，把外部4.2V锂电池电压降到3.3V，同时给数字电源和射频电源分别做了LC滤波。这一块有多重要我在后面踩坑的部分会详细说，射频发射器在数据包发射瞬间电流会有几十毫安的瞬态跳动，如果电源纹波太大，会导致射频输出频谱变差、接收端误码率升高，表现就是距离拉不远。

晶振选择需要特别注意精度。Auracast接收端要在一个时间窗口内精确采样接收数据，对发射端时钟的稳定性有要求。我用的外部晶振是24MHz，精度选为±10ppm级别。实际调试中我发现，晶振精度不够时最典型的症状是：接收端刚同步上的时候声音正常，但十分钟后开始出现偶发卡顿，甚至彻底丢同步。这是因为收发两端时钟漂移累积到一定程度，超出了接收端的容忍范围。

复位电路我用了最简单的RC复位加一个外部看门狗。实际调试中看门狗喂狗时间配置得非常宽松，因为在广播模式下一旦进入稳定工作态，协议栈本身不太会卡死，反而是我们自己加的一些音频处理逻辑容易出问题。

2.2 天线匹配与射频走线经验

天线是这类小模块最容易翻车的地方。为了控制成本，初版我直接用了PCB板载天线，双面FR4板材，板厚1.0mm。板载天线需要考虑净空区，天线正下方不能铺地和走线。我做的第一版样片就因为天线跟前的地铜皮靠太近，实测距离直接掉了三分之一。

后来我重新layout，在天线区域画了完整的净空区，同时在天线馈点后面预留了π型匹配网络，就是串联一个电感、并联两个电容的经典结构。板上预留这个位置非常有必要，因为板载天线的实际谐振频率会受外壳、周边金属件、电池位置影响，没有匹配网络就只能重新打板，有的话可以用网络分析仪微调匹配。我调完之后的S11回波损耗做到了-10dB以下，也就是反射功率不到10%，整体效率才算能接受。

射频走线从芯片天线引脚到匹配网络再到天线馈点，这段线要控制在50Ω阻抗。在没有专业阻抗计算软件的情况下，可以按常规经验走：线宽0.3mm左右，参考地要完整连续，尽量短。我还做过一个对比测试，把这段走线从8mm缩短到3mm，其他条件不变，SPP和BIS的丢包率有了肉眼可见的改善。

2.3 音频采集链路：模拟输入和数字输入怎么接

这个模块的有趣之处在于它只是个“音频搬运工”，所以输入端的信号质量会直接影响最终的广播效果。我这边做了两个版本。第一版是模拟Line-in输入，外部音源（比如电视耳机口、调音台AUX口）通过3.5mm插座进入模块，经过一圈隔直电容和分压电阻，送到芯片内置ADC。第二版是PDM数字麦克风输入，用于需要自带拾音的场景，比如课堂上老师把模块挂在脖子上，直接用板载麦克风采集人声广播给学生耳机。

模拟输入需要注意输入电平匹配。普通电视耳机口的输出幅度和满幅ADC输入范围不一定一致。我加了一颗运放做可调增益，通过两个GPIO控制增益档位，实测下来能适配大多数常见音源。数字麦克风输入相对省心，PDM接口抗干扰能力比模拟线强得多，布线要求没那么苛刻，所以如果产品形态允许，我更建议用数字麦克风直接采集。

这里展开说一个很多新手忽略的问题：音频输入的地线一定要跟模块的数字地单点连接。如果模拟地和数字地直接大面积相连，板上的开关噪声和高频谐波会耦合进模拟前端，最终广播出去的声音会有持续的“嘶嘶”底噪。我最后的处理方法是：模拟区独立一小块地岛，通过一个0Ω电阻单点连接到主地，效果立竿见影。

3. 软件配置与广播参数调优

3.1 SDK工程搭建和Auracast核心流程

软件方面，整个工程是在厂商SDK基础上搭建的。先把Auracast广播示例工程编译点亮，然后逐步裁剪掉测试代码，加入自己的应用逻辑。使用BT2106C SDK时有个点需要注意：不要直接用官方默认配置去开发产品，因为示例工程里很多参数是为了兼容性测试设置的，比如广播间隔、PDU长度都偏保守，直接套用到产品上会牺牲实时性和功耗。

Auracast发射端的核心流程可以分为四步：初始化协议栈和射频、配置BIG参数开始周期性广播、采集音频数据并做LC3编码、把编码后的音频帧按照BIS时隙顺序发送出去。这里最难的地方在于第三和第四步之间的配合。LC3编码是一帧一帧出的，每一帧时长是7.5ms或10ms，而BIS事件也有自己的时间间隔（iso_interval）。两者必须对齐，不能让编码器产帧速率低于或者高于空口发送速率，否则会出现延迟累积或者丢帧。

我在代码里用了一个带时间戳的环形缓冲区来解耦编解码和射频发送。编码器按自己的节奏把帧填进缓冲区，发送回调按BIS事件节奏从缓冲区取帧。这样即使偶尔遇到MCU被其他中断打断，也不会漏掉某一帧的发送窗口。这个设计思路对BLE音频开发通用性很强，强烈建议保留。

3.2 BIS与BIG参数配置：间隔、分组、重传

BIG（Broadcast Isochronous Group）是BIS的集合，可以把多个逻辑音频流打包成一组同时广播。我们产品核心功能是单信道广播，所以就配置了一组BIG，里面只含一个BIS。BIS的iso_interval我一开始按默认的20ms配置，后来实测发现这个间隔偏大，因为LC3帧时长是10ms，一个20ms的间隔里要装两帧音频数据，接收端的解码缓存也会相应增加，最终延迟比预期大了不少。改到10ms间隔一帧一帧发之后，端到端延迟明显降下来了。

重传参数直接决定接收端在复杂环境下的表现。BIS广播模式下接收端不会发送任何确认信息给发射端，它就是纯单向的“开枪”，所以必须在数据包里做冗余。btstack里对应的是max_pdu_sdu和重传次数。我把重传次数设为1，相当于每一帧数据发送两次，冗余翻倍，代价是空口占用时间变长。在2.4GHz环境比较复杂的写字楼里，这个冗余设置对避免瞬时卡顿非常有帮助。

另外一个是广播周期（Periodic Advertising Interval，PA Interval）。接收端初始扫描到这个广播需要的参数越密，越容易被发现，但同时会增加功耗和无线占用。我测试下来PA Interval设在100ms比较合适，手机开Auracast扫描App几乎能秒搜到，功耗也就多消耗不到1mA。如果你做的是低功耗电池设备，可以把PA Interval放到200ms到300ms，以不易发现为代价换来更长的续航。

3.3 公共广播和加密广播怎么选，配起来差别在哪

Auracast支持两种广播类型：公共广播和加密广播。

公共广播最简单。四个广播参数——广播名、广播语言、节目类型和一个十六进制ID——直接在广播包里周期广播出去，任何支持Auracast的设备都能搜到并直接收听。我测试时用的就是公共广播，手机端用系统设置或第三方App进去就能看到音频广播，点一下就出声，体验真的有点像“蓝牙版收音机”。

加密广播则多一层保护。广播内容用应对密钥加密，接收端必须拿到这个密钥才能解码音频。从实现角度看差别不只是“加个密码”那么简单。加密广播要求接收端在初始同步的时候从某个“帮助设备”手里获取密钥，这个帮助设备通常是手机，手机通过广播同步传输（PAST）把BIG相关参数和广播码传给接收端耳机/助听器。也就是说，对于加密广播，你手边得有一台支持Auracast Assistant功能的手机来“授权”接收端加入收听。

产品角度怎么选？如果应用是开放广播，例如商场广播、博物馆导览，公共广播就够了；如果应用是VIP会议室同传、收费内容推送，那就必须上加密广播。我这次两者都实现了，软件上切换差异并不大，主要是初始化时多生成一个16字节的广播码，并预留了与手机Assistant设备交互的同步传输接口。不过这要求蓝牙协议栈对PAST支持完整，选芯片的时候要确认这一点。

4. 实测效果与关键数据

4.1 覆盖距离和穿墙表现

这是我这次最关心的指标，毕竟广播类产品的卖点之一就是“覆盖范围”。实测环境是普通办公楼的开放层，手机作为接收端。

空旷环境下，手机跟模块之间没有任何遮挡，把模块放在地上半米高处，手机在40米左右还能稳定显示广播并播放音频，再远到50米时声音开始出现偶发中断，但广播同步还没有彻底丢失。隔一堵20cm左右的砖墙，距离缩小到15米，还能保持基本流畅的声音。如果是经过两道墙，就只能收到断断续续的音频碎片了。这个表现跟天线普通的蓝牙耳机实属同一水平，对于室内广播场景完全够用。

穿墙能力受限于2.4GHz频段的物理特性，很难有质的飞跃。如果你的产品需要更大的覆盖范围，我建议从几个方向着手：提高发射功率（前提是过认证允许）、改用外置天线而不是板载天线、优化接收端的灵敏度参数。其中最立竿见影的是外置天线，实测在同样条件下距离能提升20%左右，代价是增加了一根天线和同轴线缆的成本。

4.2 延迟、音质和抗干扰

延迟方面，我用的土办法是手机慢动作拍摄：一边是音源设备上的秒表跑秒，一边是接收端耳机里的声音，逐帧对比时间差。最终测得的端到端延迟在60-80ms之间。这个延迟包含音频采集、LC3编码、空口传输、接收端解码和耳机播放的全部时间。实际听感是完全跟嘴型的，看视频、看电视配音对不上会有点感觉，但对广播类应用比如候机厅播报、展会讲解来说毫无压力。

音质这块需要客观说。LC3在相同码率下音质比传统SBC好，但广播场景下不能开太高的码率。我最终用的是48kHz采样、单声道160kbps配置，听感比手机通话好很多，高频不会明显发闷，但比起原始CD级别还是可感知损失的。如果对音质有更高要求，可以上到192kbps或者打开双声道，代价是广播占用时间变长、功耗会上升。为了稳定和低延迟，单声道160kbps是广播模块比较务实的甜点配置。

抗干扰测试我模拟了办公室环境：旁边有Wi-Fi路由器、大量蓝牙鼠标键盘、同事的耳机在放歌。在这种环境下，350ms内平均丢包率在3%左右，反映到听感上就是二三十秒偶尔出现一次轻微“咔嗒”声，整体可接受。如果把重传次数提升到2，卡顿频率会显著下降，但功耗上升明显，所以实际产品我保留为可配置项，由用户自己权衡。

4.3 功耗数据与续航估算

因为模块是连续发送音频广播，功耗主要取决于iso_interval、重传次数和LC3码率。实测模块在3.7V供电、48kHz单声道160kbps、iso_interval 10ms、重传1次的配置下，平均工作电流在11mA左右。这个数据我用万用表串联测过，也用小电流计单独跑过24小时统计，比较稳定。

如果是电池供电产品，用一块500mAh的锂电池，理论续航可以到45小时左右，实际考虑电池降压损耗和低温情况，保守估计30小时以上没问题。对一个简单的广播发射器来说，这个续航非常可观。如果再用PA Interval拉到200ms、重传关闭，平均电流还能压到8mA以下，续航能再进一步，前提是你对弱信号环境下的可靠性要求不高。

5. 避坑指南与问题排查实录

5.1 手机搜不到广播：先把这三件事查一遍

调试期间最让人崩溃的问题就是手机端搜不到广播，而用抓包器看空口数据明明一切正常。根据我摸爬滚打的经验，搜不到广播大概率是以下三个原因。

第一个是PA Interval太长。接收端扫描器要持续扫描好几个广播周期才能“合并”出一个完整的广播印象。如果你为了省电把PA Interval运行到了500ms以上，很多严格的手机扫描器可能压根不会上报这个广播给你。解决办法是先用100ms左右的密集广播来做兼容性测试，确认整条链路通了再优化省电参数。

第二个是蓝牙协议栈对Auracast的支持不完整。这不是我们自己的PC端代码问题，而是接收端平台的问题。iPhone需要iOS 17以上，且是iPhone 11之后的机型才完整支持Auracast；Android这边碎片化严重，Android 13到15的部分机型支持，很多兼容性反而要写在说明书上而不是代码里。

第三个是信道配置问题。BIS广播的信道地图默认使用37/38/39三个主广播信道之外的数据信道。某些手机在扫描阶段只会扫描主广播信道，如果你把BIS信道地图配置得太窄，发送的数据包正好不在接收端扫描覆盖范围内，就会表现为“看得到广播名字但连接后没声音”。遇到这种情况，我一般会把信道地图配置回全部数据信道，先把功能跑通再优化。

5.2 音频卡顿断断续续：时钟、干扰和参数三连排查

音频一旦出现卡顿，别急着怀疑射频硬件。我的排查路径是：先看LC3帧缓冲是否溢出，再看时钟偏差，最后才怀疑干扰。

最隐蔽的卡顿元凶其实是音频采样时钟和BIS发送时钟不同步。如果音频采集由内部PLL时钟驱动，而BIS发送由某个独立的32kHz睡眠时钟参与调度，两边一旦存在ppm级别的偏差，运行几分钟后就会积累成丢帧。解决方式是用同一个时钟源驱动音频采样和BIS定时器。如果硬件上做不到，需要软件定期做重采样校正，这个工作量和难度会大很多。

其次是干扰。2.4GHz频段本来就是个拥挤菜市场，Wi-Fi、Zigbee、私有协议全都挤在里面。如果模块附近恰好有Wi-Fi路由器在传大文件，BIS广播被压缩在所难免。可以在SDK里调整BIS的信道地图绕开被Wi-Fi占用的信道，或者简单粗暴地把重传次数加一，实测都能明显改善。

最后排查的就是接收端硬件问题了。我遇到过一块样片将晶振负载电容配错，导致频率偏了30ppm，同步十分钟后必断流重连。这个问题只有在长时间运行后才会暴露，所以建议所有样片都做至少8小时连续广播的老化测试，看是否有延迟越来越大的趋势。

5.3 兼容性对照表与测试工具推荐

调试Auracast功能时，我同时用了一个Android一个iOS设备来回验证。给一张我自己项目里的测试对照表，不同平台的差异一眼就能看清：

测试工具方面，我建议至少要有一台USB接口的蓝牙协议分析仪，能把空口的BIS包和PA包抓下来，否则调试广播参数就像蒙眼开车。如果预算不足，退而求其次可以用支持LE Audio对数分析的手机App，配合厂商Log看协议栈内部状态，也能定位大部分问题。

另外推荐一个技巧：在电脑上跑一个Auracast接收的例程，把收到的LC3帧存成WAV文件。这样可以定量分析发射端是否有丢帧、有没有排序乱序，比人耳听感可靠得多。我就是靠这个工具定位出某个版本SDK在BIS序号处理上的一个边界条件bug。

5.4 常见问题速查表

把这次开发中遇到比较多的问题整理成一个速查表，方便后面做产品时快速定位。

6. 这次项目的一些体会和下一步想法

这个项目让我改变了对蓝牙音频“只能点对点连接”的固有认知。Auracast把一个本来属于收音机时代的“一对多广播”体验，用现代蓝牙的低功耗和高质量音频重新做了一遍，而且从模块开发者的角度来看，它的实现难度并不像想象中那么高。最难的不是协议栈本身，而是参数选择、硬件匹配和工程化细节的打磨。

我个人在实际操作中的体会是：做这种射频加音频的模块，一定要把测试工具配齐再动手。没有协议分析仪和频谱仪之前，我基本是在瞎调参数；有了工具之后，很多问题十分钟就能定位到具体帧和具体寄存器。

下一步我打算在这个模块基础上做两件事。一件是把多发射端的信道编排做成一个上位机工具，让客户可以规划多个广播源之间的频点避让，避免在同一个现场里多个Auracast广播源互相干扰。另一件是研究一下在加密广播模式下，如何更优雅地和手机Assistant交互，把授权流程做得更贴近普通消费者——这两个方向如果都跑通了，这模块的价值还能再上一个台阶。