简介史上最全的红外遥控器编码协议是一份专业红外遥控编码技术参考文档面向嵌入式开发、家电维修、万能遥控器码库分析等相关人员。文档系统梳理并对比了数十种常见红外遥控编码格式例如MIT-C8D8、SC50560、M50462、RECS80、NEC、Philips RC-5/RC-6等逐一说明地址码与数据码结构、脉宽调制方式、载波频率33K/38K/40K等、逻辑位时间长度及连续按键重复周期部分协议还标注了典型遥控器型号与码组便于实际解码和码库调试时快速查对。资源共1个PDF文件压缩包约4.96MB目录清晰按协议索引排列。目前已有345人学习适合需要系统梳理红外协议之间差异、进行万能遥控器码值分析或嵌入式红外解码开发的读者。 红外遥控器这个东西看起来就是按一下按键、灯亮灯灭似乎没什么技术含量。可真要自己动手做一个基于STM32的智能家居网关、学习型遥控器或者单纯想把家里乱七八糟的遥控器合并成一个你会发现水远比想象中深——不同的品牌、不同的协议、不同的时序参数光是把它们理清楚就够喝一壶的。所以当看到“史上最全的红外遥控器编码协议.pdf”这个标题时我第一反应是如果能把这套协议体系和STM32 解码实战放在一起讲清楚那才是真的省事。这篇文章我打算从一个嵌入式开发者的实操视角把红外遥控器编码协议家族梳理一遍然后重点拆解最主流的NEC协议再给出基于STM32的硬解码状态机实现思路最后聊一聊实测调试中的那些坑。无论你是刚接触红外的学生还是在做智能家居产品选型的工程师这篇文章应该都能给你一些可以直接抄作业的东西。1. 红外遥控器编码协议全景从NEC到RC61.1 为什么遥控器需要一套“自己的摩斯密码”红外遥控的本质是发射红外光脉冲接收端通过检测光的变化来还原信息。问题在于红外光是很容易受干扰的家里有阳光、白炽灯、节能灯它们的红外分量都不小。如果只是简单地把按键信号发出去可能误触发如果相同频率的遥控器之间还能互相干扰。所以大家给红外遥控增加了一层“编码”——用高低电平的宽度变化表示0和1再套上地址码表示设备身份再用命令码表示按键。这就像摩斯密码先约定一个字母用怎样的点划组合两端才能配合默契。这些规则就是编码协议。协议定义了载波频率、帧格式、电平时序、校验方式甚至重复发送策略。市面上常见的有NEC、RC5、RC6、索尼SIRC、夏普、三星、飞利浦RC-MM等。把协议吃透你不仅能用现成库解遥控器还能自己写发射编码这才是学习型遥控器的底层能力。1.2 主流协议族横向对比这里我把最常见的协议放在一个表里方便大家对照协议载波频率帧结构要点典型应用NEC38kHz9ms引导码 32bit数据 停止位110ms周期国产电视、机顶盒、学习型遥控器Sony SIRC40kHz12bit/15bit/20bit无引导码靠短脉冲宽间隔索尼电视、功放Philips RC536kHz14bit含2个起始位1个翻转位5位地址6位命令飞利浦设备、部分老电视Philips RC636kHz4个起始位1个翻转位8位地址8位命令扩展位飞利浦高端设备三星38kHz4.5ms引导码32bit数据与NEC接近但时序不同三星电视这只是个简化表实际厂商还会做各种定制。我的经验是做兼容方案时优先看“引导码时间宽度”和“数据位是脉冲宽度调制还是相位调制”这两点基本就能把协议归类剩下的再去查具体手册。1.3 为什么NEC占了大半江山NEC协议之所以能成为“事实标准”主要有几个原因第一它结构简单一个帧总共就几十毫秒解码逻辑用一颗8位单片机就能跑第二它带地址码和反码天然支持设备区分和校验第三早期电视、DVD、机顶盒大量采用后来的国产方案继续沿用。直到现在你在某宝买“万能遥控器”或“学习型遥控器”绝大多数默认兼容的就是NEC。还有一个原因很多人忽略NEC的重复码设计特别好处理。按住按键不放时发送一次数据帧后按110ms周期重复发送9ms2.25ms560us的重复码而不是完整数据帧。接收端只要识别重复码就知道按键还在按住状态不用重复解析地址和数据省掉了不少逻辑。2. NEC协议深度拆解每一位都有讲究2.1 NEC一帧到底怎么排布NEC的一帧是先是9ms高电平的引导脉冲随后是4.5ms低电平的空闲接着是32位数据。这32位数据排布是8位地址码、8位地址反码、8位命令码、8位命令反码。注意NEC发射时是LSB优先即先发一个字节的最低位最后发最高位。看到反码别觉得浪费它的作用就是校验。比如地址字段是0x00反码就是0xFF。接收方把地址和反码相加如果等于0xFF就认为这帧数据大概率没被破坏。类似的命令码和命令反码也做同样校验。我见过有些初学者直接把32位读进来发现“地址怎么是个反的”“命令怎么变成取反了”其实就是没做反码处理。这里补充一个容易踩的坑NEC标准是LSB优先但很多国产协议虽然抄NEC的时序却把字节按MSB优先发送。所以你在做兼容时代码里最好把字节级位序做成可配置不要写死在解析函数里。2.2 逻辑“0”和逻辑“1”是时间差NEC协议里每个数据bit由一段载波脉冲加一段空闲组成。载波脉冲固定是560us区别在空闲宽度逻辑“1”的空闲是1690us有些资料写成1.69ms逻辑“0”的空闲是560us。相当于0.56ms脉冲0.56ms空00.56ms脉冲1.69ms空1。你可能觉得这不就是脉冲宽度调制吗对但要注意一点载波脉冲本身是38kHz方波不是单纯高电平。接收头比如VS1838B会把38kHz载波解调输出端变成TTL电平的高/低这时你看到的才是0.56ms高、0.56ms低的脉冲。所以很多人第一步就搞错了直接把接收头的输出信号当成原始信号其实那是经过解调后的信号。解调后的信号里每个数据bit其实有两个边沿一次上升沿、一次下降沿。状态机最稳妥的做法是记录两个边沿的间隔而不是只记录某一段高电平时间。我在做解码时习惯把相邻边沿间隔存成一个环形数组再统一分析这样既能判断引导码也能识别bit还能发现异常间隔。2.3 载波调制与38kHz怎么算发射端核心任务是产生38kHz载波并把它和编码脉冲“与”在一起。简单理解就是把编码信号的每个高电平时间段内塞满38kHz的方波编码信号是低电平时红外LED熄灭。这样接收头才能稳定解调。在STM32上用定时器输出PWM非常方便。以主频72MHz为例要产生38kHz PWM分频系数PSC取1即2分频得到36MHz计数时钟重载值ARR取947实际频率约 72MHz / (2*948) ≈ 37.97kHz已经很接近了。占空比一般取1/3左右也就是在高电平区间只点亮1/3的时间这样可以用更大峰值电流驱动LED又不至于过热。驱动电路上通常用NPN三极管或MOS管把MCU的IO信号放大串一个10~30欧的限流电阻红外LED的IF一般要有50~100mA级别才能保证5米以上距离。2.4 别被NEC变种坑了市面上号称NEC的遥控器实际至少有三类变种第一类是载波频率不同常见36kHz、38kHz、40kHz第二类是引导码宽度不同比如有的用4.5ms引导码、有的没有引导码直接发数据第三类是长度不同有些厂商在32位数据后面扩展了额外的功能数据或按键码实际帧长超过32位。我的排查建议是拿到一个陌生遥控器先用逻辑分析仪抓接收头输出波形测量引导码高电平宽度、第一个数据位周期、总帧时间。如果引导码在9ms附近bit周期在1.12ms逻辑0和2.25ms逻辑1附近基本就是NEC家族具体是哪种变种再按实测波形调整参数。千万不要直接套死某个库很多现成开源库默认只支持标准NEC遇到变种就解不出来。3. STM32解码实战从硬件到状态机3.1 硬件连接与器件选择解码端最常用的一体化红外接收头是VS1838B、HS0038B它们内置光敏二极管和放大电路直接把红外信号转成TTL电平输出脚通常接一个10k上拉电阻到3.3V或5V。供电电压要看清有些型号是5V有些是3.3V接错虽然不一定烧但解调阈值会变化导致接收距离变短。STM32的GPIO配置成上拉输入同时开启外部中断。我习惯用PA0因为很多开发板把PA0引出来了还支持EXTI0。代码里给引脚配上双边沿中断因为我们需要记录上升沿和下降沿的时间差单独下降沿的话后面还得额外处理高电平持续时间。如果想省CPU可以使用定时器输入捕获通道比如TIM2_CH1把接收头输出直接接到对应引脚。输入捕获可以自动记录电平跳变时的CNT值配合DMA批量搬运解一个完整的NEC帧CPU占用极低。缺点是需要查定时器的通道映射调试略麻烦。3.2 计时方式选择外部中断还是输入捕获很多人第一次学NEC解码都是用外部中断每次电平变化进中断然后读一个us定时器的值把两次中断的差值存下来。好处是思路直白代码好写坏处是中断频繁一个NEC帧有几十个边沿如果其间还要跑OLED刷新、按键扫描容易产生时间误差。输入捕获则完全由硬件处理边沿到来时硬件锁存CNT值不会占用CPU只要定时器不溢出就行。假设定时器时钟为1MHz那么CNT每1us加1一个9ms引导码对应CNT差值为9000左右。这里有一个要注意的点定时器计数器是16位1MHz时钟下65535us之后会溢出。NEC帧虽然是110ms周期但单个事件引导码高电平也就9ms一般不会超16位范围安全起见可以在溢出中断里把记录补全或者把定时器预分频调到2us一个计数单位。3.3 解码状态机与核心代码我习惯把中断里只负责记录时间差解析放到主循环或一个独立的解析函数里。伪代码如下void EXTI0_IRQHandler(void) { static uint32_t lastTick 0; uint32_t nowTick timer_get_us(); uint32_t delta nowTick - lastTick; lastTick nowTick; ring_buf_push(delta); // 保存相邻两次边沿间隔 EXTI-PR | EXTI_PR_PR0; // 清除中断标志 }int nec_decode(ring_buf_t *buf, nec_frame_t *frame) { // 1. 找引导码约9000us高 4500us低 // 2. 处理重复码9000us 2250us // 3. 连续解析32个bit每个bit由0.56ms高0.56/1.69ms低组成 // 4. 地址、地址反码、命令、命令反码并校验 }状态机的关键就是“找引导码”。正常流程是IDLE状态等待下降沿记录高电平时间约为9ms后进入等待4.5ms低电平接着进入数据位采集。如果中途超时或时间差不符合预期立即回到IDLE避免把噪声当数据。数据位采集部分每来一个下降沿就读一次当前时间计算上一次下降沿到这一次下降沿的间隔也就是一个bit的完整周期。如果间隔约1.12ms判为0间隔约2.25ms判为1。这个判断建议给上下限容忍范围比如±30%毕竟红外接收头输出有上升下降时间、时钟也有误差但不能太宽否则会把干扰当成数据。3.4 反码校验与超时处理拿到32位原始数据后先检查地址与地址反码的和是否为0xFF再检查命令与命令反码的和是否为0xFF。如果都通过说明这一帧大概率是有效NEC数据。这里要注意有的遥控器地址码本身就用反码所以很多库里你会看到两组地址输出调试时先打印原始值不要急着取反。超时处理也要重视。如果按下按键后来了一帧之后又被遮挡接收头长时间没有跳变主循环里要设置一个超时标记比如500ms内没有完整的帧就认为此次接收结束。否则很容易出现“上一次的半截数据被下一次按键续上”的诡异现象。我在实际项目中试过只靠外部中断不加超时结果每次开机第一次按遥控器都会触发一个错误帧。4. 实测调试与常见坑4.1 用逻辑分析仪验证波形我强烈建议每个做红外的人都买一个逻辑分析仪几十块钱的24MHz采样率就够了。把接收头的OUT引脚接到逻辑分析仪按键一次就能看到完整波形先是约9ms高电平引导码然后是一串400多us到2ms不等的脉冲。用软件的量尺功能量一下第一个高电平宽度是不是9ms量级再看两个高电平之间的低电平间隔0.56ms左右是01.69ms左右是1和自己代码里的判断阈值对照一下。有个小技巧先把遥控器正对接收头发一个键逻辑分析仪采完后直接导出CSV用Python脚本统计每个间隔的直方图能一眼看出哪些是0、哪些是1比人眼数60多个边沿靠谱得多。我处理陌生遥控器时都是先用这个流程把协议参数量出来再写进STM32的配置表里。4.2 常见问题排查表现象可能原因排查方法完全收不到信号载波频率不匹配或接收头供电/方向错误示波器测接收头OUT是否有低电平脉冲测量遥控器载波频率收到的数据总是少几位引导码判断阈值太严或数据超时提前放宽引导码窗口检查状态机是否提前退出命令对但地址不对位序LSB/MSB混乱或地址反码未处理打印原始32位数据对照反码关系检查位序按住按键连续触发多次未区分数据帧和重复码手动识别9ms2.25ms重复码按键连发只上报一次偶尔一帧错误环境光干扰、供电纹波、中断被打断接收头加遮光罩MCU供电加100nF电容延时测试4.3 几个影响稳定性的细节第一接收头旁边不要放高频开关电源或者至少要保持3cm以上距离。很多同学用调试器供电时一切正常换成充电器插着就乱码多半是电源纹波干扰了接收头内部的自动增益控制电路。第二发射管和接收头之间的“正对”角度影响很大。一体化接收头通常有一个±45度左右的视场角超出之后信号强度骤降。所以做红外转发器时最好把接收头装在设备面板上而不是藏在金属外壳内。第三代码里做阈值判断时不要写死精确到微秒的值。因为环境温度、器件批次会导致时序漂移比如引导码实际测出来可能是8.6ms或者9.4ms。写一个范围判断比如delta 8000 delta 10000比写delta 9000可靠得多。我在整理红外遥控编码资料的过程中最大的体会就是“协议文档再多不如一把逻辑分析仪”。网上能找到很多现成的解码库但它们往往只适配一种协议版本遇到变种就抓瞎。我的建议是拿到协议资料后先不要急着抄代码先按第2节的思路把协议族和时序参数过一遍再用手上的遥控器实测几个波形最后再落到STM32代码上。这样踩坑最少出来的代码也更稳定。后续如果你想做学习型遥控器还可以把每种协议的参数表做成配置文件升级MCU固件时不用改代码逻辑只改配置就能兼容新遥控器扩展起来非常省事。本文还有配套的精品资源点击获取