简介红外遥控码库是一份面向电子爱好者、硬件开发者及智能家居集成商的技术资源用于通过编程方式控制电视、空调、投影仪等常见家电其工作原理基于红外通信由发射端将指令编码为光信号接收端解码后执行相应操作。压缩包体积仅27KB内部按设备类别存放遥控码数据覆盖相机、空调、网络电视等多种类型方便按需选用目前已吸引3353人学习/下载同时资源附带了可访问约30000种设备码的开源码库网址能显著拓展设备兼容范围。开发者可根据具体设备型号挑选匹配的码库文件并通过Python、C等语言自行实现编码与解码功能从而构建个性化智能遥控器或融入自动化场景它既是入门学习红外遥控开发的实用素材也是开源社区共享创新的重要补充能帮助硬件爱好者加速完成从原型验证到实际部署的全流程。1. 红外遥控码库万能遥控器的“记忆体”到底是什么做智能家居、DIY红外转发器或者干脆想手搓一个万能遥控器的人大概率会卡在同一个问题上单片机、发射管、电路图都齐了代码也能编译通过可按下按键对面那台空调、电视、风扇就是纹丝不动。折腾半天问题往往不在硬件而在“码”——你的设备不认识你发的这串红外信号。红外遥控码库说白了就是把市面上主流家电品牌的遥控编码按照统一格式采集、整理、存储下来的数据集。这份资源解决的不是“怎么搭电路”而是“发射什么数据才能让设备听话”。适合正在做红外学习模块、万能遥控器、智能音箱红外网关的开发者也适合想搞明白自家遥控器编码规律然后做二次开发的嵌入式爱好者。码库的格式和结构决定了你能不能用、好用不好用下面从一个拆过不少码库的工程师视角把这套东西掰开讲清楚。2. 红外码的两种存在形式原始时序与协议解码码库里存的到底是哪一种打开任意一份红外码库你通常会看到两种截然不同的数据形态一种是裸露的高低电平时间序列单位是微秒长这样9000, 4500, 560, 560...另一种是十六进制协议数据比如 NEC 协议里的0x00FF00FF。这两种形态对应的是红外遥控信号从物理层到逻辑层的两个阶段理解它们才能搞明白码库内部那些文件为什么这么设计。2.1 NEC协议帧格式从引导码到停止位的33.9ms先说说最常见的基础协议 NEC。几乎所有学习型遥控器的码库里NEC 码都占了半壁江山。NEC 协议的一帧完整信号大概长 108ms分为引导码、地址码、地址反码、命令码和命令反码五个部分。引导码由一个 9ms 的高电平载波发射和一个 4.5ms 的低电平停顿构成作用是告诉接收端“准备开始接收”。接下来是 4 个字节的数据段地址码 8bit、地址反码 8bit、命令码 8bit、命令反码 8bit。每个 bit 的表示方式很有意思逻辑“1”是 560us 高电平加 1680us 低电平逻辑“0”是 560us 高电平加 560us 低电平这就是所谓的脉冲距离编码。所以如果你手里拿到一份0x00FF00FF对应到物理层它意味着地址码0x00、地址反码0xFF、命令码0x00、命令反码0xFF。接收端解码时先检查引导码再检查地址反码和命令反码是否与地址码、命令码按位取反一致四段对应上了才认为这是一帧合法数据。这也是码库能校验数据是否损坏的基础逻辑。提示NEC 协议还有重复码。按键按住不放时引导码后会跟一个 9ms 高电平 2.25ms 低电平的短引导再加一个命令码而不是完整重发整帧。做长按连续调节音量、温度的场景重复码的处理直接影响用户体验后面避坑章节会专门展开。2.2 原始时序码的表示数组、微秒与高低电平协议解码码适合给人阅读和协议分析但真正发射给红外管的时候MCU 需要一个一个电平去控制 IO 翻转。原始时序码就是把一帧信号里的每个高低电平持续时间按顺序排成的数组常见格式有两种一种是“脉冲-间隔”交替数组即 [高电平脉宽, 低电平间隔, 高电平脉宽, 低电平间隔…]另一种是带前缀标记的结构体数组。举个例子某个空调品牌的开机码用 NEC 协议解码后是0x04 0xFB 0x22 0xDD但原始时序码可能是这样uint16_t ir_raw[] { 9000, 4500, // 引导码 560, 1680, // bit 1 560, 560, // bit 0 560, 560, // bit 0 560, 1680 // bit 1 // ... 后续数据位 };这份码库里数据位对应的每个 560us、1680us 时间片就是物理层的时间量化结果。关键点在于接收端解码时允许一定的时间容差比如 NEC 标准 560us 的脉冲实际收到 500us 到 650us 都会被识为同一逻辑位原始时序码则把这个容差也固化进了数据里所以不同码库对同一台设备的同一按键采集出来的时间数组往往不完全一致但都能触发设备。2.3 为什么码库必须同时保留两套数据做个红外转发器的时候最理想的方案是存协议解码码体积小NEC 一个键只要 4 字节发射时现场编码成时序脉冲。但问题来了世界上的红外协议不止 NEC 一种Sony 的 SIRC、飞利浦的 RC5/RC6、三星、东芝、还有各种空调用的超长帧协议规则差异极大。SIRC 有 12bit、15bit、20bit 三种长度RC5 用曼彻斯特编码空调码帧长动辄几百 bit现场解码再编码的代码量和调试成本直线上升。而原始时序码虽然体积大一个键 100~1000 字节但它不区分协议拿来直接按时间序列驱动 IR 发射管就行天然跨协议通用。所以成熟码库的做法是两套数据都存一套用于逻辑判断和按键映射一套用于物理发射。我们下载到的码库文件结构里一般会看到protocol/存放协议定义raw/存放时序码index索引文件把两者关联起来。理解这一点后面解压码库后对着目录结构才不至于一脸懵。3. 码库文件组织与导入实战从JSON到嵌入式C数组拿到手的一份码库通常包含协议描述文件、品牌设备索引、按键码表和原始时序目录。这一章用实际的文件结构讲解并给出把 JSON 码库转成单片机工程可用 C 数组的完整脚本可以直接抄作业。3.1 常见码库文件结构品牌/设备/功能的三级索引先看一个典型的码库目录布局ir-codebase/ ├── protocols/ │ ├── nec.json │ ├── sony_sirc.json │ └── rc5.json ├── devices/ │ ├── brand_a/ │ │ ├── tv.json │ │ └── ac.json │ └── brand_b/ │ └── soundbar.json ├── raw/ │ ├── brand_a_tv_power.raw │ └── brand_a_ac_swing.raw └── index.jsonprotocols/下每个文件定义一种协议的载波频率、时序单位和位定义devices/按“品牌 → 设备类型 → 具体机型”的路径组织raw/里的 .raw 文件就是纯数字序列每行一个时间值或一组“时间,时间”对index.json则把三者绑定。打开nec.json看协议定义{ name: NEC, carrier_hz: 38000, unit_us: 560, header: {high: 16, low: 8.4}, zero: {high: 1, low: 1}, one: {high: 1, low: 3}, repeat: {high: 16, low: 4} }这里carrier_hz是载波频率 38kHzunit_us是基本时间单位 560usheader 的high:16, low:8.4表示 16 × 560us 8960us 高电平、8.4 × 560us 4704us 低电平。这种用倍数代替绝对时间的设计是为了适应不同晶振精度下的微调比直接写死微秒数更灵活。注意不同码库对unit_us的处理方式不同有的是直接给微秒绝对值有的是给倍数。导入前先确认你的发射库是按哪种方式解析的否则会出现所有按键整体时基偏移看起来每段都是对的但设备就是不认。3.2 用Python把码库转成单片机用的编码表单片机 C 工程里最省心的存储格式是const uint16_t数组因为可以直接放进flash。写一个 Python 脚本读取 JSON 和 raw 文件自动生成头文件import json import glob import os def raw_file_to_c_array(raw_path, key_name): with open(raw_path, r) as f: lines f.read().strip().split(\n) timings [] for line in lines: line line.strip() if not line or line.startswith(#): continue parts line.replace(,, ).split() for p in parts: timings.append(int(p)) arr_str , .join(str(x) for x in timings) return fconst uint16_t {key_name}[] {{ {arr_str} }};\n def gen_codebase_header(index_path, raw_dir, output_path): with open(index_path, r) as f: index json.load(f) lines [#ifndef IR_CODEBASE_H, #define IR_CODEBASE_H, #include stdint.h, ] for entry in index[devices]: for func, raw_file in entry[functions].items(): raw_path os.path.join(raw_dir, raw_file) key f{entry[brand]}_{entry[type]}_{func}.lower() lines.append(raw_file_to_c_array(raw_path, key)) lines.append() lines.append(#endif) with open(output_path, w) as f: f.write(\n.join(lines)) if __name__ __main__: gen_codebase_header(index.json, raw, ir_codebase.h)脚本逻辑是按index.json里的映射关系找到每个功能对应的 raw 文件把里面的时间序列完整展开成 C 数组数组名由品牌、设备类型和功能名拼接。生成后直接在工程里#include ir_codebase.h用的时候按数组名索引即可。参数说明index.json的结构必须含devices数组每项有brand、type、functions三个字段functions是字典键是功能名如 power、volume_up值是 raw 文件的相对路径。如果你的码库结构略有出入改一下entry取值那段就行。生成的头文件体积取决于码库大小空调类码库一个键可能 300 个时间值即 600 字节一台电视的按键满打满算 40 个键也就 24KB 左右。对于 STM32 这类 flash 以 128KB 起步的芯片完全够用但对 8 位小 flash MCU就得考虑改用压缩存储或只加载需要的品牌子集。3.3 按键映射与设备匹配user_code与device_code的对应关系码库能不能真正接入业务逻辑关键在按键映射。以某个品牌的电视为例index.json里不仅有 raw 路径还包含协议层的用户码和功能码信息{ brand: brand_a, type: tv, protocol: nec, user_code: 0x00FF, functions: { power: {device_code: 0x45, raw: raw/brand_a_tv_power.raw}, volume_up: {device_code: 0x44, raw: raw/brand_a_tv_volup.raw} } }在做万能遥控器的逻辑层时你可能会想既然知道了 user_code 和 device_code我为什么不直接在线编码发送还要存 raw这里有个工程判断对于 NEC 这类短协议在线编码没问题但空调很多按键的帧长达 200bit 以上且不同温度、风速组合要动态拼接数据位纯解码码方案做起来极容易出错。所以实际项目里标准功能键用 raw 直发动态参数键用协议在线编码两者配合。按键映射表也比较讲究业务层不能写死功能名到 GPIO 的关系而是通过一个按键事件表来中转。例如typedef struct { uint16_t event_id; const uint16_t *raw_data; uint16_t len; } key_event_t; const key_event_t key_map[] { {EVENT_POWER, ir_brand_a_tv_power, sizeof(ir_brand_a_tv_power)/sizeof(uint16_t)}, {EVENT_VOL_UP, ir_brand_a_tv_volume_up, sizeof(ir_brand_a_tv_volume_up)/sizeof(uint16_t)}, };这样上层的按键逻辑只需要知道EVENT_POWER具体发射数据由映射表决定。如果码库里没有某个按键的码只需要在key_map里留空位业务代码不用改。这是码库落地到产品里最容易踩到的结构坑——把码库数据直接和业务逻辑耦合在一起后面每加一个品牌的遥控器就要改一遍主流程代码。具备index.json的码库实际上是在数据层面帮我们解耦了业务侧只需要加载对应地图即可。4. 发射与学习码库能不能用取决于发射电路和采样精度码库里的数据最终要靠红外发射管打出去也要靠红外接收头采回来。这一章解决两个核心问题怎么把码库时序数据变成物理红外光以及学习模式下怎么把别人的遥控器码采集下来补进码库。4.1 38kHz载波与红外发射管的驱动电路红外遥控的发射本质上是 38kHz 载波信号被码库时序调制的过程逻辑 1 或者 0 对应着载波“有”还是“无”。绝大多数码库协议定义文件里的carrier_hz: 38000对应的就是发射管要工作在 38kHz 频率上。MCU 侧通常有两种驱动方式一是 PWM 通道直接产生 38kHz 方波用一个 IO 控制载波输出使能二是内置红外发送外设比如 STM32 的 TIM 配合输出比较。驱动电路一般是三极管或 MOSFET 加一个限流电阻IR 发射管串在其中。以最常见的 NPN 三极管驱动为例// TIM2 输出 38kHz PWM, duty 33% void ir_carrier_start(void) { TIM2-CCER | TIM_CCER_CC1E; // 使能 PWM 输出 } void ir_carrier_stop(void) { TIM2-CCER ~TIM_CCER_CC1E; // 关闭 PWM 输出 } void ir_send_raw(const uint16_t *timings, uint16_t len) { for (uint16_t i 0; i len; i) { if (i % 2 0) { ir_carrier_start(); delay_us(timings[i]); } else { ir_carrier_stop(); delay_us(timings[i]); } } ir_carrier_stop(); }这段代码的要点i % 2 0时是脉宽段发射载波奇数下标是间隔段停发。delay_us的精度直接决定码库时序的保真度使用定时器微秒延时或DWT延时都比普通for循环可靠。PWM 的占空比设置在 1/3 左右比较常见因为红外发射管峰值电流大平均电流过大容易烧管占空比太低又打不远实测 33% 在 3~8 米距离内接收可靠。提示有些码库的 raw 数据不是“高低交替”从高电平开始而是从间隔开始。发送前判断第一个时间值的奇偶下标如果第 0 个元素是低电平需要先ir_carrier_stop()延时再进入循环否则开头会多出一小段载波。4.2 学习模式用TSOP4838采样并解码的完整流程码库不是天生完整的总有新机型不在库里。学习模式的作用就是把实体遥控器的码抓下来转成时序数据补进码库。硬件上采用一体化红外接收头 TSOP4838它内部集成了 38kHz 带通滤波器、解调器和输出级接上 VCC、GND 和 OUT 三个引脚就能用。注意接收头的输出逻辑与发射相反——收到载波时输出低电平空闲时输出高电平。采样的核心思路是记录输出引脚每个电平的持续时间用定时器捕获或外部中断加计数器。用外部中断的简化流程volatile uint32_t last_tick 0; volatile uint16_t capture_buf[512]; volatile uint16_t capture_idx 0; void EXTI_IRQHandler(void) { uint32_t now DWT-CYCCNT; uint32_t diff_us (now - last_tick) / (SystemCoreClock / 1000000); if (capture_idx 512) { capture_buf[capture_idx] (uint16_t)diff_us; } last_tick now; EXTI-PR | EXTI_PR_PR0; }中断每次触发时记录上一次电平持续的时间。因为接收头空闲输出高电平收到引导码后变成低电平于是边沿触发中断就捕获到了完整的“高-低-高-低”交替序列。capture_buf里存的奇数下标是间隔偶数下标是脉宽和码库 raw 格式一致。由于采集过程是把接收头输出的解调信号直接量化省去了协议解析所以任何协议的码都能抓这也是原始时序码作为码库通用格式的优势。采样需要注意diff_us的精度。DWT 计数频率等于系统主频一般 72MHz 或 168MHz除以计数频率得到微秒。如果系统主频较低如 8MHz微秒级分辨率会丢失细节建议用定时器输入捕获或 PLL 锁相到更高主频。4.3 码库回放验证按键响应率怎样才算合格回放验证是检查码库数据可用的最后一关。把刚采集的 raw 数据原样发射给真机观察设备响应。评判标准不是一个按键能不能触发而是连续按 20 次、间隔 1 秒设备至少响应 18 次才算合格。达不到时要查两个方向一是采样时发射端和接收端的距离与角度靠太近反而会导致接收头饱和波形畸变二是载波频率匹配38kHz 载波用 36kHz 接收头解调信号衰减严重采集到的码会缺帧。验证时建议写一个回环测试函数把采集的 raw 数据打印出来再对照协议文件里的时序描述逐段检查。常见做法是把空调遥控器的某个键发给逻辑分析仪对比自动解码后的协议字段和码库index.json里的 device_code 是否一致。这一步其实就是交叉验证把物理层的时序和逻辑层的数据对上了码库的可靠性才算真正闭环。5. 红外码库避坑指南三个最容易翻车的环节码库本身是一份静态数据但把数据变成实际可用的遥控功能时硬件环境、代码实现、库内数据结构都会成为不确定因素。下面的问题都是实战中反复遇到的每一条按“现象 → 原因 → 解决”写清楚。5.1 现象同一个码库文件在A设备能用在B设备失灵同一份 raw 数据在两个不同型号的发射板上表现截然不同一个响应稳定一个完全没反应。原因是不同开发板的晶振精度和延时函数实现差异导致了时序偏移。有的板子 HSE 晶振误差达到 0.5%如果延时函数基于系统主频计算但实际主频偏了每一段脉宽都会等比放大或缩短。NEC 这类容差较大的协议还能承受空调之类的长帧协议对时序敏感得多几个微秒的偏差在长帧积累后就会导致设备不认。解决方法是固定时基并校准优先使用定时器硬件延时取代软件空循环如果必须用软件延时在烧录后用一个已知协议比如 NEC 引导码 9ms实测校准系数。我一般会在工程里预留一个校准函数发射一段已知的 100 个 560us 脉冲用示波器量总时长算出补偿系数后全局应用。5.2 现象学习到的码发射出去对方设备没反应用接收头采样实体遥控器的码保存为 raw回头发射出去却失效。原因多半是采样时没有区分“载波”和“间隔”。接收头解调后的信号是去掉 38kHz 载波的包络但不同接收头对载波脉冲的响应边沿有延迟导致学习到的脉宽比原始发射脉宽偏窄或偏宽。此外采样过程中周围环境红外干扰如阳光、节能灯会叠加进捕获序列造成多余的电平跳变。解决对策是增加滤波和平滑处理对连续捕获的电平做去毛刺小于 40us 的脉冲直接忽略学习前多采几帧做对齐比较取众数时间值。最稳的做法是把学习到的码与公开码库同品牌同型号的 raw 做一次差值对比偏差超过 15% 的段标记出来人工确认。5.3 现象码库里找不到自家电视型号这是体验层面最常被吐槽的问题码库品牌覆盖很广但具体机型不在列表里。原因有两个层面一是码库按“品牌型号”索引但同品牌下的不同系列可能使用不同协议和不同用户码二是很多电视的遥控码在出厂时存在“地域差异”或“批次差异”同型号不同批次可能用不同码表。解决思路是按“品牌设备类型按键功能”模糊匹配而不是精确匹配型号。码库设备映射表里把同一个用户码下的所有机型归为同一组优先匹配用户码再尝试验证 power 键。实际操作中我会先加载该品牌所有机型列表逐个试 power 和 volume_up响应成功后锁定用户码再自动切换为按用户码驱动。这个“试配”逻辑比让用户翻说明书找型号可靠得多。5.4 现象载波频率不同导致码库“看起来正确但发射失败”raw 数据的时序完全正确逻辑分析仪解码也没有错误但设备就是没反应。排查到最后发现是载波频率不对。码库协议文件写了 NEC 用 38kHz而实际某品牌用的是 36.7kHz 或 40kHz尤其是早期进口家电载波频率五花八门。这时发射 PWM 的频率不匹配接收端解调电路无法有效提取包络。解决办法是检查协议定义文件里的 carrier 字段把发射 PWM 频率修改为对应值。如果你的码库包含多套载波频率发射逻辑要支持启动前动态重装定时器分频系数而不是让所有协议共用同一套频率设置。5.5 现象重复码、组合键与遥控器本身的状态机长按“音量”时电视应该连续调节音量很多空调遥控器按“模式”需要干接点信号连续切换。码库里如果只保存单帧数据不处理重复码长按行为就会变成只执行一次。NEC 协议在按键按住时发送重复帧引导码短引导命令码Sony SIRC 则是每 45ms 重发完整帧。如果按通码库裸发单帧长按无效按完整帧重发则很多设备会当成连续多次的独立按键来响应。正确做法是借鉴码库协议定义里的repeat字段NEC 发送完整帧延时 40ms 或 110ms 后发送重复帧直到按键释放Sony 则是循环完整帧间隔 45ms。做按键状态机时要区分“点击”和“长按”用 GPIO 扫描时记录按键按下的持续时间来控制重复发送逻辑。空调这类设备还要小心部分型号在收到重复码时会周期切换运行模式必须有对应的协议状态机配合最稳妥的调法是参照原装遥控器按同样节奏录制把一段完整的交互序列直接录成宏发送。6. 自建码库的进阶技巧用逻辑分析仪反推未知协议拿到一个不在码库里的遥控器快速反推出它的协议并补充进自己的码库这个能力在实战中非常有用。准备一台采样率不低于 10MHz 的逻辑分析仪外加一个红外接收头模块就能完成整个反推流程。先把接收头 OUT 脚接逻辑分析仪的通道采样率设 2MHz触发方式设为上升沿采样深度 10ms 以上长帧空调码可能要 50ms。用遥控器对准接收头按一个键采到完整的低电平脉冲序列。逻辑分析仪软件会自动显示每段电平的时间宽度这时对照码库里的协议定义逐段分析开头是否有较长的引导码数据位的时间宽度是等宽还是宽度变化高电平宽度和低电平宽度的最小公倍数是多少那个值通常就是时间单位。识别出协议类型后把时间序列按单位宽度量化反向解码成逻辑位。比如引导码 9000us、数据位 560/1680us基本可以判定 NEC 家族再查地址码和命令码是否为取反关系。对于非标准长帧协议很多空调采样后要用 Python 脚本把时间序列分组用聚类找出所有可能的时间槽位再映射成 0/1 序列。最后把结果与公开码库交叉验证锁定了就按前面章节的方法转成 raw 存入码库同时补一条协议描述到protocols/目录下。反推时要格外注意动态逻辑的按键比如温度设置类它的编码包含温度数值不同数值时数据位不同。这类键不适合直接存入静态码库更适合做成协议模板在发射时根据当前参数动态生成时序。经过几次完整的“采样 → 反推 → 验证 → 入库”流程后我现在拆一个新遥控器从拿到硬件到入库一个按键的周期基本能控制在 15 分钟内。每次做完这个流程我都强制跑一遍回放验证的 20 次按键测试确保数据不是“看起来对”。这步习惯帮我避开了很多让人头皮发麻的隐性错误也希望帮到你。本文还有配套的精品资源点击获取
简介红外遥控码库是一份面向电子爱好者、硬件开发者及智能家居集成商的技术资源用于通过编程方式控制电视、空调、投影仪等常见家电其工作原理基于红外通信由发射端将指令编码为光信号接收端解码后执行相应操作。压缩包体积仅27KB内部按设备类别存放遥控码数据覆盖相机、空调、网络电视等多种类型方便按需选用目前已吸引3353人学习/下载同时资源附带了可访问约30000种设备码的开源码库网址能显著拓展设备兼容范围。开发者可根据具体设备型号挑选匹配的码库文件并通过Python、C等语言自行实现编码与解码功能从而构建个性化智能遥控器或融入自动化场景它既是入门学习红外遥控开发的实用素材也是开源社区共享创新的重要补充能帮助硬件爱好者加速完成从原型验证到实际部署的全流程。1. 红外遥控码库万能遥控器的“记忆体”到底是什么做智能家居、DIY红外转发器或者干脆想手搓一个万能遥控器的人大概率会卡在同一个问题上单片机、发射管、电路图都齐了代码也能编译通过可按下按键对面那台空调、电视、风扇就是纹丝不动。折腾半天问题往往不在硬件而在“码”——你的设备不认识你发的这串红外信号。红外遥控码库说白了就是把市面上主流家电品牌的遥控编码按照统一格式采集、整理、存储下来的数据集。这份资源解决的不是“怎么搭电路”而是“发射什么数据才能让设备听话”。适合正在做红外学习模块、万能遥控器、智能音箱红外网关的开发者也适合想搞明白自家遥控器编码规律然后做二次开发的嵌入式爱好者。码库的格式和结构决定了你能不能用、好用不好用下面从一个拆过不少码库的工程师视角把这套东西掰开讲清楚。2. 红外码的两种存在形式原始时序与协议解码码库里存的到底是哪一种打开任意一份红外码库你通常会看到两种截然不同的数据形态一种是裸露的高低电平时间序列单位是微秒长这样9000, 4500, 560, 560...另一种是十六进制协议数据比如 NEC 协议里的0x00FF00FF。这两种形态对应的是红外遥控信号从物理层到逻辑层的两个阶段理解它们才能搞明白码库内部那些文件为什么这么设计。2.1 NEC协议帧格式从引导码到停止位的33.9ms先说说最常见的基础协议 NEC。几乎所有学习型遥控器的码库里NEC 码都占了半壁江山。NEC 协议的一帧完整信号大概长 108ms分为引导码、地址码、地址反码、命令码和命令反码五个部分。引导码由一个 9ms 的高电平载波发射和一个 4.5ms 的低电平停顿构成作用是告诉接收端“准备开始接收”。接下来是 4 个字节的数据段地址码 8bit、地址反码 8bit、命令码 8bit、命令反码 8bit。每个 bit 的表示方式很有意思逻辑“1”是 560us 高电平加 1680us 低电平逻辑“0”是 560us 高电平加 560us 低电平这就是所谓的脉冲距离编码。所以如果你手里拿到一份0x00FF00FF对应到物理层它意味着地址码0x00、地址反码0xFF、命令码0x00、命令反码0xFF。接收端解码时先检查引导码再检查地址反码和命令反码是否与地址码、命令码按位取反一致四段对应上了才认为这是一帧合法数据。这也是码库能校验数据是否损坏的基础逻辑。提示NEC 协议还有重复码。按键按住不放时引导码后会跟一个 9ms 高电平 2.25ms 低电平的短引导再加一个命令码而不是完整重发整帧。做长按连续调节音量、温度的场景重复码的处理直接影响用户体验后面避坑章节会专门展开。2.2 原始时序码的表示数组、微秒与高低电平协议解码码适合给人阅读和协议分析但真正发射给红外管的时候MCU 需要一个一个电平去控制 IO 翻转。原始时序码就是把一帧信号里的每个高低电平持续时间按顺序排成的数组常见格式有两种一种是“脉冲-间隔”交替数组即 [高电平脉宽, 低电平间隔, 高电平脉宽, 低电平间隔…]另一种是带前缀标记的结构体数组。举个例子某个空调品牌的开机码用 NEC 协议解码后是0x04 0xFB 0x22 0xDD但原始时序码可能是这样uint16_t ir_raw[] { 9000, 4500, // 引导码 560, 1680, // bit 1 560, 560, // bit 0 560, 560, // bit 0 560, 1680 // bit 1 // ... 后续数据位 };这份码库里数据位对应的每个 560us、1680us 时间片就是物理层的时间量化结果。关键点在于接收端解码时允许一定的时间容差比如 NEC 标准 560us 的脉冲实际收到 500us 到 650us 都会被识为同一逻辑位原始时序码则把这个容差也固化进了数据里所以不同码库对同一台设备的同一按键采集出来的时间数组往往不完全一致但都能触发设备。2.3 为什么码库必须同时保留两套数据做个红外转发器的时候最理想的方案是存协议解码码体积小NEC 一个键只要 4 字节发射时现场编码成时序脉冲。但问题来了世界上的红外协议不止 NEC 一种Sony 的 SIRC、飞利浦的 RC5/RC6、三星、东芝、还有各种空调用的超长帧协议规则差异极大。SIRC 有 12bit、15bit、20bit 三种长度RC5 用曼彻斯特编码空调码帧长动辄几百 bit现场解码再编码的代码量和调试成本直线上升。而原始时序码虽然体积大一个键 100~1000 字节但它不区分协议拿来直接按时间序列驱动 IR 发射管就行天然跨协议通用。所以成熟码库的做法是两套数据都存一套用于逻辑判断和按键映射一套用于物理发射。我们下载到的码库文件结构里一般会看到protocol/存放协议定义raw/存放时序码index索引文件把两者关联起来。理解这一点后面解压码库后对着目录结构才不至于一脸懵。3. 码库文件组织与导入实战从JSON到嵌入式C数组拿到手的一份码库通常包含协议描述文件、品牌设备索引、按键码表和原始时序目录。这一章用实际的文件结构讲解并给出把 JSON 码库转成单片机工程可用 C 数组的完整脚本可以直接抄作业。3.1 常见码库文件结构品牌/设备/功能的三级索引先看一个典型的码库目录布局ir-codebase/ ├── protocols/ │ ├── nec.json │ ├── sony_sirc.json │ └── rc5.json ├── devices/ │ ├── brand_a/ │ │ ├── tv.json │ │ └── ac.json │ └── brand_b/ │ └── soundbar.json ├── raw/ │ ├── brand_a_tv_power.raw │ └── brand_a_ac_swing.raw └── index.jsonprotocols/下每个文件定义一种协议的载波频率、时序单位和位定义devices/按“品牌 → 设备类型 → 具体机型”的路径组织raw/里的 .raw 文件就是纯数字序列每行一个时间值或一组“时间,时间”对index.json则把三者绑定。打开nec.json看协议定义{ name: NEC, carrier_hz: 38000, unit_us: 560, header: {high: 16, low: 8.4}, zero: {high: 1, low: 1}, one: {high: 1, low: 3}, repeat: {high: 16, low: 4} }这里carrier_hz是载波频率 38kHzunit_us是基本时间单位 560usheader 的high:16, low:8.4表示 16 × 560us 8960us 高电平、8.4 × 560us 4704us 低电平。这种用倍数代替绝对时间的设计是为了适应不同晶振精度下的微调比直接写死微秒数更灵活。注意不同码库对unit_us的处理方式不同有的是直接给微秒绝对值有的是给倍数。导入前先确认你的发射库是按哪种方式解析的否则会出现所有按键整体时基偏移看起来每段都是对的但设备就是不认。3.2 用Python把码库转成单片机用的编码表单片机 C 工程里最省心的存储格式是const uint16_t数组因为可以直接放进flash。写一个 Python 脚本读取 JSON 和 raw 文件自动生成头文件import json import glob import os def raw_file_to_c_array(raw_path, key_name): with open(raw_path, r) as f: lines f.read().strip().split(\n) timings [] for line in lines: line line.strip() if not line or line.startswith(#): continue parts line.replace(,, ).split() for p in parts: timings.append(int(p)) arr_str , .join(str(x) for x in timings) return fconst uint16_t {key_name}[] {{ {arr_str} }};\n def gen_codebase_header(index_path, raw_dir, output_path): with open(index_path, r) as f: index json.load(f) lines [#ifndef IR_CODEBASE_H, #define IR_CODEBASE_H, #include stdint.h, ] for entry in index[devices]: for func, raw_file in entry[functions].items(): raw_path os.path.join(raw_dir, raw_file) key f{entry[brand]}_{entry[type]}_{func}.lower() lines.append(raw_file_to_c_array(raw_path, key)) lines.append() lines.append(#endif) with open(output_path, w) as f: f.write(\n.join(lines)) if __name__ __main__: gen_codebase_header(index.json, raw, ir_codebase.h)脚本逻辑是按index.json里的映射关系找到每个功能对应的 raw 文件把里面的时间序列完整展开成 C 数组数组名由品牌、设备类型和功能名拼接。生成后直接在工程里#include ir_codebase.h用的时候按数组名索引即可。参数说明index.json的结构必须含devices数组每项有brand、type、functions三个字段functions是字典键是功能名如 power、volume_up值是 raw 文件的相对路径。如果你的码库结构略有出入改一下entry取值那段就行。生成的头文件体积取决于码库大小空调类码库一个键可能 300 个时间值即 600 字节一台电视的按键满打满算 40 个键也就 24KB 左右。对于 STM32 这类 flash 以 128KB 起步的芯片完全够用但对 8 位小 flash MCU就得考虑改用压缩存储或只加载需要的品牌子集。3.3 按键映射与设备匹配user_code与device_code的对应关系码库能不能真正接入业务逻辑关键在按键映射。以某个品牌的电视为例index.json里不仅有 raw 路径还包含协议层的用户码和功能码信息{ brand: brand_a, type: tv, protocol: nec, user_code: 0x00FF, functions: { power: {device_code: 0x45, raw: raw/brand_a_tv_power.raw}, volume_up: {device_code: 0x44, raw: raw/brand_a_tv_volup.raw} } }在做万能遥控器的逻辑层时你可能会想既然知道了 user_code 和 device_code我为什么不直接在线编码发送还要存 raw这里有个工程判断对于 NEC 这类短协议在线编码没问题但空调很多按键的帧长达 200bit 以上且不同温度、风速组合要动态拼接数据位纯解码码方案做起来极容易出错。所以实际项目里标准功能键用 raw 直发动态参数键用协议在线编码两者配合。按键映射表也比较讲究业务层不能写死功能名到 GPIO 的关系而是通过一个按键事件表来中转。例如typedef struct { uint16_t event_id; const uint16_t *raw_data; uint16_t len; } key_event_t; const key_event_t key_map[] { {EVENT_POWER, ir_brand_a_tv_power, sizeof(ir_brand_a_tv_power)/sizeof(uint16_t)}, {EVENT_VOL_UP, ir_brand_a_tv_volume_up, sizeof(ir_brand_a_tv_volume_up)/sizeof(uint16_t)}, };这样上层的按键逻辑只需要知道EVENT_POWER具体发射数据由映射表决定。如果码库里没有某个按键的码只需要在key_map里留空位业务代码不用改。这是码库落地到产品里最容易踩到的结构坑——把码库数据直接和业务逻辑耦合在一起后面每加一个品牌的遥控器就要改一遍主流程代码。具备index.json的码库实际上是在数据层面帮我们解耦了业务侧只需要加载对应地图即可。4. 发射与学习码库能不能用取决于发射电路和采样精度码库里的数据最终要靠红外发射管打出去也要靠红外接收头采回来。这一章解决两个核心问题怎么把码库时序数据变成物理红外光以及学习模式下怎么把别人的遥控器码采集下来补进码库。4.1 38kHz载波与红外发射管的驱动电路红外遥控的发射本质上是 38kHz 载波信号被码库时序调制的过程逻辑 1 或者 0 对应着载波“有”还是“无”。绝大多数码库协议定义文件里的carrier_hz: 38000对应的就是发射管要工作在 38kHz 频率上。MCU 侧通常有两种驱动方式一是 PWM 通道直接产生 38kHz 方波用一个 IO 控制载波输出使能二是内置红外发送外设比如 STM32 的 TIM 配合输出比较。驱动电路一般是三极管或 MOSFET 加一个限流电阻IR 发射管串在其中。以最常见的 NPN 三极管驱动为例// TIM2 输出 38kHz PWM, duty 33% void ir_carrier_start(void) { TIM2-CCER | TIM_CCER_CC1E; // 使能 PWM 输出 } void ir_carrier_stop(void) { TIM2-CCER ~TIM_CCER_CC1E; // 关闭 PWM 输出 } void ir_send_raw(const uint16_t *timings, uint16_t len) { for (uint16_t i 0; i len; i) { if (i % 2 0) { ir_carrier_start(); delay_us(timings[i]); } else { ir_carrier_stop(); delay_us(timings[i]); } } ir_carrier_stop(); }这段代码的要点i % 2 0时是脉宽段发射载波奇数下标是间隔段停发。delay_us的精度直接决定码库时序的保真度使用定时器微秒延时或DWT延时都比普通for循环可靠。PWM 的占空比设置在 1/3 左右比较常见因为红外发射管峰值电流大平均电流过大容易烧管占空比太低又打不远实测 33% 在 3~8 米距离内接收可靠。提示有些码库的 raw 数据不是“高低交替”从高电平开始而是从间隔开始。发送前判断第一个时间值的奇偶下标如果第 0 个元素是低电平需要先ir_carrier_stop()延时再进入循环否则开头会多出一小段载波。4.2 学习模式用TSOP4838采样并解码的完整流程码库不是天生完整的总有新机型不在库里。学习模式的作用就是把实体遥控器的码抓下来转成时序数据补进码库。硬件上采用一体化红外接收头 TSOP4838它内部集成了 38kHz 带通滤波器、解调器和输出级接上 VCC、GND 和 OUT 三个引脚就能用。注意接收头的输出逻辑与发射相反——收到载波时输出低电平空闲时输出高电平。采样的核心思路是记录输出引脚每个电平的持续时间用定时器捕获或外部中断加计数器。用外部中断的简化流程volatile uint32_t last_tick 0; volatile uint16_t capture_buf[512]; volatile uint16_t capture_idx 0; void EXTI_IRQHandler(void) { uint32_t now DWT-CYCCNT; uint32_t diff_us (now - last_tick) / (SystemCoreClock / 1000000); if (capture_idx 512) { capture_buf[capture_idx] (uint16_t)diff_us; } last_tick now; EXTI-PR | EXTI_PR_PR0; }中断每次触发时记录上一次电平持续的时间。因为接收头空闲输出高电平收到引导码后变成低电平于是边沿触发中断就捕获到了完整的“高-低-高-低”交替序列。capture_buf里存的奇数下标是间隔偶数下标是脉宽和码库 raw 格式一致。由于采集过程是把接收头输出的解调信号直接量化省去了协议解析所以任何协议的码都能抓这也是原始时序码作为码库通用格式的优势。采样需要注意diff_us的精度。DWT 计数频率等于系统主频一般 72MHz 或 168MHz除以计数频率得到微秒。如果系统主频较低如 8MHz微秒级分辨率会丢失细节建议用定时器输入捕获或 PLL 锁相到更高主频。4.3 码库回放验证按键响应率怎样才算合格回放验证是检查码库数据可用的最后一关。把刚采集的 raw 数据原样发射给真机观察设备响应。评判标准不是一个按键能不能触发而是连续按 20 次、间隔 1 秒设备至少响应 18 次才算合格。达不到时要查两个方向一是采样时发射端和接收端的距离与角度靠太近反而会导致接收头饱和波形畸变二是载波频率匹配38kHz 载波用 36kHz 接收头解调信号衰减严重采集到的码会缺帧。验证时建议写一个回环测试函数把采集的 raw 数据打印出来再对照协议文件里的时序描述逐段检查。常见做法是把空调遥控器的某个键发给逻辑分析仪对比自动解码后的协议字段和码库index.json里的 device_code 是否一致。这一步其实就是交叉验证把物理层的时序和逻辑层的数据对上了码库的可靠性才算真正闭环。5. 红外码库避坑指南三个最容易翻车的环节码库本身是一份静态数据但把数据变成实际可用的遥控功能时硬件环境、代码实现、库内数据结构都会成为不确定因素。下面的问题都是实战中反复遇到的每一条按“现象 → 原因 → 解决”写清楚。5.1 现象同一个码库文件在A设备能用在B设备失灵同一份 raw 数据在两个不同型号的发射板上表现截然不同一个响应稳定一个完全没反应。原因是不同开发板的晶振精度和延时函数实现差异导致了时序偏移。有的板子 HSE 晶振误差达到 0.5%如果延时函数基于系统主频计算但实际主频偏了每一段脉宽都会等比放大或缩短。NEC 这类容差较大的协议还能承受空调之类的长帧协议对时序敏感得多几个微秒的偏差在长帧积累后就会导致设备不认。解决方法是固定时基并校准优先使用定时器硬件延时取代软件空循环如果必须用软件延时在烧录后用一个已知协议比如 NEC 引导码 9ms实测校准系数。我一般会在工程里预留一个校准函数发射一段已知的 100 个 560us 脉冲用示波器量总时长算出补偿系数后全局应用。5.2 现象学习到的码发射出去对方设备没反应用接收头采样实体遥控器的码保存为 raw回头发射出去却失效。原因多半是采样时没有区分“载波”和“间隔”。接收头解调后的信号是去掉 38kHz 载波的包络但不同接收头对载波脉冲的响应边沿有延迟导致学习到的脉宽比原始发射脉宽偏窄或偏宽。此外采样过程中周围环境红外干扰如阳光、节能灯会叠加进捕获序列造成多余的电平跳变。解决对策是增加滤波和平滑处理对连续捕获的电平做去毛刺小于 40us 的脉冲直接忽略学习前多采几帧做对齐比较取众数时间值。最稳的做法是把学习到的码与公开码库同品牌同型号的 raw 做一次差值对比偏差超过 15% 的段标记出来人工确认。5.3 现象码库里找不到自家电视型号这是体验层面最常被吐槽的问题码库品牌覆盖很广但具体机型不在列表里。原因有两个层面一是码库按“品牌型号”索引但同品牌下的不同系列可能使用不同协议和不同用户码二是很多电视的遥控码在出厂时存在“地域差异”或“批次差异”同型号不同批次可能用不同码表。解决思路是按“品牌设备类型按键功能”模糊匹配而不是精确匹配型号。码库设备映射表里把同一个用户码下的所有机型归为同一组优先匹配用户码再尝试验证 power 键。实际操作中我会先加载该品牌所有机型列表逐个试 power 和 volume_up响应成功后锁定用户码再自动切换为按用户码驱动。这个“试配”逻辑比让用户翻说明书找型号可靠得多。5.4 现象载波频率不同导致码库“看起来正确但发射失败”raw 数据的时序完全正确逻辑分析仪解码也没有错误但设备就是没反应。排查到最后发现是载波频率不对。码库协议文件写了 NEC 用 38kHz而实际某品牌用的是 36.7kHz 或 40kHz尤其是早期进口家电载波频率五花八门。这时发射 PWM 的频率不匹配接收端解调电路无法有效提取包络。解决办法是检查协议定义文件里的 carrier 字段把发射 PWM 频率修改为对应值。如果你的码库包含多套载波频率发射逻辑要支持启动前动态重装定时器分频系数而不是让所有协议共用同一套频率设置。5.5 现象重复码、组合键与遥控器本身的状态机长按“音量”时电视应该连续调节音量很多空调遥控器按“模式”需要干接点信号连续切换。码库里如果只保存单帧数据不处理重复码长按行为就会变成只执行一次。NEC 协议在按键按住时发送重复帧引导码短引导命令码Sony SIRC 则是每 45ms 重发完整帧。如果按通码库裸发单帧长按无效按完整帧重发则很多设备会当成连续多次的独立按键来响应。正确做法是借鉴码库协议定义里的repeat字段NEC 发送完整帧延时 40ms 或 110ms 后发送重复帧直到按键释放Sony 则是循环完整帧间隔 45ms。做按键状态机时要区分“点击”和“长按”用 GPIO 扫描时记录按键按下的持续时间来控制重复发送逻辑。空调这类设备还要小心部分型号在收到重复码时会周期切换运行模式必须有对应的协议状态机配合最稳妥的调法是参照原装遥控器按同样节奏录制把一段完整的交互序列直接录成宏发送。6. 自建码库的进阶技巧用逻辑分析仪反推未知协议拿到一个不在码库里的遥控器快速反推出它的协议并补充进自己的码库这个能力在实战中非常有用。准备一台采样率不低于 10MHz 的逻辑分析仪外加一个红外接收头模块就能完成整个反推流程。先把接收头 OUT 脚接逻辑分析仪的通道采样率设 2MHz触发方式设为上升沿采样深度 10ms 以上长帧空调码可能要 50ms。用遥控器对准接收头按一个键采到完整的低电平脉冲序列。逻辑分析仪软件会自动显示每段电平的时间宽度这时对照码库里的协议定义逐段分析开头是否有较长的引导码数据位的时间宽度是等宽还是宽度变化高电平宽度和低电平宽度的最小公倍数是多少那个值通常就是时间单位。识别出协议类型后把时间序列按单位宽度量化反向解码成逻辑位。比如引导码 9000us、数据位 560/1680us基本可以判定 NEC 家族再查地址码和命令码是否为取反关系。对于非标准长帧协议很多空调采样后要用 Python 脚本把时间序列分组用聚类找出所有可能的时间槽位再映射成 0/1 序列。最后把结果与公开码库交叉验证锁定了就按前面章节的方法转成 raw 存入码库同时补一条协议描述到protocols/目录下。反推时要格外注意动态逻辑的按键比如温度设置类它的编码包含温度数值不同数值时数据位不同。这类键不适合直接存入静态码库更适合做成协议模板在发射时根据当前参数动态生成时序。经过几次完整的“采样 → 反推 → 验证 → 入库”流程后我现在拆一个新遥控器从拿到硬件到入库一个按键的周期基本能控制在 15 分钟内。每次做完这个流程我都强制跑一遍回放验证的 20 次按键测试确保数据不是“看起来对”。这步习惯帮我避开了很多让人头皮发麻的隐性错误也希望帮到你。本文还有配套的精品资源点击获取
