很多人一看“蓝牙加语音播报”第一反应就是找一颗蓝牙音箱芯片好像能放歌的芯片一定就会说话。但这个需求恰恰反过来了不需要蓝牙听歌只要蓝牙BLE透传加本地语音播报这句话的本质是把项目从“音频流”拉回到“数据流”。A2DP传歌和BLE透传指令是两条完全不同的技术路线而本地语音播报需要的只是设备自己把Flash里存好的语音放出来和手机之间传的始终是控制指令。这篇内容我就以自己最近配合的水控终端项目为样本把选型思路、芯片对比、落地流程和量产前要踩的坑一次说清楚适合正在做蓝牙水控器、智能锁、售货机、医疗终端等“连接就用一下、主要靠本地发声”的硬件工程师。1. 需求边界这个项目要的是“会说话的终端”不是“能放歌的喇叭”1.1 “不需要蓝牙听歌”背后的协议真相蓝牙音频听歌走的是A2DP Profile它是一条带宽约2Mbps量级的实时音频通道手机把压缩后的音频流持续推给设备设备解码后通过DAC和功放放出来。这条链路的特点是连接建立后最好一直保持数据量大、功耗高而且协议栈实现复杂。对“租个蓝牙音箱听歌”的场景A2DP是必须的对“手机发个指令、设备自己说句话”的场景A2DP纯属浪费。这个需求里的“不需要蓝牙听歌”实际是把蓝牙的职责限定在极小的范围内手机通过BLE GATT服务写几个字节设备解析后做动作再通过Notify回几个字节。BLE透传的特点是连接快、功耗低、协议栈相对简单但传输速率和吞吐量远不如A2DP不适合传音频流传指令却是绰绰有余。所以需求定下来非常简单手机端和终端之间只需要一个自定义的GATT服务定义两到三个Characteristic一个负责接收手机下发的指令一个负责把设备状态回传给手机最多再加一个用于电量、信号等信息的只读特征值。设备端“会说话”这件事完全由本地语音播报解决。1.2 本地语音播报的本质Flash里存文件事件来了就放本地语音播报核心不在蓝牙而在芯片的音频播放通路。常见有两种实现方式一是芯片内部或外挂Flash里存好语音资源事件触发后通过DAC直接播放二是通过PWM模拟语音输出再外接滤波和功放。第一种音质稳定、开发简单第二种成本极低但音质和音量都有限。很多产品经理会把“能播报”和“能听歌”混为一谈。实际上一个只做本地语音播报的设备不需要接收任何无线音频流播放的内容在出厂前就已经烧录进Flash了。设备要做的事只有三件听BLE指令、查Flash对应词条、播放这段语音。用生活类比的话A2DP像电视直播数据必须实时拉到屏幕本地语音播报像录像回放内容早就存好了遥控器按下才放。这个区别直接影响选型方向如果只做本地语音播报芯片可以不需要A2DP协议栈但必须带DAC、带Flash存储资源、带可用的音频播放接口。这时候你会发现传统意义上的“蓝牙音频芯片”反而是最顺手的载体因为它们天生自带音频播放能力。1.3 需求定稿时的三句话清单在正式选型之前我把需求压成了三句话这里也分享给大家参考手机通过BLE连接设备下发查询、控制、参数配置等指令设备需要回复状态。设备在特定事件下本地播报语音提示比如“欢迎使用”“余额不足”“正在充值”。不需要把手机音乐推给设备不需要连续音频流不需要A2DP。这三句话看起来简单但每一条都在筛选芯片。第一句要求BLE协议栈成熟、GATT服务可定制第二句要求有DAC、有语音资源管理第三句帮我们排除了大量“先按蓝牙音箱方案做反正也能播报”的弯路。很多项目拖着不交付就是因为需求里混入了不必要的音频流能力导致功耗、成本、认证全部翻倍。我最常用的一句话给团队做对齐**通道是BLE声音是本地蓝牙只传指令芯片负责讲话。**能把这句说明白选型就完成了一半。2. 国产芯片选型池三条路线先把“谁做声音”这件事定下来2.1 路线A带DAC的音频SoC杰理/中科蓝讯是主要玩家第一类是杰理、中科蓝讯为代表的蓝牙音频SoC。这类芯片本来为蓝牙音箱、蓝牙耳机设计自带DAC、音频功放接口、Flash资源管理SDK里也配好了语音播报的完整链路。用在“BLE透传本地语音播报”场景属于降维打击你不需要额外接语音IC也不用为DAC电路发愁直接把语音资源放进去BLE收到指令后调用播报接口就行。杰理在这里的生态尤其值得一提。AC69xx系列在蓝牙音箱和水控方案里出货量很大模组厂商多资料相对好找。SDK虽然初次上手有些“自家风格”但一旦跑起来BLE透传、按键播报、事件播报、语音提示这些功能基本都能在工程模板里找到现成例子。中科蓝讯更偏向TWS耳机市场但它的方案同样具备DAC和BLE能力只是大多数资料面向耳机场景做非耳机类终端时需要自己多摸索。路线A的特点是“声音这件事完全不用你操心”代价是低功耗能力通常不如纯BLE SoC尤其是带音频功放时待机电流和休眠电流会高一些对市电供电或锂电池容量较大的设备完全没问题对纽扣电池设备就比较吃力。2.2 路线B低功耗BLE SoC 语音外设泰凌微/奉加微方向第二类是泰凌微TLSR8258、奉加微PHY6222、博通集成BK3431/BK3435这类纯低功耗BLE SoC。它们内部没有音频DAC也没有功放但BLE协议栈非常扎实sleep电流能做到很低的水平适合做智能锁、传感器节点、电子标签这类靠电池活很久的设备。既然芯片本身不会“发声”就需要外接音频播放单元。常见做法是外挂一颗串口语音IC比如唯创的JQ8900、BY8301这类模块主控通过串口或IO触发语音播放也可以外接DAC加功放把语音文件解码后的数据喂给DAC。前一种方案开发最简单语音文件存在语音IC的Flash里主控只需要发一个字节指令就能触发后一种方案成本略低但软件工作量和射频布局风险都更大。路线B的核心价值在功耗。如果设备要求一年不充电、休眠电流低于10uA量级、日常不带音量那音频SoC确实做不到只能走这个方向。代价是BOM上多一颗语音ICPCB多几个器件软件上也要维护两条串口链路。2.3 路线CMCU 透传模块 串口语音IC慢项目里的稳妥解法第三类是把“蓝牙”和“语音”都外包主控用普通MCU蓝牙用现成透传模块语音用现成语音模块。这类方案技术门槛最低很多不熟悉BLE协议栈的小团队会选因为主控只需要处理串口收发蓝牙模块和语音模块各自买来就能用。但它的缺点同样明显。一颗普通MCU加一颗蓝牙透传模块加一颗语音模块三颗物料的总成本往往超过一颗集成方案PCB面积也更大。模块之间的串口通信、电平匹配、天线干扰都可能引入新的问题。更麻烦的是BLE模块通常不开放内部协议栈你想做深一点的连接参数优化、广播策略调整、低功耗唤醒管理基本都被模块厂商的固件限制住了。所以我的判断是路线C适合项目数量小、排期紧、团队完全没有蓝牙开发经验、且对成本不敏感的情况。一旦产品要量产几千台以上路线C的整体开销反而更高不推荐作为长期方案。2.4 三条路线的对比表格对比维度路线A音频SoC路线BBLE SoC 语音外设路线CMCU 透传模块 语音IC代表方向杰理AC69xx、中科蓝讯泰凌微TLSR8258、奉加微PHY6222任意MCU HC/JDY/BLE模块语音播报内置DAC直接放需外接语音IC或DAC需外接语音ICBLE透传能力成熟可定制GATT成熟可深度定制依赖模块固件定制有限低功耗表现一般休眠偏高优秀适合电池长续航取决于MCU和模块整体一般开发难度中SDK有学习期中高音频链路要自行调低串口搞定单位BOM成本中低集成度高中加语音IC高三颗物料适合场景水控、售货机、锁、家电纽扣电池终端小批量、快速验证3. 我最终拍板的方案按“水控器场景”给出一个可落地的选型结论3.1 参考场景和需求基线为了让结论不悬空我把这次选型的样本场景说具体一点我们要做的是一台宿舍浴室用的蓝牙水控终端用户拿手机小程序扫码或连接BLE然后查询余额、开始用水、扣费结束。设备需要在自己内部判断事件并播报“欢迎使用”“余额不足请充值”“本次消费X元”等十几条语音。这个场景有几个硬约束第一设备供电是锂电加充电管理不是纽扣电池所以对低功耗有要求但不极端第二用户离设备最多一两米蓝牙距离不构成压力第三语音内容固定不会频繁更新第四量产数量在几千台BOM成本非常敏感。有了这些硬约束选型就不是拍脑袋了而是每一条都能检验。我建议的基线是BLE连接成功后手机发一条查询余额指令设备在100ms内回状态并在余额低于阈值时本地播报。这个基线把“BLE透传”和“本地语音播报”两个核心需求都钉死了。3.2 为什么优先选杰理AC69xx/G系列这个场景我最终选了杰理AC69xx系列作为主控具体型号以厂家最新释放为准。核心理由有四点。第一自带音频DAC和功放接口语音播报最小系统只需要一颗芯片加一颗喇叭功放外围器件少PCB面积小量产组装成本低。第二杰理在蓝牙音频/水控这个圈子的方案积累深SDK里直接能找到BLE透传的GATT服务例子也能找到事件语音播报的调用接口。我们不需要从零去拼一个音频播放链路这是纯BLE SoC给不了的优势。第三AC69xx系列的Flash容量足够放几十条语音提示。按照每条语音1到2秒、用中低采样率压缩的算法整个语音包也才几百KB不会把方案撑爆。第四模组供应链成熟。前期验证可以直接买现成模组等确认功能后再做板载设计开发和量产节奏都能压缩。3.3 什么时候应该换成TLSR8258我也要诚实说一句杰理方案并不是万能答案。如果需求稍微偏一点就必须换成泰凌微TLSR8258或同级别BLE SoC加语音外设。判断标准只有几条设备是否必须用纽扣电池并且待机一年以上设备是否完全没有实体电源开关需要长期挂在广播/休眠状态整机休眠电流是否要求做到10uA以下只要有一个回答“是”音频SoC基本可以排除。TLSR8258这类芯片在低功耗上的功底是音频SoC比不了的虽然需要外挂语音IC但换来的是更长的续航和更稳定的长期待机表现。还有一种情况也可以考虑路线B项目本身需要做Zigbee或Thread想在同一颗芯片上兼顾BLE和多协议。TLSR8258原生支持多种协议这是它独特的优势。如果只是纯BLE加语音没必要为这个能力买单。3.4 成本账单颗物料价格、模组价、开发成本成本方面我按印象给个量级供参考不代表具体报价。路线A的音频SoC单颗价格通常在几元人民币范围内但因为它集成了DAC和语音能力省掉了外挂语音IC的钱整体BOM会比路线B、路线C更紧凑。路线B的BLE SoC单颗更便宜但加一颗语音IC后整体BOM并不占优势。路线C是最贵的一颗透传模块就吃掉不少预算。如果计算开发成本路线A和路线B都需要投入一到两周熟悉SDK路线C基本当天就能跑通串口。但开发成本是一次性的BOM成本是每台机器都在付的所以量产数量超过千台之后路线A的优势会越来越明显。我个人经验是项目到了“几千台起步”这个规模就不要再看模块单价那几毛钱的差异了真正影响利润的是整机BOM、装配工时和售后返修率。集成度越高通常意味着装配越简单、故障点越少。4. 从空白工程到样机出声的完整流程以AC69xx为例4.1 硬件最小系统的几个关键脚第一步是搭硬件。以AC69xx做板载为例最小系统包含供电、晶振、Flash、音频输出、天线这几块。供电部分芯片通常支持3.3V或5V输入板子上要放一个LDO输入侧加100uF电解电容和0.1uF陶瓷电容。特别提醒音频设备对电源纹波敏感如果供电纹波大语音播报时会出现明显的底噪这个问题比很多人想象中更容易出现。晶振一般用24MHz布局时要尽量靠近芯片走线短一点。Flash看SDK和型号有的型号内置Flash有的需要外挂。外挂Flash选普通SPI NOR Flash就行但要注意语音资源区域和固件区域的划分别把两个区域搞重叠。音频输出端DAC输出通常需要经过RC滤波后送入功放。功放可以选国产的几百毫瓦级AB类功放驱动4欧或8欧的喇叭。喇叭端要加ESD器件和TVS因为设备和人体接触频繁静电打坏DAC的事故在量产中很常见。天线部分建议预留π型匹配网络也就是串联两个电感/电容加并联一个电容的布局先不贴元件等到实验室调射频时再根据实际S11和测试距离确定值。4.2 BLE透传服务怎么搭GATT服务设计和数据帧格式AC69xx的SDK里会提供BLE工程模板通常自带一个透传服务。你可以直接复用也可以改成自定义UUID。我一般建议改成自己的UUID避免和市面上的公版模板混淆也能防止用户装了多个App互相干扰。自定义GATT服务建议加三个CharacteristicRX手机写入设备UUID自定义属性为Write负责接收指令。TX设备通知手机UUID自定义属性为Notify负责回复状态。可能需要一个DeviceInfo或电量只读特征值属性为Read。数据帧格式一定要在最早期定死。我用的是一套极简格式帧头 0xA5 命令 例如 0x01 查询余额 / 0x02 开始用水 / 0x03 停止用水 长度 数据字节数 数据 实际内容如余额金额 校验 数据异或和或者CRC16给个具体例子手机查询余额发送A5 01 01 00 01最后一位是前面字节的异或和。设备收到后校验通过回复A5 81 04 00 00 02 58 5F。这套格式简单到在MCU裸机上都能轻松解析不需要引入复杂的协议栈概念。编写代码时建议把帧解析做成独立函数不要散落在各处。BLE NOTE的Packet大小有限一帧不超过20字节如果指令内容多就需要分帧发送在应用层做粘包和组包。这个细节在初期不处理后面联调时一定会被它折磨。4.3 本地语音词条的生成、烧录与触发语音词条的来源有两个一是找人录音二是用TTS合成。对水控器这种提示语用TTS合成就够了关键是把“采样率”“编码格式”“导出格式”统一。杰理SDK一般会带语音资源生成工具把WAV文件转换成SDK可识别的资源文件。转换时建议先统一转成8kHz采样的单声道音频码率控制在中等档位。这样一条1秒的语音大约只占20到30KB整个提示语包能做到很小。这里有个质朴又容易忽略的“库容量计算”如果采样率翻倍、码率翻倍语音包体积直接翻四倍Flash容量可能不够。把音频资源通过烧录工具下载到Flash后在SDK里通过工具分配到的WordAddr来触发。触发逻辑很简单收到指令解析出事件号然后调用SDK里的语音播报接口把对应的词条ID传进去。比如收到“余额不足”指令后void on_balance_low_event(void) { // 指定词条IDSDK内部会去Flash取音频并播放 speech_play_by_id(SPEECH_ID_BALANCE_LOW); }需要注意语音播报接口调用后芯片会占用DAC和功放如果此时还有别的音频逻辑需要做优先级管理。例如设备正在播报“余额不足”时用户又触发了“本次消费X元”系统要决定是打断前一条还是排队播放。一个简单的做法是加一个播放队列后一条指令先等前一条播完。4.4 与手机App的联调顺序联调阶段我强烈建议从最简单的工具开始而不是一上来就写小程序。先用nRF Connect或类似BLE调试工具扫描到设备找到自定义的Service UUID先测试写入“查询余额”指令看设备回包是否正常。确认基本读写没问题后再用调试工具订阅TX的Notify通道看设备主动上报的数据是否完整。很多问题都出在订阅时机上手机没有订阅就收不到Notify设备端如果没检测到CCCD值变化就发NotifyApp端自然什么都收不到。最后再上小程序或者正式App把整套业务流程走一遍。这里特别提醒App端一定要处理好“蓝牙断开重连”的逻辑。BLE设备的连接并不像想象的那么稳用户拿着手机走远一步连接就可能断开设备语音播报播完之后要及时把连接参数和广播状态恢复好。整个过程中串口Log是救命工具。调试阶段把BLE收发的每一帧都打印出来和手机端收到的数据对比很快就能定位问题。5. 量产前必须躲开的五个坑以及我的验证方法5.1 射频距离天线匹配不是玄学很多项目死在“实验室里好好的到现场连不上”。BLE虽然工作在2.4GHz但射频性能和PCB布局强相关。天线附近不要铺铜净空区要留够走线要尽量短阻抗控制按芯片参考设计做。打样阶段务必预留π型匹配位置样机回来后用频谱仪或网络分析仪调匹配。没有仪器的话可以实际用手机测RSSI同一位置同一信道记录距离1米、3米、5米的信号强度。如果RSSI衰减过快基本是天线的阻抗没调好。这个测试必须在整机状态下做壳子、电池、螺丝都会影响天线效果裸板测试的数据不能代表最终量产。5.2 语音播报与低功耗的取舍水控器虽然不要求纽扣电池级功耗但也不能完全不管休眠电流。音频SoC播报时功放消耗可观如果你一直让芯片处于满速运行待机电流会很难看。合理的做法是平时让系统进入低功耗休眠状态BLE保持广播或浅睡只有收到有效指令或到了定时唤醒事件时才彻底醒来播报完立刻休眠。那一次语音播报本身就会带来几十到几百毫安瞬间电流时间很短对电池容量的压力有限真正耗电的是“长时间空转”和“不必要的定时器唤醒”。测试低功耗不能只看规格书。我建议用高精度电流计看整机真实电流曲线验证“休眠-唤醒-广播-连接-播报-休眠”这个完整循环确认每个状态的电流和时间都在预期内。5.3 Flash容量与语音时长要一起算Flash规划要放在项目第一天不要等语音全部录完才发现放不下。算一下账按10条提示语、每条2秒、共20秒音频来算如果用8kHz采样率压缩码率32kbps20秒音频大约80KB非常宽裕。但如果你在录音时用了44.1kHz采样、高码率MP3再翻几倍Flash就吃紧了。我这里建议把采样率统一控制在低档音质对提示语来说足够换来的是Flash空间余量。修改语音词条后要重新生成资源文件并重新烧录这个过程最好做成脚本避免每次手动拖拽出错。还要注意Flash的擦写寿命和编程电压量产烧录时如果不稳定会出现个别设备语音播放破音或干脆没声音。产测流程里一定要加一条“触发每条语音并人工/自动听音”的检查项。5.4 手机兼容性iOS/Android不能只拿一台测BLE看起来是个标准协议但各厂商手机的实际表现差别很大。iOS对BLE连接参数有自己的一套要求如果你的设备广播间隔过短、连接参数太激进iPhone会拒绝连接或者频繁断开。Android这边碎片化更严重不同厂家对蓝牙权限、后台扫描、系统省电策略的处理方式都不同。我的建议是准备一个手机兼容性矩阵覆盖iPhone至少两款、Android主流厂商至少三款以上每台手机都要完整走一遍“扫码连接-查询-充值-播报”的流程。这里最常见的问题就是测试人员用自己手机测了两天没问题一到用户手上安卓手机锁屏后BLE连接被系统杀掉设备不播报了。解决方案是在App端引导用户开启后台蓝牙权限同时设备端要在连接断开后快速恢复广播。5.5 认证、烧录和产测方便量产的方案才叫好方案方案能跑通只是第一步能顺利量产才能叫“好方案”。国内销售通常需要做无线型号核准SRRC如果需要合法使用蓝牙商标还要考虑蓝牙技术联盟的相关认证。这些认证在选型阶段就要查清楚芯片原厂一般会提供对应的认证资料和QDID帮你省去大量重复测试。量产阶段还要考虑烧录效率。语音资源、固件、MAC地址尽量合并成一次烧录。如果工厂希望先用治具批量刷机你需要提前确认SDK支持哪种烧录工具并把产测固件准备好。千万不要等产品上线了才考虑产测那时候每发现一个烧录问题都要多花几倍的返工成本。补一条从实际项目里摸出来的经验量产前一定要安排至少50台样机做“高温高湿长时间待机”的摸底特别是带喇叭的设备。语音播报时DAC和功放发热量不小如果散热不好个别元器件在高温下会漂移出现音量变小、破音甚至无声。这类问题在早期样机上很难暴露到了批量发货阶段再发现就是大事故。另外做这类“本地语音播报加BLE透传”的产品不要贪心集成太多功能进去。很多时候产品经理会建议“顺便支持一下手机音乐播放”这会让功耗、认证和软件复杂度同时上涨性价比极低。一口咬定“只听指令、只发状态、本地播放”反而能让项目在最短时间内落地。