最近花了大概兩周多時間把手頭這塊BT2106C Auracast藍牙廣播模塊從評估板一路調(diào)到了能小批量打樣的狀態(tài)。先說結(jié)論公共廣播和加密廣播兩條鏈路都跑通了空曠環(huán)境下手機接收距離實測約40米隔一堵磚墻大概15米左右從音源到耳機出聲的體感延遲在60-80ms之間。用一句話來概括這個項目就是利用支持LE Audio的BT2106C芯片做了一顆只干Auracast廣播這一件事的小模塊把外部音頻采集進來、用LC3編碼后以BIS廣播流發(fā)出去讓范圍內(nèi)的手機、耳機、助聽器直接收聽。這篇文章不是產(chǎn)品發(fā)布會通稿我把這次開發(fā)過程中的選型思路、硬件設計、軟件配置、實測數(shù)據(jù)以及踩過的坑都整理出來。如果你正打算做藍牙音頻廣播、助聽器TV發(fā)射器、展廳導覽、會議室同傳這類設備這篇應該能幫你少走不少彎路。1. 選型與整體設計為什么是BT2106CAuracast解決什么問題1.1 Auracast在現(xiàn)有藍牙音頻版圖里的位置先說點背景知識。傳統(tǒng)藍牙音頻走的是A2DP一對一的連接模式。手機連耳機、連音箱一個源只能對應一個接收端。帶著無線耳機走到電視機旁邊想換著聽得先斷開重連整個過程非常折騰。Auracast把這件事改成了廣播制式相當于在一個無線電頻段上持續(xù)播放音頻誰在覆蓋范圍內(nèi)誰就能接收?；贚E Audio里的BISBroadcast Isochronous Stream廣播同步流一個發(fā)射端可以把多路音頻流同時廣播出去接收端只需同步到這個廣播流不需要建立傳統(tǒng)意義上的藍牙連接。這個特性對應的典型場景非常明確醫(yī)院叫號、博物館導覽、健身房電視機音頻、高鐵候車大廳廣播、助聽器用戶直接拾取公共場所的音頻信號。甚至會議室里做同聲傳譯也可以通過Auracast通道對外廣播多語言音頻聽眾用手機或耳機自由選擇信道。和傳統(tǒng)一對一藍牙音頻相比Auracast最大的價值就是“一對多、低延遲、免配對”。1.2 BT2106C這顆芯片到底強在哪選BT2106C之前我把市面上支持Auracast的方案大致掃了一遍。大致分兩類一類是手機主控芯片自帶的藍牙音頻方案功能強但外圍復雜做產(chǎn)品要支付高昂的授權和BOM成本另一類是面向音頻外設的BLE音頻SoC集成了射頻、MCU、DSP和音頻編解碼器一片就能干活。BT2106C屬于后者。這顆芯片是中科藍訊的產(chǎn)品支持藍牙5.4和LE Audio內(nèi)部集成了射頻收發(fā)器、32位MCU和用于LC3編解碼的音頻DSP。對我這個項目來說極具吸引力的一點是單芯片方案外部只需要一顆晶振、供電電路、天線和一個音頻輸入接口不需要再掛單獨的藍牙協(xié)議棧芯片或者音頻編解碼芯片。布線面積能壓到非常小很適合做得像U盤那么大。另外值得說的一點是功耗和整套SDK的學習成本。BT2106C在純廣播模式下的電流實測在個位數(shù)毫安級別這對手持或者電池供電的產(chǎn)品非常友好。SDK層面中科藍訊已經(jīng)提供了LE Audio相關的協(xié)議棧和Auracast示例工程不太需要從零去啃BLE Audio規(guī)范開發(fā)者可以把主要精力放在應用層和射頻調(diào)試上。1.3 系統(tǒng)級設計是純發(fā)射端還是收發(fā)一體項目剛開始我犯過糾結(jié)要不要做成“收發(fā)一體”——既能發(fā)射Auracast廣播又能接收Auracast廣播一個模塊兩個角色。后來想明白了模塊的定位是“廣播信號源”用于替代市場上傳統(tǒng)的FM調(diào)頻發(fā)射器或者紅外導覽設備所以必須優(yōu)先保證發(fā)射鏈路的穩(wěn)定和音質(zhì)。接收能力只在調(diào)試階段臨時開啟用來做往返測試。這樣做也簡化了軟件狀態(tài)機避免了收發(fā)模式切換時可能帶來的協(xié)議棧沖突。所以最后的系統(tǒng)框架是外部音頻進模塊經(jīng)ADC采樣后交給DSP做LC3編碼按BIS時隙打包到空口模塊自身不做解碼不播聲音。整個系統(tǒng)的工作流程是單向的這對代碼邏輯、內(nèi)存占用和功耗控制都友好得多。2. 硬件設計細節(jié)原理圖、PCB和天線那些事2.1 最小系統(tǒng)搭建供電、晶振、復位BT2106C的最小系統(tǒng)并不復雜。供電部分我用了一顆低噪聲LDO把外部4.2V鋰電池電壓降到3.3V同時給數(shù)字電源和射頻電源分別做了LC濾波。這一塊有多重要我在后面踩坑的部分會詳細說射頻發(fā)射器在數(shù)據(jù)包發(fā)射瞬間電流會有幾十毫安的瞬態(tài)跳動如果電源紋波太大會導致射頻輸出頻譜變差、接收端誤碼率升高表現(xiàn)就是距離拉不遠。晶振選擇需要特別注意精度。Auracast接收端要在一個時間窗口內(nèi)精確采樣接收數(shù)據(jù)對發(fā)射端時鐘的穩(wěn)定性有要求。我用的外部晶振是24MHz精度選為±10ppm級別。實際調(diào)試中我發(fā)現(xiàn)晶振精度不夠時最典型的癥狀是接收端剛同步上的時候聲音正常但十分鐘后開始出現(xiàn)偶發(fā)卡頓甚至徹底丟同步。這是因為收發(fā)兩端時鐘漂移累積到一定程度超出了接收端的容忍范圍。復位電路我用了最簡單的RC復位加一個外部看門狗。實際調(diào)試中看門狗喂狗時間配置得非常寬松因為在廣播模式下一旦進入穩(wěn)定工作態(tài)協(xié)議棧本身不太會卡死反而是我們自己加的一些音頻處理邏輯容易出問題。2.2 天線匹配與射頻走線經(jīng)驗天線是這類小模塊最容易翻車的地方。為了控制成本初版我直接用了PCB板載天線雙面FR4板材板厚1.0mm。板載天線需要考慮凈空區(qū)天線正下方不能鋪地和走線。我做的第一版樣片就因為天線跟前的地銅皮靠太近實測距離直接掉了三分之一。后來我重新layout在天線區(qū)域畫了完整的凈空區(qū)同時在天線饋點后面預留了π型匹配網(wǎng)絡就是串聯(lián)一個電感、并聯(lián)兩個電容的經(jīng)典結(jié)構。板上預留這個位置非常有必要因為板載天線的實際諧振頻率會受外殼、周邊金屬件、電池位置影響沒有匹配網(wǎng)絡就只能重新打板有的話可以用網(wǎng)絡分析儀微調(diào)匹配。我調(diào)完之后的S11回波損耗做到了-10dB以下也就是反射功率不到10%整體效率才算能接受。射頻走線從芯片天線引腳到匹配網(wǎng)絡再到天線饋點這段線要控制在50Ω阻抗。在沒有專業(yè)阻抗計算軟件的情況下可以按常規(guī)經(jīng)驗走線寬0.3mm左右參考地要完整連續(xù)盡量短。我還做過一個對比測試把這段走線從8mm縮短到3mm其他條件不變SPP和BIS的丟包率有了肉眼可見的改善。2.3 音頻采集鏈路模擬輸入和數(shù)字輸入怎么接這個模塊的有趣之處在于它只是個“音頻搬運工”所以輸入端的信號質(zhì)量會直接影響最終的廣播效果。我這邊做了兩個版本。第一版是模擬Line-in輸入外部音源比如電視耳機口、調(diào)音臺AUX口通過3.5mm插座進入模塊經(jīng)過一圈隔直電容和分壓電阻送到芯片內(nèi)置ADC。第二版是PDM數(shù)字麥克風輸入用于需要自帶拾音的場景比如課堂上老師把模塊掛在脖子上直接用板載麥克風采集人聲廣播給學生耳機。模擬輸入需要注意輸入電平匹配。普通電視耳機口的輸出幅度和滿幅ADC輸入范圍不一定一致。我加了一顆運放做可調(diào)增益通過兩個GPIO控制增益檔位實測下來能適配大多數(shù)常見音源。數(shù)字麥克風輸入相對省心PDM接口抗干擾能力比模擬線強得多布線要求沒那么苛刻所以如果產(chǎn)品形態(tài)允許我更建議用數(shù)字麥克風直接采集。這里展開說一個很多新手忽略的問題音頻輸入的地線一定要跟模塊的數(shù)字地單點連接。如果模擬地和數(shù)字地直接大面積相連板上的開關噪聲和高頻諧波會耦合進模擬前端最終廣播出去的聲音會有持續(xù)的“嘶嘶”底噪。我最后的處理方法是模擬區(qū)獨立一小塊地島通過一個0Ω電阻單點連接到主地效果立竿見影。3. 軟件配置與廣播參數(shù)調(diào)優(yōu)3.1 SDK工程搭建和Auracast核心流程軟件方面整個工程是在廠商SDK基礎上搭建的。先把Auracast廣播示例工程編譯點亮然后逐步裁剪掉測試代碼加入自己的應用邏輯。使用BT2106C SDK時有個點需要注意不要直接用官方默認配置去開發(fā)產(chǎn)品因為示例工程里很多參數(shù)是為了兼容性測試設置的比如廣播間隔、PDU長度都偏保守直接套用到產(chǎn)品上會犧牲實時性和功耗。Auracast發(fā)射端的核心流程可以分為四步初始化協(xié)議棧和射頻、配置BIG參數(shù)開始周期性廣播、采集音頻數(shù)據(jù)并做LC3編碼、把編碼后的音頻幀按照BIS時隙順序發(fā)送出去。這里最難的地方在于第三和第四步之間的配合。LC3編碼是一幀一幀出的每一幀時長是7.5ms或10ms而BIS事件也有自己的時間間隔iso_interval。兩者必須對齊不能讓編碼器產(chǎn)幀速率低于或者高于空口發(fā)送速率否則會出現(xiàn)延遲累積或者丟幀。我在代碼里用了一個帶時間戳的環(huán)形緩沖區(qū)來解耦編解碼和射頻發(fā)送。編碼器按自己的節(jié)奏把幀填進緩沖區(qū)發(fā)送回調(diào)按BIS事件節(jié)奏從緩沖區(qū)取幀。這樣即使偶爾遇到MCU被其他中斷打斷也不會漏掉某一幀的發(fā)送窗口。這個設計思路對BLE音頻開發(fā)通用性很強強烈建議保留。3.2 BIS與BIG參數(shù)配置間隔、分組、重傳BIGBroadcast Isochronous Group是BIS的集合可以把多個邏輯音頻流打包成一組同時廣播。我們產(chǎn)品核心功能是單信道廣播所以就配置了一組BIG里面只含一個BIS。BIS的iso_interval我一開始按默認的20ms配置后來實測發(fā)現(xiàn)這個間隔偏大因為LC3幀時長是10ms一個20ms的間隔里要裝兩幀音頻數(shù)據(jù)接收端的解碼緩存也會相應增加最終延遲比預期大了不少。改到10ms間隔一幀一幀發(fā)之后端到端延遲明顯降下來了。重傳參數(shù)直接決定接收端在復雜環(huán)境下的表現(xiàn)。BIS廣播模式下接收端不會發(fā)送任何確認信息給發(fā)射端它就是純單向的“開槍”所以必須在數(shù)據(jù)包里做冗余。btstack里對應的是max_pdu_sdu和重傳次數(shù)。我把重傳次數(shù)設為1相當于每一幀數(shù)據(jù)發(fā)送兩次冗余翻倍代價是空口占用時間變長。在2.4GHz環(huán)境比較復雜的寫字樓里這個冗余設置對避免瞬時卡頓非常有幫助。另外一個是廣播周期Periodic Advertising IntervalPA Interval。接收端初始掃描到這個廣播需要的參數(shù)越密越容易被發(fā)現(xiàn)但同時會增加功耗和無線占用。我測試下來PA Interval設在100ms比較合適手機開Auracast掃描App幾乎能秒搜到功耗也就多消耗不到1mA。如果你做的是低功耗電池設備可以把PA Interval放到200ms到300ms以不易發(fā)現(xiàn)為代價換來更長的續(xù)航。3.3 公共廣播和加密廣播怎么選配起來差別在哪Auracast支持兩種廣播類型公共廣播和加密廣播。公共廣播最簡單。四個廣播參數(shù)——廣播名、廣播語言、節(jié)目類型和一個十六進制ID——直接在廣播包里周期廣播出去任何支持Auracast的設備都能搜到并直接收聽。我測試時用的就是公共廣播手機端用系統(tǒng)設置或第三方App進去就能看到音頻廣播點一下就出聲體驗真的有點像“藍牙版收音機”。加密廣播則多一層保護。廣播內(nèi)容用應對密鑰加密接收端必須拿到這個密鑰才能解碼音頻。從實現(xiàn)角度看差別不只是“加個密碼”那么簡單。加密廣播要求接收端在初始同步的時候從某個“幫助設備”手里獲取密鑰這個幫助設備通常是手機手機通過廣播同步傳輸PAST把BIG相關參數(shù)和廣播碼傳給接收端耳機/助聽器。也就是說對于加密廣播你手邊得有一臺支持Auracast Assistant功能的手機來“授權”接收端加入收聽。產(chǎn)品角度怎么選如果應用是開放廣播例如商場廣播、博物館導覽公共廣播就夠了如果應用是VIP會議室同傳、收費內(nèi)容推送那就必須上加密廣播。我這次兩者都實現(xiàn)了軟件上切換差異并不大主要是初始化時多生成一個16字節(jié)的廣播碼并預留了與手機Assistant設備交互的同步傳輸接口。不過這要求藍牙協(xié)議棧對PAST支持完整選芯片的時候要確認這一點。4. 實測效果與關鍵數(shù)據(jù)4.1 覆蓋距離和穿墻表現(xiàn)這是我這次最關心的指標畢竟廣播類產(chǎn)品的賣點之一就是“覆蓋范圍”。實測環(huán)境是普通辦公樓的開放層手機作為接收端?？諘绛h(huán)境下手機跟模塊之間沒有任何遮擋把模塊放在地上半米高處手機在40米左右還能穩(wěn)定顯示廣播并播放音頻再遠到50米時聲音開始出現(xiàn)偶發(fā)中斷但廣播同步還沒有徹底丟失。隔一堵20cm左右的磚墻距離縮小到15米還能保持基本流暢的聲音。如果是經(jīng)過兩道墻就只能收到斷斷續(xù)續(xù)的音頻碎片了。這個表現(xiàn)跟天線普通的藍牙耳機實屬同一水平對于室內(nèi)廣播場景完全夠用。穿墻能力受限于2.4GHz頻段的物理特性很難有質(zhì)的飛躍。如果你的產(chǎn)品需要更大的覆蓋范圍我建議從幾個方向著手提高發(fā)射功率前提是過認證允許、改用外置天線而不是板載天線、優(yōu)化接收端的靈敏度參數(shù)。其中最立竿見影的是外置天線實測在同樣條件下距離能提升20%左右代價是增加了一根天線和同軸線纜的成本。4.2 延遲、音質(zhì)和抗干擾延遲方面我用的土辦法是手機慢動作拍攝一邊是音源設備上的秒表跑秒一邊是接收端耳機里的聲音逐幀對比時間差。最終測得的端到端延遲在60-80ms之間。這個延遲包含音頻采集、LC3編碼、空口傳輸、接收端解碼和耳機播放的全部時間。實際聽感是完全跟嘴型的看視頻、看電視配音對不上會有點感覺但對廣播類應用比如候機廳播報、展會講解來說毫無壓力。音質(zhì)這塊需要客觀說。LC3在相同碼率下音質(zhì)比傳統(tǒng)SBC好但廣播場景下不能開太高的碼率。我最終用的是48kHz采樣、單聲道160kbps配置聽感比手機通話好很多高頻不會明顯發(fā)悶但比起原始CD級別還是可感知損失的。如果對音質(zhì)有更高要求可以上到192kbps或者打開雙聲道代價是廣播占用時間變長、功耗會上升。為了穩(wěn)定和低延遲單聲道160kbps是廣播模塊比較務實的甜點配置。抗干擾測試我模擬了辦公室環(huán)境旁邊有Wi-Fi路由器、大量藍牙鼠標鍵盤、同事的耳機在放歌。在這種環(huán)境下350ms內(nèi)平均丟包率在3%左右反映到聽感上就是二三十秒偶爾出現(xiàn)一次輕微“咔嗒”聲整體可接受。如果把重傳次數(shù)提升到2卡頓頻率會顯著下降但功耗上升明顯所以實際產(chǎn)品我保留為可配置項由用戶自己權衡。4.3 功耗數(shù)據(jù)與續(xù)航估算因為模塊是連續(xù)發(fā)送音頻廣播功耗主要取決于iso_interval、重傳次數(shù)和LC3碼率。實測模塊在3.7V供電、48kHz單聲道160kbps、iso_interval 10ms、重傳1次的配置下平均工作電流在11mA左右。這個數(shù)據(jù)我用萬用表串聯(lián)測過也用小電流計單獨跑過24小時統(tǒng)計比較穩(wěn)定。如果是電池供電產(chǎn)品用一塊500mAh的鋰電池理論續(xù)航可以到45小時左右實際考慮電池降壓損耗和低溫情況保守估計30小時以上沒問題。對一個簡單的廣播發(fā)射器來說這個續(xù)航非?？捎^。如果再用PA Interval拉到200ms、重傳關閉平均電流還能壓到8mA以下續(xù)航能再進一步前提是你對弱信號環(huán)境下的可靠性要求不高。5. 避坑指南與問題排查實錄5.1 手機搜不到廣播先把這三件事查一遍調(diào)試期間最讓人崩潰的問題就是手機端搜不到廣播而用抓包器看空口數(shù)據(jù)明明一切正常。根據(jù)我摸爬滾打的經(jīng)驗搜不到廣播大概率是以下三個原因。第一個是PA Interval太長。接收端掃描器要持續(xù)掃描好幾個廣播周期才能“合并”出一個完整的廣播印象。如果你為了省電把PA Interval運行到了500ms以上很多嚴格的手機掃描器可能壓根不會上報這個廣播給你。解決辦法是先用100ms左右的密集廣播來做兼容性測試確認整條鏈路通了再優(yōu)化省電參數(shù)。第二個是藍牙協(xié)議棧對Auracast的支持不完整。這不是我們自己的PC端代碼問題而是接收端平臺的問題。iPhone需要iOS 17以上且是iPhone 11之后的機型才完整支持AuracastAndroid這邊碎片化嚴重Android 13到15的部分機型支持很多兼容性反而要寫在說明書上而不是代碼里。第三個是信道配置問題。BIS廣播的信道地圖默認使用37/38/39三個主廣播信道之外的數(shù)據(jù)信道。某些手機在掃描階段只會掃描主廣播信道如果你把BIS信道地圖配置得太窄發(fā)送的數(shù)據(jù)包正好不在接收端掃描覆蓋范圍內(nèi)就會表現(xiàn)為“看得到廣播名字但連接后沒聲音”。遇到這種情況我一般會把信道地圖配置回全部數(shù)據(jù)信道先把功能跑通再優(yōu)化。5.2 音頻卡頓斷斷續(xù)續(xù)時鐘、干擾和參數(shù)三連排查音頻一旦出現(xiàn)卡頓別急著懷疑射頻硬件。我的排查路徑是先看LC3幀緩沖是否溢出再看時鐘偏差最后才懷疑干擾。最隱蔽的卡頓元兇其實是音頻采樣時鐘和BIS發(fā)送時鐘不同步。如果音頻采集由內(nèi)部PLL時鐘驅(qū)動而BIS發(fā)送由某個獨立的32kHz睡眠時鐘參與調(diào)度兩邊一旦存在ppm級別的偏差運行幾分鐘后就會積累成丟幀。解決方式是用同一個時鐘源驅(qū)動音頻采樣和BIS定時器。如果硬件上做不到需要軟件定期做重采樣校正這個工作量和難度會大很多。其次是干擾。2.4GHz頻段本來就是個擁擠菜市場Wi-Fi、Zigbee、私有協(xié)議全都擠在里面。如果模塊附近恰好有Wi-Fi路由器在傳大文件BIS廣播被壓縮在所難免?？梢栽赟DK里調(diào)整BIS的信道地圖繞開被Wi-Fi占用的信道或者簡單粗暴地把重傳次數(shù)加一實測都能明顯改善。最后排查的就是接收端硬件問題了。我遇到過一塊樣片將晶振負載電容配錯導致頻率偏了30ppm同步十分鐘后必斷流重連。這個問題只有在長時間運行后才會暴露所以建議所有樣片都做至少8小時連續(xù)廣播的老化測試看是否有延遲越來越大的趨勢。5.3 兼容性對照表與測試工具推薦調(diào)試Auracast功能時我同時用了一個Android一個iOS設備來回驗證。給一張我自己項目里的測試對照表不同平臺的差異一眼就能看清接收端平臺支持狀態(tài)備注iOS 17及以上支持iPhone 11及后續(xù)機型系統(tǒng)自帶音頻廣播入口Android 13部分支持需要手機SoC自帶LE Audio完整協(xié)議棧Android 14部分支持廠商差異較大三星/谷歌親兒子較好Android 15及以上較完整Android原生Auracast接收已落地Windows 11暫不建議目前藍牙音頻棧對Auracast支持不成熟主流TWS耳機多數(shù)支持需要確認芯片平臺和固件版本測試工具方面我建議至少要有一臺USB接口的藍牙協(xié)議分析儀能把空口的BIS包和PA包抓下來否則調(diào)試廣播參數(shù)就像蒙眼開車。如果預算不足退而求其次可以用支持LE Audio對數(shù)分析的手機App配合廠商Log看協(xié)議棧內(nèi)部狀態(tài)也能定位大部分問題。另外推薦一個技巧在電腦上跑一個Auracast接收的例程把收到的LC3幀存成WAV文件。這樣可以定量分析發(fā)射端是否有丟幀、有沒有排序亂序比人耳聽感可靠得多。我就是靠這個工具定位出某個版本SDK在BIS序號處理上的一個邊界條件bug。5.4 常見問題速查表把這次開發(fā)中遇到比較多的問題整理成一個速查表方便后面做產(chǎn)品時快速定位?，F(xiàn)象可能原因排查方式解決方案手機搜不到廣播PA間隔太長/平臺不支持抓包看PA事件縮短PA間隔確認接收端官方支持能搜到但連接后無聲音信道地圖不匹配/加密廣播無授權抓包分析BIS事件恢復默認信道地圖/取消加密測試聲音斷斷續(xù)續(xù)時鐘漂移/外部干擾/輸出欠壓查幀序號/Log看丟包率統(tǒng)一時鐘源/加重傳/查電源紋波運行十分鐘后徹底斷流晶振頻率偏大老化測試觀察時鐘偏移換精度更好的晶振/調(diào)負載電容距離很短只有幾米天線匹配不良/射頻走線過長網(wǎng)絡分析儀測回損調(diào)整π匹配、縮短射頻走線底噪明顯沙沙聲模擬地與數(shù)字地未隔離斷開模擬地測試單點接地/加磁珠隔離6. 這次項目的一些體會和下一步想法這個項目讓我改變了對藍牙音頻“只能點對點連接”的固有認知。Auracast把一個本來屬于收音機時代的“一對多廣播”體驗用現(xiàn)代藍牙的低功耗和高質(zhì)量音頻重新做了一遍而且從模塊開發(fā)者的角度來看它的實現(xiàn)難度并不像想象中那么高。最難的不是協(xié)議棧本身而是參數(shù)選擇、硬件匹配和工程化細節(jié)的打磨。我個人在實際操作中的體會是做這種射頻加音頻的模塊一定要把測試工具配齊再動手。沒有協(xié)議分析儀和頻譜儀之前我基本是在瞎調(diào)參數(shù)有了工具之后很多問題十分鐘就能定位到具體幀和具體寄存器。下一步我打算在這個模塊基礎上做兩件事。一件是把多發(fā)射端的信道編排做成一個上位機工具讓客戶可以規(guī)劃多個廣播源之間的頻點避讓避免在同一個現(xiàn)場里多個Auracast廣播源互相干擾。另一件是研究一下在加密廣播模式下如何更優(yōu)雅地和手機Assistant交互把授權流程做得更貼近普通消費者——這兩個方向如果都跑通了這模塊的價值還能再上一個臺階。