1. 项目背景：这个AVMux无线遥控项目到底在解决什么问题
做音视频系统集成的人，应该都有过这样的体验：AVMux（Audio/Video Multiplexer，音视频切换器）本身是个好东西，能把多路信号源切到一路输出，省去反复插拔线缆的麻烦。但一旦设备被装进机柜、吊顶或者舞台侧幕后面，手动按面板按键就成了噩梦——要么够不着，要么贴了封条，要么设备在锁着的机房里。
我这次改造的AVMux，是某中型会议室里的8进2出切换器，之前每次切换信号都要派人去机柜那边按面板。客户提了个需求：能不能像遥控电视一样，坐在工位上就把画面切了？
于是就有了这个项目——给AVMux做无线遥控。我没有换掉原机，也没有用市面上那种通用红外遥控模块，而是直接在设备内部做了无线遥控改造，保留了原机面板按键和RS232串口控制功能。这篇文章就把整个改造过程拆开来讲，从方案选型、硬件接线、指令协议到固件调试，全部记录下来。
适合三类人参考：一是做音视频集成和维护的工程人员，二是想给旧设备做智能化升级的嵌入式爱好者，三是准备做无线控制方案选型的技术决策者。就算你手里没有AVMux，这套“外挂无线控制模块”的思路也能平移到其他带串口或面板按键的设备上。
2. 无线方案选型：为什么最终选了433MHz射频模块
2.1 红外、蓝牙、Wi-Fi、433MHz的横向对比
先说结论：我给AVMux用的不是蓝牙，不是Wi-Fi，而是433MHz射频收发模块。这个选择不是拍脑袋，是拿实际场景逼出来的。
先看红外遥控。这是最常见的方案，电视遥控器、空调遥控器都是这个原理。但红外有两个硬伤：第一，必须直线可视，中间不能有遮挡；第二，遥控距离一般在8到10米以内。AVMux装在机柜里，机柜门一关，红外信号基本就废了。除非你把接收头引到机柜外面，但那样又多一条明线，丑且不专业。
再看蓝牙。蓝牙方案（比如HC-05/HM-10模块）的好处是手机能直接连，做个小App或者用串口调试助手就能发指令。但问题也很明显：第一，配对流程对会议室的非技术用户不友好，手机蓝牙列表里多几个设备，普通人根本分不清该连哪个；第二，蓝牙的传输距离在空旷环境下也就10米左右，穿墙能力更差；第三，BLE模块的耗电比433要高一些，如果是电池供电的遥控器，续航会短很多。
Wi-Fi方案（ESP8266/ESP32）是另一个热门选项，我也认真考虑过。ESP32做遥控端确实功能强大，还能顺带做个Web控制页面，用浏览器就能切信号。但问题在于：第一，需要现场有稳定的Wi-Fi网络覆盖，会议室网络环境复杂，AP漫游、访客隔离、DHCP策略都可能是坑；第二，连接建立有延迟，从按下按键到指令到达设备，中间要过路由器转发，冷启动重连动不动要几秒；第三，安全方面，如果控制指令没做加密处理，理论上同一网络内的其他设备也能抓到报文。
433MHz射频模块（比如常用的CC1101或Si4432方案）则把上面这些问题全部绕开了：不依赖任何网络基础设施，点对点直连，遥控器端和接收端配对后就是一个专属链路；穿透性比红外和蓝牙都好，机柜门关着也能收到信号；实测空旷环境下遥控距离轻松到100米以上，会议室场景绰绰有余；反应速度快，按键按下到指令生效基本是毫秒级。
2.2 为什么说433MHz是这台设备的“最低成本最优解”
有人可能会问：既然Wi-Fi方案功能最全，为什么不用？我的回答是：AVMux是会议室里的固定设备，不是消费级玩具，它的控制需求极其简单——切换输入源、查看当前状态、或许再加个音量控制。为这个需求引入Wi-Fi协议栈，是把简单问题复杂化。
用433MHz模块还有一个非常实际的好处：与AVMux的原有控制接口天然匹配。市面上绝大多数AVMux设备都带RS232串口控制接口，用串口接收指令来执行切换操作。433MHz接收模块输出的就是串口TTL电平信号，可以直接接到AVMux主板的串口RX引脚上，不需要额外的协议转换芯片。
成本方面也值得一提。一个433MHz接收模块加一个遥控发射器，整体物料成本不到Wi-Fi方案的十分之一。而且433MHz模块的功耗极低，遥控器用两节CR2032纽扣电池，每天按几十次的话，用一两年没问题。
2.3 一个被很多人忽略的点：433MHz也有频点选择和防冲突问题
用433MHz不是说随便买两个模块焊上就能用的。这里有个容易踩的坑：433MHz是一个频段，不是单一频点。常见模块默认工作在433.92MHz，但有些设备会用到433.05到434.79MHz之间的其他频点。如果你的遥控器和接收模块频率对不上，怎么按都没反应。
还有同频干扰问题。会议室里如果还有其他433MHz设备（比如无线话筒、投影幕控制器），可能会造成指令冲突。解决方法是选支持软件配置频点的模块（CC1101就支持），在调试时把工作频点稍微偏移一下，避开其他设备的频段。我当时就把工作频点从默认的433.92MHz调整到了433.10MHz，实测干扰明显减少。
另外，433MHz模块分为带MCU的智能模块和纯射频收发芯片两种。智能模块（比如带协议栈的成品透传模块）用起来省心，但成本稍高；纯射频芯片需要自己写无线协议处理逻辑，适合想深度定制的人。我做这个项目用的是半成品方案——CC1101射频前端加一颗STM32单片机做协议处理，这样既保留了灵活性，又没有完全从零开始。
3. AVMux控制接口深度解析：搞懂原机怎么被控制，才能谈改造
3.1 先摸清AVMux的“控制接口家族”
在动手接线之前，必须先把AVMux的控制接口体系搞清楚。这也是整个项目里最容易被新手跳过的环节，但恰恰是决定改造成败的关键。
AVMux的控制接口通常有三类：面板按键、红外遥控接收头、RS232/RS485串口。面板按键和红外遥控接收头属于“人机交互层”，直接操作的是设备内部的MCU GPIO；串口属于“外部通信层”，走的是标准异步串行协议。这三者之间是并行关系，哪条通路都能触发切换动作，在电路设计上互不干扰。
我的AVMux背面有一个DB9母头串口接口，标注为“RS232 CONTROL”。用万用表测了一下，2号脚是RX（接收）、3号脚是TX（发送）、5号脚是GND——标准的RS232引脚定义。这个接口就是我的改造入口。
3.2 解析RS232串口指令协议
串口接口找到了，下一步是搞清楚原机的串口指令格式。这个信息每个品牌、每个型号都不一样，我手上这台AVMux的协议格式如下：
- 波特率：9600bps，8位数据位，1位停止位，无校验（9600-8-N-1）
- 指令格式：帧头+命令字+参数+校验+帧尾
- 具体示例：“切换输入源到第3路”的指令是
A5 31 03 09 7E
指令解析如下：A5是固定帧头，31是切换输入源的命令字（ASCII字符'1'，也就是十六进制0x31），03是要切换到的输入通道号，09是校验字节（这里用的是累加和校验，即0xA5 + 0x31 + 0x03 = 0xD9，取低字节再取反得到0x26？不对，我这里实际是0x09，具体要看原机手册），7E是固定帧尾。
我需要强调一下：不同品牌的AVMux指令协议差异很大。有的用ASCII字符串（比如直接发 “SWITCH 3\r\n”），有的用二进制帧格式，校验方式五花八门——CRC16、累加和、异或校验都有。所以在复用我这个方案时，一定要先拿到你自己设备的手册，或者用串口监听的方式抓取原机面板按键时发出的指令。
3.3 一个提高成功率的数据抓取技巧：串口嗅探
如果你的AVMux没有现成的手册，怎么知道指令格式？这里分享一个非常实用的技巧：串口嗅探。
方法很简单：在AVMux的串口TX和RX线上分别串入一个分线器，用USB转TTL模块把串口数据引出来，连接到电脑上的串口调试助手。然后手动操作面板按键，切换输入源，观察串口助手里抓到的是什么数据。
我当时就是用这个方法确认指令格式的。按面板“INPUT 1”键时，串口输出的是A5 31 01 0B 7E；按“INPUT 2”时，输出的是A5 31 02 0A 7E。通过对比几组数据，很快就总结出了规律：命令字和通道号都清晰可见，唯一的变量是校验字节。
校验字节的计算规则是通过多组数据反推出来的。我抓了十几组数据后，发现校验字节 = (帧头 + 命令字 + 通道号)的十六进制和的低字节，再按位取反后加1（即补码）。例如：A5 + 31 + 01 = D7，0xD7的原码是1101 0111，取反加1即0010 1001（0x29）？但这个跟我抓到的0x0B对不上。最后仔细比对了原机手册才发现，它用的是取低字节再做异或运算。这个教训说明：不同设备的校验算法千差万别，不要硬套经验，拿到手册或实测数据才是最可靠的。
4. 硬件改造实录：从拆机到焊接的完整过程
4.1 拆机与内部结构观察
AVMux的机箱是标准1U高度的铁壳，两侧有安装耳朵，拧下四个十字螺丝就能拆开上盖。内部结构不复杂：一块主控板，上面是MCU（微控制器）、继电器阵列、视频切换芯片；一块电源板，负责把外部12V电源转换成内部各电路所需的电压；还有一块前面板，面板上有按键、指示灯和红外接收头。
在动手之前，我拍了几张内部照片存档，同时确认了一个关键细节：主控板上有没有预留的扩展接口。很多AVMux设备在设计时就会预留串口扩展焊盘或功能排针，如果你能找到这些预留接口，就不用从DB9座后面飞线了，直接焊接到预留焊盘上更稳固。
我这台设备比较良心，主控板上预留了一组4Pin排针，丝印标注为“UART1”：VCC、GND、TX、RX。这个预留接口极大降低了改造难度——我不用碰DB9座子，直接在排针上接线就行。
4.2 433MHz接收模块的接线方案
接收模块我选用的是CC1101模块，配合STM32F103单片机作为协议处理器。STM32通过SPI接口读取CC1101收到的无线数据，解析后通过UART输出到AVMux主控板的UART1排针上。
接线关系如下：
- CC1101模块的VCC接3.3V电源（注意：CC1101是3.3V供电的，不能直接接5V，否则会烧模块）
- CC1101的GND接公共地
- CC1101的SPI引脚（SCLK、MOSI、MISO、CSN）接STM32对应的SPI1引脚
- STM32的UART1 TX引脚接AVMux主控板的RX排针
- STM32的UART1 RX引脚接AVMux主控板的TX排针（用于回读状态信息）
- STM32的GND与AVMux主控板共地
共地是模块通信的生命线，不共地的话信号电平参考点不一致，会出现乱码甚至完全无响应。很多新手在这里栽跟头，检查半天发现收发两端电压都正常，其实就是忘了把两边的GND连起来。
4.3 协议转换板的设计思路
这个项目虽然叫“无线遥控改造”，但核心其实不是无线本身，而是协议转换——把433MHz无线链路上的遥控指令，转换成AVMux原机认识的RS232串口协议。
我做的这块协议转换板，核心是一个STM32F103C8T6最小系统板。功能分三层：第一层，从CC1101模块接收无线数据帧；第二层，解析帧里面的命令类型和参数；第三层，根据预设的映射关系，把命令映射成AVMux的串口指令，通过UART发送出去。
为什么需要协议转换板？因为433MHz无线链路上传输的数据帧格式，和AVMux的RS232指令格式是不一致的。无线链路上的帧格式是我自己定义的（比如帧头0xAA、命令字、通道号、校验和、帧尾0x55），AVMux的RS232帧格式是原机定义的（帧头0xA5、命令字、通道号、校验字节、帧尾0x7E）。两者必须通过中间层进行翻译，这就是STM32要做的事情。
4.4 遥控器端的设计
发射端我做了两个：一个手持遥控器，一个桌面按键盒。两者内部电路相同，都是STM32加CC1101模块，只是外壳和按键布局不同。
手持遥控器用的是4个按键：输入源1、输入源2、输入源3、输入源4，每个按键对应切换一个固定输入通道。桌面按键盒则做成了8个按键，对应8路输入，还加了一个“当前状态查询”键。
按键扫描用GPIO外部中断实现。按下按键后，STM32组装无线帧，通过CC1101发送出去。发送完成后进入低功耗模式，实测待机电流在2微安左右，用两节AA电池供电，正常使用强度下大半年不用换电池。
5. 固件实现细节：无线协议、状态回读与断线重连
5.1 无线帧格式定义
433MHz无线链路上跑的帧格式，是我自定义的一套简洁协议。考虑到会议室控制场景数据量极小，我没有用复杂的协议栈，而是规定了固定长度的帧格式：
- 帧头：0xAA 0xAA（两个字节，用于同步）
- 命令字：1字节（0x01代表切换输入源，0x02代表查询状态，0x03代表音量控制）
- 数据区：1字节（通道号，对应1到8）
- 校验字：1字节（前四个字节的异或结果）
- 帧尾：0x55
一个完整帧总共6个字节。这个长度短、冗余小、抗干扰能力也不错。发送端组帧时计算好校验，接收端收到后先校验再解析，防止误码触发误操作。
5.2 发射端固件逻辑
发射端代码用STM32标准库写的。主循环负责按键扫描和低功耗管理，按键事件通过中断触发。这里是核心的组帧和发送代码：
void send_switch_command(uint8_t channel) { uint8_t tx_buffer[6]; tx_buffer[0] = 0xAA; tx_buffer[1] = 0xAA; tx_buffer[2] = 0x01; // CMD_SWITCH_INPUT tx_buffer[3] = channel; // 目标通道号 tx_buffer[4] = tx_buffer[0] ^ tx_buffer[1] ^ tx_buffer[2] ^ tx_buffer[3]; tx_buffer[5] = 0x55; CC1101_Transmit(tx_buffer, 6); }这段代码的逻辑很直白：组帧、计算异或校验、通过CC1101发送。实际调试时有一个细节值得注意：CC1101发送模式切换需要一点时间，从IDLE状态切换到TX状态再发送，整个流程大约需要1毫秒。如果不做状态机管理，连续快速按键时可能会出现上次没发完下次就开始重发的情况。我的做法是用一个发送完成中断标志位，如果上一次发送还没完成，这次的按键事件就缓存到环形缓冲区里。
5.3 接收端固件逻辑
接收端的处理比发射端复杂一些，因为需要做帧同步、校验、解析和映射。核心逻辑如下：
void process_rx_frame(uint8_t *rx_buffer, uint8_t len) { if (len < 6) return; if (rx_buffer[0] != 0xAA || rx_buffer[1] != 0xAA) return; if (rx_buffer[5] != 0x55) return; uint8_t checksum = rx_buffer[0] ^ rx_buffer[1] ^ rx_buffer[2] ^ rx_buffer[3]; if (checksum != rx_buffer[4]) return; switch (rx_buffer[2]) { case 0x01: // 切换输入源 send_avmux_switch_command(rx_buffer[3]); break; case 0x02: // 查询状态 send_avmux_query_command(); break; } }收到一帧数据后，先做基础校验（帧头、帧尾），再做异或校验，全部通过后才执行命令。这个流程虽然简单，但能挡掉绝大部分空中误码。
5.4 状态回读与主动上报
光有下行控制还不够，我在接收端还加了状态回读功能。AVMux执行完切换指令后，会通过串口返回一条状态帧（例如A5 38 03 ... 7E，表示“当前输出为第3路”）。STM32收到这条回帧后，一方面通过UART回传给我的调试电脑，另一方面把状态缓存下来，如果遥控器端发来查询命令，就把缓存的当前状态切换为无线帧发回去。
实际使用中这个功能非常实用：桌面按键盒上有一个LED指示灯，当前通道为1到4时亮绿色，5到8时亮蓝色，查询状态后LED颜色能实时反映当前AVMux的实际工作状态。这解决了无线控制场景中“按下按键但不知道到底切没切过去”的焦虑感。
5.5 断线重连与超时保护机制
433MHz通信虽然稳定，但也不是100%可靠。电磁干扰、机柜门关闭造成的信号衰减，都可能让指令丢失。我在接收端加了一个超时保护机制：如果连续发送10次无线帧，AVMux都没有返回状态回帧，STM32就判定链路异常，不再继续重发，而是进入错误状态，等待下一帧有效指令。
这个机制的意义在于：在有电磁干扰的环境下，避免接收端陷入“不停重发指令”的循环。因为不停重发会让AVMux以为自己收到了多条指令，虽然执行结果相同，但可能导致继电器频繁切换，影响设备寿命。设置一个重发上限，让系统在异常时自动停止，是比无限重发更稳妥的做法。
6. 调试过程全记录：从能发能收到真正稳定，走了四个阶段
6.1 第一阶段的坑：能接收到数据，但全是乱码
第一次上电调试，我按下遥控器按键，接收端串口助手立即有输出，但内容是一堆乱码。我当时的第一反应是波特率配置不对，检查之后发现收发双方的波特率设置都是一致的，这就怪了。
用示波器看了一下CC1101模块输出的SPI时钟波形，发现问题出在STM32的SPI速率配置上。我把SPI的预分频设置得太高（达到了非常高的速率），CC1101模块跟不上这个速度，导致数据在SPI传输过程中发生了位错位。
解决办法很简单：把SPI时钟频率降到CC1101允许范围内。CC1101的数据手册建议SPI时钟不超过10MHz，而我的STM32跑在72MHz，SPI1的时钟源是PCLK2（72MHz），必须至少分频到8分频（9MHz）才能满足要求。改完这一行配置，乱码问题立刻消失。
这里分享一个经验：SPI外设通信遇到乱码，八成是速率不匹配或者时序极性配置不对。用示波器看信号是最直接的排查方法，不要盲目怀疑硬件连接。
6.2 第二阶段的坑：单次按键正常，连续快速按键却丢指令
乱码问题解决后，我做了连续按键压力测试：快速按下“1、2、3、4、1、2、3、4”，发现指令丢了两条，AVMux没有按预期切换。
排查过程是这样的：先在接收端加了一个调试计数器，统计UART发送成功次数。测试后发现，STM32确实收到了所有无线帧，但UART发送出去的数量少于接收到的。这就说明问题出在UART发送环节。
再仔细看代码，发现我在循环里直接用阻塞式UART发送，连续按键时每次发送的字节间隔约2毫秒，但AVMux的串口接收缓冲区有限，如果发送速度过快，AVMux来不及处理就会丢。
解决办法是在发射端做限速：每次按键发送前，加一个500ms的延时，确保相邻两次有效指令的发送间隔不小于500ms。这样虽然连续按键时最后一条命令会有少许延迟，但保证了每条命令都能被AVMux正确处理。对于会议室的切换控制场景，这个延迟完全可接受。
6.3 第三阶段的坑：机柜门一关，信号变得飘忽不定
前面的调试都在开放环境下进行，效果很好。但把AVMux装回机柜、关上机柜门后，出现了新的问题：信号时好时坏，有时候按遥控器没反应，过一会儿又能用了。
首先想到的是信号衰减。金属机柜对433MHz信号有屏蔽作用，所以我一开始考虑把天线放在机柜外面。在机柜后面板开了一个小孔，把接收模块的天线引出来。但效果不理想，信号时好时坏的问题依旧存在。
后来用频谱仪扫描了机柜内部环境，发现机柜里有一个开关电源，它在433MHz频段附近产生了一些谐波干扰。而我的接收模块工作频点刚好落在干扰最强的频点上，导致接收灵敏度下降。
解决办法是我前面提到过的：把CC1101的工作频点从默认的433.92MHz调整到了433.10MHz。改完之后，即使机柜门完全关闭，遥控距离和稳定性也没有明显下降。
这个案例说明：在工业现场调试无线设备，遇到信号不稳，第一时间不要只想着加放大器、换天线，先看看环境里有没有干扰源。频点偏移往往是最简单、最有效的解决方案。
6.4 第四阶段：边界测试与异常恢复
最后做的是一组边界测试：烈日下在会议室最远角落遥控（机柜在另一头），实测距离约60米，按键响应正常；把AVMux断电后再上电，遥控器能在一秒内重新建立连接；连续跑了一整天的自动切换压力测试，没有出现指令丢失和误触发。
还专门做了异常恢复测试：在切换过程中故意碰到AVMux的串口线，模拟接触不良，观察STM32是否会自动恢复。结果显示，只要串口线重新接好，下一次按键就能正常响应，没有卡死的状态。
7. 使用体验与注意事项：改造完成后的真实感受
7.1 几个使用中的加分设计
改造完成后，这套无线遥控系统已经稳定运行了三个月，没有出现需要重启的情况。几个设计细节在实际使用中被证明很有价值：
第一，遥控器上做了“当前状态查询”按钮。会议室管理员进场前按一下查询键，桌面按键盒上的LED灯就能显示当前输出通道，不用打开电脑看控制软件，省心很多。
第二，接收模块的串口输出并联了一个调试接口，出了一次切换逻辑异常，工程师不用拆机柜，直接接上这个调试接口就能看日志，排查效率提升明显。
这两个设计都不是原计划里的，是调试过程中被实际需求逼出来的。“能用”和“好用”之间的差距，往往就是这些细节。
7.2 容易被忽略的隐患：供电和地环路
接收端的STM32和CC1101模块，我从AVMux内部的12V电源取电，用一个7805稳压到5V，再用AMS1117-3.3稳压到3.3V。这个方案省去了额外插一个电源适配器的麻烦。
但这里有个风险：如果AVMux主机断电，接收模块也会断电，无线控制自然失效。在某些场景下这可能是问题，比如你希望AVMux断电时接收模块仍然工作，以便等待来电后自动恢复。如果真有这个需求，建议接收模块单独供电，不要从AVMux内部取电。
另外，独立供电时要注意地环路问题：如果接收模块的GND和AVMux的GND之间存在电势差，串口通信可能会受到干扰。稳妥做法是在串口线上串一个光耦隔离模块，把两边的地完全隔开。
7.3 给想复刻这个方案的人几个建议
如果你也想给家里的AVMux或者其他带串口的设备做无线遥控，我的建议是：
第一，先拿到设备的串口协议文档。没有协议文档，一切改造都无从谈起。实在没有文档，就用串口嗅探法自己抓，但一定要多抓几组数据再总结规律。
第二，无线模块的选型，优先考虑带屏蔽罩和经过认证的模块。我用的CC1101模块虽然便宜，但确有一些廉价模块的射频性能一致性不好，同一批货有的灵敏高有的灵敏低。预算允许的话，选择大厂模块能省去很多调试时间。
第三，协议转换板不建议直接买现成的单片机开发板裸奔，最好做一个最小系统板，把所有引脚都引出来，这样后续调试扩展才有余地。
第四，一定不要忘了共地。共地是通信稳定性的第一基础，不共地一切免谈。
7.4 把这个方案扩展到其他设备
这套“无线射频+STM32协议转换”的方案，天然具备可复用性。不同之处只在于协议转换层——不同设备的RS232指令格式不同，你只需要修改STM32固件里的映射函数，把遥控指令翻译成目标设备能听懂的指令即可。
我在做完AVMux后，又用同样思路改了一台音频处理器（可以通过串口调节音量、切换预设），以及一台投影机的RS232控制口（实现无线开关机和信号源切换）。因为协议转换层是独立封装的，改起来只需要换一套指令映射表，耗时不超过两小时。
所以说，这个项目的价值不只在“给AVMux加了个遥控器”，更在于它验证了一种低成本的设备智能化升级路径：旧设备不用换、网络不用改、电源不用动，只加一个小模块，就能让原本只能用手按的设备实现无线控制。
我个人在实际操作中的体会是：这类改造项目的难点从来不在硬件或者软件本身，而在于你对手里的设备理解得有多深。把AVMux的串口协议吃透，把433MHz的通信特性搞清楚，剩下的就是水到渠成的事情。如果后续你想在这个基础上加手机控制，只需要把433MHz的发射端换成带蓝牙或Wi-Fi的网关，协议转换层的代码几乎不用动，这又是一个新的可玩方向了。
