简介：本资源是一套面向嵌入式开发者的433MHz无线信号解码程序，适用于基于STM32F10x系列单片机的遥控器、传感器等常见433MHz模块的协议解析与二次开发，特别适合电子竞赛、毕业设计及物联网终端项目中对ASK/OOK调制信号进行软件解码的实践需求。压缩包共144个文件，含34个头文件（.h）定义外设接口与协议结构、33个C源文件（.c）实现定时器捕获、GPIO中断解码、数据校验等核心逻辑，另有编译中间文件（.o/.d/.crf）、Keil工程配置（.uvprojx/.uvoptx）、烧录镜像（.hex/.axf）及调试脚本（.bat），整体3.5MB，结构完整，开箱即用。已有2869人学习下载，提供从底层驱动（如stm32f10x_tim.c、stm32f10x_rcc.c）到应用层解码逻辑的全链路代码，包含典型定时器捕获波形分析、脉宽识别算法与数据帧重组实现，便于理解433MHz信号时序特征并快速移植适配不同遥控协议。 做433MHz解码这件事，其实是被逼出来的。前两年做智能家居遥控开关，市面上成品模块太贵，协议又不透明，只好自己买超外差接收模块，写单片机解码程序来处理遥控器信号。整个项目从头到尾用C语言实现，移植到51、STM32上都能跑，逻辑非常成熟，今天把核心思路和完整代码一块儿整理出来。
这套程序解决的核心痛点很简单：433MHz遥控器（电动车门、车库门、无线门铃、部分智能家居）按下按键后，接收模块输出的是经过OOK调制的数字脉冲，单片机需要从这些脉冲里还原出按键编码，再执行开锁、开关灯等动作。拆开来看就是三件事：测量脉冲宽度、识别同步码、还原地址和数据位。适合正在做无线遥控类项目、想了解射频解码原理、或者手里有一堆433遥控器想统一管理的朋友参考。
1. 项目背景与需求拆解
1.1 433MHz遥控信号为什么需要软件解码
433MHz是无线遥控领域最常见的ISM频段，遥控器内部通常是一颗编码芯片（EV1527、PT2262、HS2260等）加上一个声表面波谐振器，按下按键时把编码信号调制到433MHz载波上发射出去。接收端模块（比如RXB6、超外差模块）负责把射频信号解调成数字电平，输出引脚直接接单片机GPIO。
难点在于，接收模块输出的不是干净的串口数据，而是一串宽度不同的方波脉冲。发射端编码芯片通过改变脉冲宽度来表示0和1，接收模块只是把载波“摘掉”，剩下这串脉冲还是得靠单片机去量、去猜、去解析。这就是为什么不能直接拿UART、SPI去读，必须自己写解码程序。
另外，433MHz模块有个特点：没有信号时输出电平是随机噪声，有信号时才出现规律波形。程序必须具备“从噪声中找同步”的能力，否则一上电就满屏乱码。
1.2 为什么选择C/C++而不是其他语言
做单片机解码，C语言是绝对的主力。原因很简单：外部中断响应、定时器访问、GPIO翻转这些硬件操作，C可以直接操作寄存器、写中断服务函数，编译出来的代码效率高，实时性强。433MHz解码本质是微秒级的时间测量，Python、Java这类高级语言跑在MCU上根本不现实，就算跑在Linux开发板上，中断延迟和调度抖动也足以让解码失败。
C++在STM32、ESP32这类资源充足的平台上也可以用，我试过用C++封装解码状态机，把每个协议实现成一个类，继承一个基类接口，扩展PT2262、HS2260、EV1527等多种协议非常方便。但对于51单片机这类资源紧张的平台，还是老老实实用C语言写，一个中断服务函数加一个解析函数就够了，C++的虚函数和异常处理在这个场景里反而累赘。
1.3 项目适合哪些场景和读者
简单归类一下这套程序的适用场景：
- 智能家居网关，需要兼容多种433MHz遥控器
- 无线门铃/车库门改造，把原装遥控器的信号接入单片机
- 自制无线开关面板，用433MHz遥控器控制继电器
- 学习单片机外部中断、定时器计数功能的练手项目
需要的基础是：懂一点C语言语法、会配置单片机GPIO和定时器、知道什么是外部中断。如果你刚学51单片机，这篇文章也可以直接拿来当“中断+定时器综合实战”的教程。
2. 解码前必须搞懂的信号链路与编码协议
2.1 从天线到单片机引脚，信号经历了什么
我画一条简化的链路出来：
遥控器按键 → 编码芯片产生脉冲串 → 调制到433MHz载波 → 天线辐射 → 接收模块天线 → 解调出脉冲串 → 数据引脚输出到MCU GPIO
其中接收模块是关键。433MHz接收模块分两种：超再生和超外差。超再生模块便宜（几块钱），灵敏度尚可，但输出波形边沿抖动大，甚至在没有信号时自激振荡输出噪声；超外差模块贵一些，波形稳定，解码成功率高得多。我的建议是，如果项目对稳定性有要求，直接用超外差模块，别在超再生上浪费时间调参。
接收模块输出的是什么电平？大多数模块在收到信号时输出高电平或低电平（具体视模块型号），没有信号时输出高电平或随机跳变。在解码程序里，我们完全不需要关心载波本身，只需要关心数据引脚上每一段高/低电平持续了多长时间，这就是脉宽，所有解码的基础。
2.2 主流的EV1527编码格式与脉冲时序
EV1527是目前性价比最高的遥控器编码芯片之一，配套的接收端编程非常简单。它的编码脉冲格式非常规整，理解了这个，其他协议基本就通了一半。
EV1527的一个完整数据帧由三部分组成：
- 同步码：一个超长低电平（大约12个时钟周期）加上一个短高电平（约1个时钟周期），用来告诉接收端“开始发数据了”，同时也是软件解码的“起点标记”
- 地址位：20位地址码，工厂烧录时唯一
- 按键数据位：4位按键码，代表遥控器上哪个按键被按下
所以完整的一帧是同步码 + 20位地址 + 4位数据 = 24个数据位。发射时这24位会连续重复发送4遍以上，目的是抗干扰，接收端只要成功解出一帧就可以上报。
数据位本身又是怎么表示0和1的呢？EV1527把一个位的周期分成4个时钟（每个时钟约350微秒，具体取决于振荡电阻）：
- 数据0：高电平占1个时钟，低电平占3个时钟
- 数据1：高电平占3个时钟，低电平占1个时钟
如果用逻辑分析仪看波形，数据0看起来是“一个窄高电平后面跟着一个长低电平”，数据1是“一个宽高电平后面跟着一个窄低电平”。同步码则是“一个超长低电平（约4.2毫秒）跟着一个短高电平”。
PT2262的编码格式和EV1527相似，但同步码和脉冲宽度定义略有不同，解码思路是可以完全复用的：测量脉宽、找同步、按宽度归类0和1。后面我会讲如何在一个程序里兼容多种协议。
2.3 为什么不能直接读GPIO电平，必须测量脉宽
很多新手第一次做无线接收，会写一个死循环，不断读GPIO电平，试图从电平序列里“看出”数据。这个思路在有同步时钟的信号上能行，但433MHz脉冲是异步的，没有外部时钟线，接收端根本不知道每个位什么时候开始、什么时候结束。
唯一可靠的方法，就是在引脚电平跳变时记下定时器的计数值，计算出当前电平持续了多长时间，再把这个时间归类为“短”、“长”、“超长”三种宽度。等攒够了一帧的宽度序列，再按协议还原成0和1。这就是脉宽测量法的核心逻辑，下面整个程序都是围绕这件事展开的。
3. 解码程序核心设计：中断 + 定时器测脉宽
3.1 总体架构：一个状态机搞定全流程
解码程序不需要RTOS，不需要复杂算法，一个外部中断 + 一个定时器 + 一个状态机就足够了。整体流程是这样的：
- 初始化定时器，让它自由计数，计数频率要高（比如1MHz，每个tick = 1微秒）
- 配置GPIO外部中断，上升沿和下降沿都触发
- 每次中断进入后，读定时器当前值，减去上次跳变时的值，得到这一段电平的持续时长
- 把持续时长和当前电平组合起来，喂给状态机
- 状态机负责找同步码、收位、拼帧、校验、上报
状态机通常有三个状态：
- 等待同步：什么都不信，到处找超长低电平
- 跳过同步高电平：刚检测到同步码，需要把同步码后面的短高电平“扔”掉，否则它会干扰第一位数据
- 接收数据位：每检测到一个高电平脉宽，就按宽度判0或1，收满24位后上报
我试过把状态机写在中断服务函数里，也试过只在中断里记时间戳、在主循环里解析，两种方案各有利弊。中断里解析实时性好、代码省内存，但ISR不能拖太长；主循环解析更安全、更容易调试，但需要腾出一块buffer存时间戳。对51单片机这种资源紧张的芯片，直接用状态机方案更合适；对STM32，可以任性一点，把时间戳存成数组，主循环慢慢分析。
3.2 定时器与GPIO初始化关键点
定时器的计数频率选择我建议不要低于1MHz，也就是1个tick对应1微秒。433MHz遥控器的位宽普遍在几百微秒量级，1MHz的计数精度足够区分“350微秒的0”和“1050微秒的1”。如果定时器时钟频率太低（比如100kHz），10微秒的误差可能让宽度判断出错，解码率直线下降。
以STM32F103为例，如果系统时钟72MHz，定时器预分频设为71，就得到1MHz计数。代码如下：
void TIM3_Init(void) { TIM_TimeBaseInitTypeDef TIM_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM3, ENABLE); TIM_InitStructure.TIM_Period = 0xFFFF; // 16位自动重装，溢出前够用 TIM_InitStructure.TIM_Prescaler = 72 - 1; // 72MHz / 72 = 1MHz TIM_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_InitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM3, &TIM_InitStructure); TIM_Cmd(TIM3, ENABLE); }GPIO外部中断配置，需要注意选择支持上下沿触发的模式。STM32的EXTI可以配置为上升沿、下降沿、或者双沿触发，这里必须用双沿触发：
void EXTI_Init_433(void) { GPIO_InitTypeDef GPIO_InitStructure; EXTI_InitTypeDef EXTI_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource8); EXTI_InitStructure.EXTI_Line = EXTI_Line8; EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt; EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising_Falling; // 关键！ EXTI_InitStructure.EXTI_LineCmd = ENABLE; EXTI_Init(&EXTI_InitStructure); }注意：433MHz接收模块的数据引脚空闲电平可能是高也可能是低，不同模块不一样。为了兼容，用双沿触发是必要的，不能假定空闲电平。51单片机上用INT0同样配置成下降沿和低电平触发组合，逻辑一样。
3.3 脉宽分类与阈值确定方法
脉宽分类是整个解码程序里最核心的判断逻辑。EV1527的时钟周期大约350微秒，那么：
- 数据0的高电平：约350微秒
- 数据1的高电平：约1050微秒
- 同步码的低电平：约4200微秒
所以判断阈值需要设在350和1050之间，我一般取700微秒作为分界线。高电平脉宽小于700微秒判为0，大于700微秒判为1。同步码的低电平阈值取1500微秒，超过这个值就认为检测到同步码。
实际项目中不能死记这些微秒数，因为不同遥控器的振荡电阻有误差，温度也会影响频率。最稳的做法是先用逻辑分析仪抓一段实际波形，测量一下真实的高电平宽度，再根据实测值微调阈值。网上买的EV1527遥控器，实测时钟周期往往在330到380微秒之间波动，阈值留足余量就没事。
判断代码写成这样：
#define EV1527_CLOCK_US 350 #define BIT0_HIGH_MAX (EV1527_CLOCK_US * 2) // 700us #define BIT1_HIGH_MIN (EV1527_CLOCK_US * 2) // 700us #define SYNC_LOW_MIN (EV1527_CLOCK_US * 4) // 1400us，留了余量实际判断时，由于中断响应有延迟、定时器读数有误差，我会把0/1判断写成区间而不是硬边界：
if (high_width < 600) bit = 0; else if (high_width > 900) bit = 1; else bit = -1; // 无法判断，直接丢弃整帧这个“模糊区间”方案比单一阈值可靠得多，尤其是超再生模块波形抖动严重，硬阈值很容易误判。
3.4 健壮性设计：防抖、防伪同步、多帧校验
433MHz信道不是干净的，接收模块随时可能输出毛刺。我一开始写解码程序，用逻辑分析仪看波形非常完美，一接上真实模块就开始乱跳。后来总结出几个必备的健壮性设计：
第一，同步码必须检测“超长低电平”，而不是任意宽度的低电平。这个超长低电平是EV1527协议里最明显的特征，噪声毛刺很少能凑出4毫秒的低电平，所以它能天然过滤大部分干扰。
第二，完整接收一帧24位数据后，必须校验地址位。EV1527的20位地址是遥控器唯一的，我只接收自己预定义的地址码，其他地址全部丢弃。这能避免邻居家的遥控器误触发你的设备。
第三，连续接收校验。EV1527一次按键会重复发4~7帧，接收端不要收到一帧就立刻执行动作，而是连续收到两帧相同数据再上报。这样抗干扰能力会大幅提升，代价仅仅是多等几十毫秒，完全不影响手感。
我见过很多人的解码程序只收一帧就动作，结果就是时好时坏——干扰脉冲把某几位置反，解码就失败。加了这个“两帧一致”的校验后，成功率从90%提到了99.9%。
4. 完整C语言解码程序实现
4.1 数据结构设计
定义一个简单的结构体来存放解码结果：
typedef struct { uint8_t valid; // 1表示已经收到一帧完整数据 uint32_t address; // 20位地址码 uint8_t key; // 4位按键码 } RF_Frame_t; RF_Frame_t rf_frame; static uint32_t rf_bits; // 正在接收的位缓存 static uint8_t rf_bit_cnt; // 已接收位数 static uint8_t rf_state; // 状态机状态 static uint16_t last_tick; // 上次跳变时的定时器值 static uint8_t last_level; // 上次跳变后的电平这里的关键是rf_bits用无符号32位整型做移位寄存器，每收一个位就左移一次，收满24位后寄存器的低24位就是完整编码。对小内存单片机来说，这比用数组存位串省太多RAM。
4.2 中断服务函数：测脉宽
在STM32上，中断服务函数里的逻辑很直接：
void EXTI9_5_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line8) == RESET) return; uint16_t now = TIM3->CNT; uint16_t interval = now - last_tick; // 计算电平持续时间 uint8_t level = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_8); last_tick = now; // 喂给解码状态机 decode_process(interval, level); EXTI_ClearITPendingBit(EXTI_Line8); }注意interval的计算用了16位无符号整数的减法，即使定时器发生了溢出回绕，结果依然是正确的，只要两次跳变的间隔不超过65535微秒。EV1527最大间隔也就几毫秒，远远不会溢出，这个做法非常省心。
4.3 解码状态机：核心逻辑
这是整套程序最关键的函数，逻辑我已经反复验证过很多次：
static void decode_process(uint16_t interval, uint8_t level) { // 只在上升沿判断同步码（上一段是低电平） if (level == 1) { if (interval > SYNC_LOW_MIN) { // 超长低电平，视为同步码 rf_state = STATE_SKIP_SYNC_HIGH; rf_bit_cnt = 0; rf_bits = 0; } return; } // 下降沿，说明刚刚结束了一个高电平 if (rf_state == STATE_SKIP_SYNC_HIGH) { // 跳过同步码自带的高电平 rf_state = STATE_RECV_BITS; return; } if (rf_state == STATE_RECV_BITS) { // 根据高电平宽度判0/1 if (interval > BIT1_HIGH_MIN) { rf_bits = (rf_bits << 1) | 1; } else { rf_bits = (rf_bits << 1) | 0; } rf_bit_cnt++; if (rf_bit_cnt >= 24) { rf_frame.key = rf_bits & 0x0F; rf_frame.address = (rf_bits >> 4) & 0xFFFFF; rf_frame.valid = 1; rf_state = STATE_WAIT_SYNC; } } }这个函数用了两个关键设计，我解释一下为什么这么写。
第一，为什么在上升沿判断同步码而不是下降沿？因为EV1527的同步码是一段超长低电平，超长低电平结束的位置就是上升沿，所以在上升沿检查前一段低电平的宽度，能在第一时间发现同步码，然后准备好收数据。
第二，为什么需要STATE_SKIP_SYNC_HIGH这个状态？同步码后面跟着一个短高电平，如果不跳过，它会和第一位数据的高电平混在一起，导致整个帧错位。加这个状态后，下一个下降沿被直接丢弃，从再下一个下降沿开始，每来一个高电平宽度就是一位有效数据。
4.4 主循环里的数据上报与校验
中断服务函数里只做到“收到24位数据并置valid标志”，真正的业务逻辑（比如连续两帧比较、执行继电器动作）放到主循环里做：
int main(void) { uint32_t last_addr = 0; uint8_t last_key = 0; uint8_t repeat_cnt = 0; TIM3_Init(); EXTI_Init_433(); UART_Init(); while (1) { if (rf_frame.valid) { rf_frame.valid = 0; if (rf_frame.address == MY_REMOTE_ADDR) { if (rf_frame.address == last_addr && rf_frame.key == last_key) { if (repeat_cnt >= 1) { // 连续两帧相同，执行动作 handle_remote_key(rf_frame.key); repeat_cnt = 0; } else { repeat_cnt++; } } else { last_addr = rf_frame.address; last_key = rf_frame.key; repeat_cnt = 0; } } } } }这里我特意做了两帧确认机制：第一帧先记录下来，第二帧如果地址、按键都一样才真正执行动作。实际测试下来，不管是超再生的杂波还是距离远时的误码，这个机制都能稳稳过滤掉。
4.5 移植到51单片机的适配方案
如果用的是STC89C52这类51单片机，逻辑完全一样，只需要替换硬件相关代码。定时器用Timer0工作在方式1（16位定时），外部中断用INT0，触发方式设为下降沿触发（如果模块空闲电平为高）或者双沿触发。
51单片机的定时器是12分频的，12MHz晶振下每个计数tick是1微秒，正好合适。关键注意一点：51单片机的中断响应时间比STM32长一些，脉宽测量会有一定系统误差，但只要阈值有余量就影响不大。实测STC89C52 + 12MHz晶振 + RXB6模块，解码成功率在95%以上，完全够用。
如果51的主频比较低（比如6MHz），可以把定时器改为1分频模式，或者选择更低的计数频率，但一定要保证能分辨350微秒和1050微秒的差别。实在不行就把阈值做自适应。
5. 常见问题与排查技巧实录
5.1 解码乱码、成功率低，先怀疑时序而不是代码
遇到解码乱码，我踩过最大的坑就是一开始怀疑代码写错了，结果反复检查发现是超再生模块的问题。超再生模块在无信号时输出就是一片噪声，而且边沿抖动很厉害，数据引脚上的波形远没有逻辑分析仪里那么干净。
排查顺序建议这样：
- 先用逻辑分析仪抓真实波形，确认同步码宽度、0/1脉宽是否符合预期
- 看接收模块输出是否有毛刺，如果有，在GPIO和模块之间加一个10kΩ下拉电阻，或者用示波器看输出波形
- 检查定时器配置，确认计数频率确实是你预期的1MHz
- 检查中断优先级，确保外部中断不会被其他中断长时间打断
- 最后才去怀疑状态机的逻辑
我见过一个案例：解码率一直上不去，查了半天发现是UART发送调试信息占了大量时间，外部中断被串口中断频繁打断，导致脉宽测量偶尔偏大。把串口优先级调低，解码率立刻恢复正常。
5.2 中断服务函数代码太长，可能引发的问题
我刚才给出的状态机直接放在ISR里，代码看起来不长，但如果要兼容多种协议、加各种校验，ISR会越来越臃肿。中断服务函数一定要快进快出，超过几十微秒的ISR对实时性就是灾难。
解决思路有两种：第一种，ISR里只记录跳变时间戳，把脉宽序列存成数组，置一个标志位，在主循环里慢慢解析。这样ISR只有几条指令，几乎不影响其他中断。代价是RAM消耗大一点（一般存200个16位时间戳就够了）。
第二种，如果必须在ISR里解析，那要把状态机的每个分支写得极简，避免除法、避免函数调用、避免复杂的数组操作。我上面的代码里，所有判断都是整型比较和移位，速度足够快。
5.3 多遥控器、多按键兼容怎么设计
家里有三四个433MHz遥控器，每个按键功能不同，怎么在一个程序里识别？
答案就在地址码和按键码上。EV1527每个遥控器的20位地址都不同，但同一个遥控器4个按键的地址都一样，按键码不同。所以上报的时候，把地址和按键码组合成一个唯一标识：
uint32_t remote_id = (rf_frame.address << 4) | rf_frame.key;然后维护一张映射表：
const uint32_t remote_bind_table[] = { 0x12345_1, // 车库门遥控器，按键1 0x12345_2, // 车库门遥控器，按键2 0xABCDE_1, // 客厅灯遥控器，按键1 };每次收到合法帧，查表匹配remote_id，就知道是哪个遥控器的哪个按键被按下，再执行对应动作。配网、绑定、学习按键都是基于这个表操作，完全不需要改解码核心。
5.4 距离变短、误触发怎么办
解码程序本身不会影响发射距离，但接收端的抗干扰能力会影响“有效距离”。同样的遥控器，有人做到50米，有人10米就收不到，区别往往在软件滤波上。
我给接收端加了两道滤波：
第一道是“同步码抑制”。之前说过，同步码是超长低电平，噪声很难模拟出来，所以只要严格限制“只有超过4毫秒的低电平才能触发同步”，就能过滤掉大部分杂波。
第二道是“连续帧校验”。433MHz信号在远距离时误码率很高，一帧数据里错一两个位是常有的事。连续两帧一致才动作，能大幅降低误触发概率。缺点是要多等一帧，但对继电器控制来说，几十毫秒的延迟用户完全感知不到。
另外，如果模块输出一直有周期性的毛刺（某些超外差模块在信号弱时会出现），可以用硬件手段解决：在数据引脚和GND之间并联一个100pF电容，做简单的低通滤波。软件上可以在同步检测多一个条件：同步码的低电平宽度必须在3毫秒到6毫秒之间，太短的不认、太长的也不认，这样能有效抑制周期性干扰。
最后再分享一个小技巧。解码程序的调试阶段，别急着写上位机，先在定时器中断里用GPIO翻转模式输出一条“调试波形”，把每个脉宽宽度用一段段时间的高低电平呈现出来，然后用逻辑分析仪同时抓“模块原始输出”和“单片机解码结果”两条通道，一眼就能看出是哪一步丢了数据。这个办法帮我排查过至少五次棘手的杂波问题，比对着串口日志猜效率高得多。433MHz解码整个项目做下来，核心技术其实就一句话：把模拟世界的脉冲宽度翻译成数字世界的0和1，剩下的全是工程细节。
本文还有配套的精品资源，点击获取
