最近花了大概两周多时间把手头这块BT2106C Auracast蓝牙广播模块从评估板一路调到了能小批量打样的状态。先说结论公共广播和加密广播两条链路都跑通了空旷环境下手机接收距离实测约40米隔一堵砖墙大概15米左右从音源到耳机出声的体感延迟在60-80ms之间。用一句话来概括这个项目就是利用支持LE Audio的BT2106C芯片做了一颗只干Auracast广播这一件事的小模块把外部音频采集进来、用LC3编码后以BIS广播流发出去让范围内的手机、耳机、助听器直接收听。这篇文章不是产品发布会通稿我把这次开发过程中的选型思路、硬件设计、软件配置、实测数据以及踩过的坑都整理出来。如果你正打算做蓝牙音频广播、助听器TV发射器、展厅导览、会议室同传这类设备这篇应该能帮你少走不少弯路。1. 选型与整体设计为什么是BT2106CAuracast解决什么问题1.1 Auracast在现有蓝牙音频版图里的位置先说点背景知识。传统蓝牙音频走的是A2DP一对一的连接模式。手机连耳机、连音箱一个源只能对应一个接收端。带着无线耳机走到电视机旁边想换着听得先断开重连整个过程非常折腾。Auracast把这件事改成了广播制式相当于在一个无线电频段上持续播放音频谁在覆盖范围内谁就能接收。基于LE Audio里的BISBroadcast 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参数配置间隔、分组、重传BIGBroadcast Isochronous Group是BIS的集合可以把多个逻辑音频流打包成一组同时广播。我们产品核心功能是单信道广播所以就配置了一组BIG里面只含一个BIS。BIS的iso_interval我一开始按默认的20ms配置后来实测发现这个间隔偏大因为LC3帧时长是10ms一个20ms的间隔里要装两帧音频数据接收端的解码缓存也会相应增加最终延迟比预期大了不少。改到10ms间隔一帧一帧发之后端到端延迟明显降下来了。重传参数直接决定接收端在复杂环境下的表现。BIS广播模式下接收端不会发送任何确认信息给发射端它就是纯单向的“开枪”所以必须在数据包里做冗余。btstack里对应的是max_pdu_sdu和重传次数。我把重传次数设为1相当于每一帧数据发送两次冗余翻倍代价是空口占用时间变长。在2.4GHz环境比较复杂的写字楼里这个冗余设置对避免瞬时卡顿非常有帮助。另外一个是广播周期Periodic Advertising IntervalPA 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之后的机型才完整支持AuracastAndroid这边碎片化严重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设备来回验证。给一张我自己项目里的测试对照表不同平台的差异一眼就能看清接收端平台支持状态备注iOS 17及以上支持iPhone 11及后续机型系统自带音频广播入口Android 13部分支持需要手机SoC自带LE Audio完整协议栈Android 14部分支持厂商差异较大三星/谷歌亲儿子较好Android 15及以上较完整Android原生Auracast接收已落地Windows 11暂不建议目前蓝牙音频栈对Auracast支持不成熟主流TWS耳机多数支持需要确认芯片平台和固件版本测试工具方面我建议至少要有一台USB接口的蓝牙协议分析仪能把空口的BIS包和PA包抓下来否则调试广播参数就像蒙眼开车。如果预算不足退而求其次可以用支持LE Audio对数分析的手机App配合厂商Log看协议栈内部状态也能定位大部分问题。另外推荐一个技巧在电脑上跑一个Auracast接收的例程把收到的LC3帧存成WAV文件。这样可以定量分析发射端是否有丢帧、有没有排序乱序比人耳听感可靠得多。我就是靠这个工具定位出某个版本SDK在BIS序号处理上的一个边界条件bug。5.4 常见问题速查表把这次开发中遇到比较多的问题整理成一个速查表方便后面做产品时快速定位。现象可能原因排查方式解决方案手机搜不到广播PA间隔太长/平台不支持抓包看PA事件缩短PA间隔确认接收端官方支持能搜到但连接后无声音信道地图不匹配/加密广播无授权抓包分析BIS事件恢复默认信道地图/取消加密测试声音断断续续时钟漂移/外部干扰/输出欠压查帧序号/Log看丢包率统一时钟源/加重传/查电源纹波运行十分钟后彻底断流晶振频率偏大老化测试观察时钟偏移换精度更好的晶振/调负载电容距离很短只有几米天线匹配不良/射频走线过长网络分析仪测回损调整π匹配、缩短射频走线底噪明显沙沙声模拟地与数字地未隔离断开模拟地测试单点接地/加磁珠隔离6. 这次项目的一些体会和下一步想法这个项目让我改变了对蓝牙音频“只能点对点连接”的固有认知。Auracast把一个本来属于收音机时代的“一对多广播”体验用现代蓝牙的低功耗和高质量音频重新做了一遍而且从模块开发者的角度来看它的实现难度并不像想象中那么高。最难的不是协议栈本身而是参数选择、硬件匹配和工程化细节的打磨。我个人在实际操作中的体会是做这种射频加音频的模块一定要把测试工具配齐再动手。没有协议分析仪和频谱仪之前我基本是在瞎调参数有了工具之后很多问题十分钟就能定位到具体帧和具体寄存器。下一步我打算在这个模块基础上做两件事。一件是把多发射端的信道编排做成一个上位机工具让客户可以规划多个广播源之间的频点避让避免在同一个现场里多个Auracast广播源互相干扰。另一件是研究一下在加密广播模式下如何更优雅地和手机Assistant交互把授权流程做得更贴近普通消费者——这两个方向如果都跑通了这模块的价值还能再上一个台阶。