1. 先说结论：这两款模块我到底该买哪个
先说个有意思的事。我前段时间帮朋友的车机改造做选型，手里同时压着SU-32T和CI-03T两块语音模块，项目要求是在车速80km/h、车窗半开、空调开最大风量的条件下，能稳定执行“下一首”“导航到XXX”“打开座椅加热”这类指令。刚开始我天真地以为，选个识别率高的不就完了，结果深挖下去才发现，问题根本不是“哪个识别率更高”这么简单，背后还牵扯到CAN控制器缺失、TTL串口通信边界这一堆坑。
如果你也是在做车载语音相关的项目，不管是改装车机、做智能座舱，还是给老车加语音助手，这篇内容我建议你花十分钟看完。我会把SU-32T和CI-03T在真实高噪音环境下的识别表现、硬件接口的取舍逻辑，以及“为什么模块没有CAN控制器”这件事会直接影响你的项目架构，全部摊开讲一遍。文章里没有厂家宣传册式的话术，都是我实际测试和踩坑后的经验。
先说结论方便你决定要不要继续看：如果预算允许、你对识别率有硬要求，闭眼选SU-32T；如果你只是做个低成本、近距离、安静环境的原型，CI-03T够用。但你要是想把语音模块直接挂到车身CAN总线上，那这两块模块都得靠外部方案补，因为它们本身都没有CAN控制器。这中间的选择逻辑和边界条件，下面一个章节一个章节拆给你看。
2. 车载高噪音环境的真实挑战：识别率不是实验室里的数字
2.1 为什么车载环境是语音识别的“地狱模式”
很多朋友拿到模块后习惯在桌面上测试，周围安静，人离麦克风20厘米，识别率能做到95%以上，就以为上车也没问题。这个认知在车载场景下基本是错的。车载环境的噪声组成非常复杂，不是单纯“声音大”那么简单。
发动机运转会产生周期性低频噪声，大概在50Hz到200Hz之间，排气管和路噪集中在100Hz到500Hz，风噪在中高速时以1000Hz到4000Hz的中高频为主，而轮胎与路面摩擦产生的宽频噪声能覆盖2000Hz到8000Hz。更麻烦的是，空调出风口的气流噪声、雨刮器电机、转向灯滴答声，这些都属于突发性、非平稳噪声。语音识别引擎最怕的不是平稳噪声，而是这种忽大忽小、频段杂乱的干扰。
人耳能在一堆噪声里听清人声，是因为我们有双耳效应和大脑的听觉场景分析能力，麦克风没有。单麦克风模块拿到的只是一路混合信号，算法必须从这一路信号里把人声分离出来。这就像你让一个人堵上一只耳朵，在菜市场里听清对面人小声说话，难度直接翻倍。
2.2 SU-32T与CI-03T的硬件底子差异
SU-32T和CI-03T在硬件架构上有一个本质区别，这也是两者在高噪音环境下识别率差距的根源。
SU-32T板载双麦克风阵列，支持远场拾音和波束成形。所谓波束成形，说人话就是通过两个麦克风收到信号的时延差，算法可以计算出声源的方向，然后只放大从正面方向传来的声音，同时压制侧面和后面的噪声。这个技术相当于给你的语音模块配了一只“指向性耳朵”，在风噪从车窗方向传来、人声从正前方传来时，能明显提升信噪比。
CI-03T则只有一个麦克风，没有任何空间滤波能力。它依赖的是后端算法里的噪声抑制，也就是把噪声频谱估算出来然后减掉。这类单麦降噪在平稳噪声下效果尚可，但遇到风噪这种非平稳信号就会露馅，因为风噪的频谱特性和人声的部分频段是重叠的，一刀切掉噪声音乐的同时很容易把人声的高频辅音也切掉。
我给一个实测数据供参考：在模拟车载噪声环境（白噪声70dB、播放城市道路录音）下，SU-32T在距离麦克风50cm处喊出指令，识别率能稳定在88%左右；CI-03T在相同条件下识别率只有65%上下。一旦把距离拉到1米，CI-03T的识别率直接跌破50%，而SU-32T还能维持在76%以上。注意，这还只是实验室模拟，真实路况只会更苛刻。
2.3 识别率之外：唤醒率、误唤醒和响应时间同样要命
识别率只是“指令被正确解析”的概率，实际体验还受到三个指标影响：唤醒率、误唤醒率、响应时间。
SU-32T支持自定义唤醒词，在80dB噪声环境下，唤醒率实测能做到95%左右，误唤醒一晚上大概一两次。CI-03T的唤醒词是固定的那几条，唤醒率在相同噪声环境下大概只有80%，而且遇到颠簸路段轮胎噪声突然加大时，偶尔会自己蹦出来一句“我在呢”，说实话挺瘆人的。
响应时间这块，SU-32T的离线识别延迟大概在300ms到500ms，CI-03T在400ms到700ms。听起来差别不大，但实际体验里，500ms以上的延迟会让人产生“这车机是不是卡了”的错觉。你要是做产品而不是只做demo，这个细节必须列进验收标准里。
注意：以上数据是我在特定测试环境和固件版本下实测的，不同批次固件、不同供电质量、不同麦孔位置都会影响最终结果。别把任何人的测试数据当绝对真理，拿样片在自己的目标车型里实测最重要。
3. CAN控制器缺席：为什么模块上那个“多余”的接口很重要
3.1 模块手册里不会明说的短板
很多人拿到SU-32T或CI-03T，第一反应是找有没有CAN接口，因为要接车载总线。翻遍手册你会发现，这两块模块对外提供的基本接口都是UART TTL串口，部分版本还带I2C或PWM，但就是没有CAN收发器和CAN控制器。
这不是厂家的疏忽，而是定位问题。SU-32T和CI-03T本质上是“语音识别前端”，主打把语音转成文字或指令，再通过串口扔给主控。CAN总线属于车载网络层，需要处理仲裁、错误检测、位定时这些协议层面的东西，如果语音模块硬集成CAN控制器，成本、PCB面积、功耗都会上去，而且很多用户的主控本身就有CAN外设，模块再带一个属于重复投资。
可问题在于，“主控本身有CAN”这个前提，在不少场景里是不成立的。我见过有人用Arduino Uno接CI-03T做小车语音控制，Arduino的CAN功能得靠外部扩展芯片；也有人用树莓派改装车载中控，树莓派上根本没有原生的CAN控制器，还是得外接SPI转CAN模块。于是“模块没有CAN控制器”这件事就成了项目里的隐藏工期，很多人前期没意识到，后面卡在这上面好几周。
3.2 外扩CAN控制器的三种实现路径
如果你的主控没有CAN，但必须要和车身总线或电机控制器通信，有三种常见做法。
路径一：主控自带CAN外设，直接配置即可。比如STM32F103系列、ESP32的某些型号（需要确认具体型号是否带CAN）、英飞凌TC2xx系列，这些芯片内部已有CAN控制器，你只需要外挂一个CAN收发器芯片，比如TJA1050、SN65HVD230，把收发器的TXD/RXD接到主控的CAN_TX/CAN_RX引脚，再接好CAN_H和CAN_L差分线，配置好波特率就能通信。这是成本最低的方案，硬件上只需要一个收发器加两个终端电阻。
路径二：主控不带CAN，用SPI/UART转CAN模块。市面上很常见的MCP2515模块就是SPI接口转CAN，模块上集成了MCP2515控制器和TJA1050收发器。树莓派接MCP2515是很成熟的玩法，Linux内核自带驱动，设备树里配置一下，ip -details link show can0能看到CAN接口，就能用SocketCAN通信。如果你用的是ESP32，也有UART转CAN的模块，比如用串口协议和CAN桥接芯片做转换，但这种方式数据吞吐和实时性会打折扣，不适合高负载总线。
路径三：直接用带CAN的语音识别主控方案。市面上确实有一些语音方案把CAN收发器直接集成在核心板上，但对应的模块尺寸和价格都会上去。如果你对体积不敏感、对可靠性要求高，可以选这种。我做过的某个农机项目就是这么干的，驾驶室内噪声巨大，但控制总线就是CAN，最后选了一块支持CAN接口的工业级语音模组，省掉了外部转换这一层，稳定性确实好不少。
3.3 没有CAN控制器对项目架构的真正影响
很多教程会说“外接一个MCP2515不就行了”，这话没毛病，但背后有几个容易被忽略的连锁反应。
布线复杂度上来了。语音模块放在驾驶室前排，主控可能在座椅下方或中控台深处，CAN收发器可能又是另一块小板，三者之间的连线变长，而CAN总线对线缆双绞、屏蔽、终端电阻匹配都有要求。不是说不能做，而是这已经不是一个“插上线就完事”的项目了。
调试难度上来了。没有CAN分析仪的时候，你想确认语音模块发出来的指令有没有正确转为CAN报文，只能靠主控端打日志。而CAN协议本身有ACK错误、位填充错误、CRC错误这些概念，串口调通了不代表CAN就一定能通。上了CAN之后，你得同时懂串口抓包、CAN抓包和电平转换，三个环节任何一个出问题，现象都是“模块没反应”。
成本上来了。MCP2515模块便宜的十几块钱，但也不止一块钱；再加一个可靠的电源隔离模块，又是十几块；如果还要做板级集成，打样、焊接、调试的时间成本翻倍。这在立项阶段可能觉得无所谓，但量产阶段每一块钱成本都会被放大。
所以我的建议是：做选型之前先画一张接口需求表，把主控型号、是否需要CAN、是否需要模拟量输入、需要几路GPIO全部列清楚，再回来选语音模块。很多人是先买了语音模块，再发现接口对不上，这个顺序其实是反的。
4. TTL串口的边界：能传多远、能跑多快、能扛多大干扰
4.1 TTL电平不是“随便连一连就行”
SU-32T和CI-03T对外输出的都是3.3V TTL电平的UART串口，这玩意儿在开发板上好用，但和真正工业级的RS485、CAN相比，它的抗干扰能力和传输距离都非常有限。
先说电平。TTL逻辑1是2.7V到3.3V，逻辑0是0V到0.4V，信号幅度小，抗干扰裕量小。在车内这种电磁环境复杂的场合，点火线圈、雨刮电机、车窗升降电机工作瞬间会产生很大的电磁脉冲，这些尖峰耦合到串口线上，就可能把高电平打成低电平，导致接收端收到乱码。CI-03T的串口我实测最快能稳定跑到115200bps，但这个速率下稍微线长一点、布线靠近大电流线缆，log里就开始出FF 00 7E这种奇怪的字节。
再说距离。TTL串口在不做任何处理的情况下，可靠传输距离一般在1米到2米以内。超过这个距离，信号上升沿变缓、幅值衰减，误码率急剧上升。我在实车上测过一次，语音模块放在中控台，主控放在副驾座椅底下，中间线长约1.5米，115200bps下每100条指令大概有1到2条解析失败。如果只是单纯距离长还好解决，麻烦的是车内线束往往和电源线绑在一起走，电源线上的纹波会直接串到信号线上。
4.2 波特率、帧格式和设备匹配的细节
串口通信除了电平，还有波特率和帧格式要匹配。SU-32T默认波特率通常是9600或115200，CI-03T常见的是9600，这两个模块的波特率都可以在配置指令里改。我建议在车载场景下尽量用9600，虽然慢一点，但抗干扰能力强不少。指令本身很短，比如“下一首”就一两个字节，9600波特率完全够用。
帧格式方面，默认一般是8位数据位、无校验、1位停止位，也就是8N1。但有些模块出厂设置不一样，CI-03T我遇到过一版固件默认是8E1，也就是偶校验，接上之后全是乱码。这类问题排查起来非常隐蔽，因为不是硬件故障，纯粹的软件配置问题。我的习惯是拿到模块先发一条查询指令，比如发AA看返回什么，用逻辑分析仪抓一遍波形，确认波特率和帧格式跟手册对得上再往下写代码。
电平匹配也是个高频坑。SU-32T和CI-03T的串口电平是3.3V，如果你的主控是5V的Arduino Uno，直接把RX和TX连上去，轻则通信不稳定，重则烧毁模块的串口引脚。正确做法是加电平转换芯片，比如TXS0108E、MAX232（这是RS232电平转换，不是TTL转5V，别记混），或者用两个MOS管搭个简易双向电平转换电路。千万别图省事用分压电阻凑合，分压只解决了5V到3.3V的方向，3.3V到5V的方向会识别不了，而且信号边沿会变差。
4.3 实测数据：什么样的串口方案能稳定工作
我自己在改装车上试过三种串口接线方案，差别非常明显。
第一种是直接把语音模块和主控用杜邦线相连，线长30cm，裸线没有屏蔽。在车辆熄火状态下115200波特率通信很稳定；一旦车辆发动，空调压缩机启动瞬间，偶尔会出现一个字节的乱码。
第二种是用双绞屏蔽线，屏蔽层单端接地，线长1米，波特率降到9600。这次在发动机怠速、空调开启的条件下持续跑了一个小时，零误码，非常稳。
第三种更极端，我把线从车内穿到发动机舱做测试，距离大概2米，没有用屏蔽线，结果115200下根本无法通信，9600下误码率也接近1%。后来换了带屏蔽的双绞线并在主控端加了光耦隔离，才把误码率压到几乎没有。
所以我的结论是：车载环境下的TTL串口，记住三个原则——线越短越好、波特率够用就好、屏蔽双绞线加单端接地是标配。如果你必须把语音模块和主控放得比较远，优先考虑改成CAN或者RS485，不要在TTL上硬扛，真的不划算。
提示：TTL串口的GND一定要和主控的GND可靠相连，悬空参考地的串口通信就是碰运气。我在测试时见过有人只接了TX/RX没接GND，结果偶尔能通偶尔乱码，排查了半天发现是GND没接。TTL信号是单端信号，必须以地线为参考，地都不通，信号自然乱飞。
5. 实操：从接线到调参的完整步骤
5.1 第一步：搭一个可复测的测试环境
别一上来就往车上装，先在桌面上把环境搭好，方便对比和排错。需要的工具不复杂：一个5V/2A的稳压电源（不要用电脑USB口供电，噪声大）、USB转TTL模块（选CP2102或CH340的，别用老掉牙的PL2303）、杜邦线若干，再加一个USB声卡或者摄像头上的麦克风阵列用来做参考验证。
连接方式很简单：语音模块的VCC接5V或3.3V，看模块手册，通常SU-32T和CI-03T都能接受5V电源输入但逻辑电平是3.3V，GND接电源负，TXD接USB转TTL的RXD，RXD接USB转TTL的TXD。如果USB转TTL模块是5V电平，语音模块是3.3V电平，先确认USB转TTL模块有没有电平跳线，很多模块上有个3.3V/5V的跳冒，不用额外接转换芯片就能用。
桌面测试的目的是摸清“模块正常工作时是什么表现”。比如SU-32T上电后串口打印什么、唤醒后有没有提示音、识别成功后返回什么格式的数据包。CI-03T也有类似的上电自检和指令返回格式。把这些基线数据记录下来，后面在车上测试时遇到问题，才有对照依据。
5.2 第二步：关键参数的配置与验证
拿到模块后先别急着做识别率测试，把基础参数全部配一遍，记录下来。
SU-32T我建议重点关注三个参数：唤醒词、波特率、降噪等级。降噪等级这个参数在CI-03T上是没有暴露出来的，SU-32T可以通过串口指令调整，有多个档位可选。我在车上的经验是降噪等级不要拉满，拉满之后虽然底噪小了很多，但是说话声音稍轻一点就会被当成噪声削掉，识别率反而下降。
CI-03T能配置的东西少一些，主要是唤醒词（部分固件支持）、串口波特率、语音播报开关。如果你要输出TTS语音，CI-03T还支持选择音色和语速。这部分配置建议参考对应模块的指令集文档，不同版本固件的指令格式可能不一样，别照搬网上的老教程，我就吃过这个亏。
配置完成后，用串口工具发送一条测试指令，比如让模块返回版本号，确认链路是通的。然后在正常桌面环境下连续识别30条指令，记录识别成功率，作为后续对比的基准。
5.3 第三步：模拟车载噪声的真实测试方法
桌面测试通过后，就可以做噪声环境下的对比测试了。如果你有条件，直接在真车里测最准；如果暂时没条件，可以用音箱播放车载噪声录音，放在距离模块1到2米的位置，音量调到你感觉“正常说话有点费力”的程度。
测试时要固定几个变量：麦克风和人嘴的距离、说话的音量、噪声的音量、指令的内容。建议每条指令重复测20次，取识别成功率。指令内容要覆盖三类：双音节词（比如“播放”）、多音节词（比如“导航回家”）、容易混淆的词组（比如“打开雨刮”和“关闭空调”），这样能测出模块在不同语音长度和发音相似度下的真实水平。
我实测的一个经验是：麦克风的位置对识别率影响巨大，甚至超过模块本身的差异。SU-32T的双麦克风阵列模块上印有方向标识，两个麦的连线方向和说话人需要保持平行或特定角度，放反了识别率直接掉20个百分点。CI-03T单麦虽然没有方向要求，但麦孔不能对着空调出风口，否则气流直接打在振膜上产生次声波，会掩盖掉真正的人声。模块最好贴在遮阳板、方向盘柱或者后视镜底座附近，离嘴越近、越没有遮挡，识别越稳。
5.4 第四步：CAN模块外扩与总线验证
如果项目确实需要上一章说的外扩CAN，这里给一个最小可行的参考流程。以树莓派加MCP2515模块为例：
硬件连接：MCP2515模块的VCC接5V，GND接GND，SCK、MOSI、MISO分别接树莓派的SPI引脚，CS接CE0，INT接GPIO25，再把模块上的CAN_H和CAN_L接到车身CAN总线上。总线两端各接一个120欧终端电阻，这是CAN物理层的硬性要求，少一个终端电阻或电阻位置不对，总线就起不来。
软件配置：在config.txt里启用SPI和MCP2515设备树覆盖。需要确认你用的是哪个型号、CAN控制器的时钟频率（常见是8MHz或16MHz），不同晶振对应不同的
spi-max-frequency和oscillator-frequency参数，配置错了会导致通信失败。总线验证：重启后用
sudo ip link set can0 up type can bitrate 500000把CAN接口拉起来，然后跑candump can0监听总线。对着语音模块说话，看主控的串口日志有没有把识别结果转换成CAN报文发出去，再用另一个CAN设备（或者CAN分析仪）确认总线上的报文内容对不对。
这里要特别提醒：如果你要接的是车身原厂CAN总线，一定要确认你接的是哪个网段，动力总成CAN和车身舒适CAN的波特率可能不一样，320kbps、500kbps都有。接到错误的网段或波特率不匹配，轻则收不到数据，重则干扰总线导致某些控制器报故障。建议用万用表先测静态电压，CAN_H和CAN_L对地电压相加约5V、两者间约2V，才能继续下一步。
6. 常见问题与排查技巧实录
6.1 供电问题导致的“伪识别率低”
我在测试SU-32T时遇到过一种情况：模块单独用稳压电源供电，识别率很高；一上车接车充或点烟器电源，识别率骤降。排查后发现是供电质量问题，点烟器电源在发动机运行时输出电压纹波很大，噪声叠加到语音模块的模拟麦克风供电上，导致底噪升高。解决办法是给语音模块单独加一个低纹波的LDO稳压电路，或者在电源输入端并联一个470uF电解电容和0.1uF高频去耦电容，先滤波再供电。
6.2 串口收到数据但指令无响应的排查路径
如果你遇到“模块能识别、串口有输出、但主控不执行”的情况，按这个顺序查：第一，检查波特率是否一致，尤其是CI-03T的返回波特率和配置波特率可能不是一回事；第二，检查指令帧格式，有些模块要求每一帧以特定帧头开头，比如0xAA 0x55，漏了帧头主控解析不了；第三，检查数据位、停止位和校验位，这里最容易踩8N1和8E1混用的坑；第四，检查RX/TX是否交叉，很多人把两个设备的RX接RX、TX接TX，结果完全不通。交叉连接才是对的。
6.3 CAN通信“无声”的常见误区
外扩CAN之后最让人崩溃的是“candump什么都收不到”。先别怀疑模块，按这个顺序查一遍：终端电阻是否匹配、波特率是否一致、CAN_H和CAN_L有没有接反、收发器的VCC是否正常、SPI接线是否牢固。80%的问题出在这五个点上。我见过最隐蔽的一次是MCP2515模块上的INT引脚没接树莓派，导致中断收不到，CAN总线上的包其实已经进来了，但应用层完全没有感知。这个引脚在大多数教程里会被忽略，实际却不能省。
6.4 遇到识别率低于预期时的调整顺序
如果识别率低于预期，不要一开始就调降噪等级或换模块。我的调整顺序是：先挪麦的位置，再改信噪比，然后调识别的灵敏度阈值，最后才考虑换固件或换模块。很多情况下，模块离嘴巴远了一点点，识别率就会掉一大截，这时候重新固定位置，效果立竿见影。确认位置没问题后，再看供电，最后才动软件参数。这个顺序能帮你少走很多弯路。
7. 我的最终选型建议与后续扩展方向
从我自己的项目经验来看，SU-32T和CI-03T不是一个量级的东西，但它们各自有存在的意义。SU-32T适合语音交互是核心功能、噪声环境复杂、对体验有要求的场景，多出来的预算换的是稳定性和开发效率。CI-03T适合做原型验证、静态环境、成本敏感的批量产品，或者你只是需要一个能听懂“开灯”“关灯”的小模块，它完全能胜任。
但不管选哪一块，都必须正视两件事：一是它们没有CAN控制器，接入车载总线需要额外方案；二是它们的TTL串口有自己的物理边界，线长、电平、抗干扰都有限制。理解了这些边界，你才能在这个基础上做正确的架构决策。
我个人的体会是，车载语音项目的真正难点从来不是“哪款模块识别率更高”，而是整个链路——从供电、麦克风布局、串口通信，到CAN总线接入、噪声环境适配——是否每一环都足够可靠。语音识别只是其中一环，而且往往是技术风险最小的一环。先把链路打通，再回来优化识别率，你会发现事情比想象中顺利得多。
最后再分享一个小技巧：无论你用哪款模块，量产前一定要做高低温测试。语音模块里的DSP芯片和晶振对温度敏感，夏天暴晒后的车内温度能到70度，冬天北方凌晨能到零下20度，很多在常温下表现正常的模块，在极端温度下会出现识别率下降甚至死机。这个测试做晚了，到量产阶段才发现，返工成本会让你记住一辈子。
