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