简介《Otis RSL远程串行接口协议标准》是一份面向电梯通信开发、接口调试与维护人员的英文技术文档围绕 Otis 远程串行链路RSL的数据交换规范展开可用于理解电梯产品与外部设备之间的通信机制。资源为 PDF 格式共 1 个文件压缩包约 663KB原文约 16 页含修订记录、目录和版权声明便于查阅归档。文档从协议概览、OSI 七层模型映射讲到物理层、链路层与应用层涵盖 RS-485 半双工通信、信号电平、帧结构、CRC 校验、命令集与错误代码等要点并给出初始化、建链、传输、错误处理和断开连接的流程。已有 138 人学习适合需要核对 rs5、rs14、rs18 等协议细节、开展串行接口对接与故障排查的工程技术人员参考。1. 一帧 800 微秒只驮 5 个 bitRSL 远程串行接口协议标准到底解决什么问题RSLRemote Serial Link远程串行接口协议最容易被误判成 RS-485 的变种。我第一次翻这份十来页的标准时也这么想直到把示波器夹上去才发现不对它有独立的时钟线四根线里两根走信号、两根送电主站打拍子、从站跟着节拍收发本质上是一条同步移位总线一轮循环里写段 64 个帧时隙、读段 64 个帧时隙每个时隙只有 5 个 bit。这份文档给的是接口层契约——物理电平、帧时序、位映射怎么排不涉及具体业务含义。它适合正在对接老式控制柜外呼/内召面板、楼层显示器、指示灯阵列的人手上有一块面板或一块控制板想知道它到底按什么节拍说话这里能对上。不适合想找现成驱动库的人因为公开的实现几乎没有绝大多数工作得自己从时序图开始搭。2. 四线制物理层DL1/DL2/Return/VRS 怎么接300 米线长怎么算2.1 分层映射为什么 36 层是空的标准里有一张 OSI 七层对照表是最该先看的一页。它明确写了这条总线只实现物理层、链路层和应用层中间四层标注为“Not Supported”。这不是偷懒而是一条单主多从、点到点的位导向总线本来就不需要路由、分段、会话管理和表示层转换。OSI 层本标准的实现情况承载内容7 应用有位映射定义Basic、CPI-11/NEL、Global Aesthetics 三套6 表示无—5 会话无—4 传输无无差错重传、无流控出错就靠链路层判据丢弃3 网络无无地址路由靠帧时隙位置区分从站2 链路有RSL 帧1 物理有RSL 位、电平、连接器第三层缺失是这个协议最反直觉的地方从站没有地址字节。主站在写周期里按固定顺序依次填 64 个帧时隙第 N 个时隙就是第 N 号从站的位置从站在读周期里同样按位置把自己的位塞进对应时隙。换句话说寻址靠的是“你在第几个节拍上应答”而不是报文里带 ID。这一点决定了后面所有的调试方式——你没法用串口助手发一条“读地址 0x05”的命令去试探只能整轮整轮地抓。对比一下常见的三种接口差别就很清楚了维度RSLRS-485RS-232线数4 根2 信号 2 电源2 根差分3 根TX/RX/GND同步方式独立时钟线同步异步靠双方波特率约定异步拓扑单主多从全部并联多点半双工点对点标称距离300 m1200 m低速时15 m 量级寻址帧时隙位置报文里的地址字节无把 RSL 按 RS-485 去接是最常见的翻车起点RS-485 要方向控制引脚RSL 没有RS-485 靠波特率对齐RSL 靠时钟线对齐RS-485 的差分对是 A/BRSL 的两根信号线一根是数据、一根是时钟。硬件上看着都是“两根线传数据”协议行为完全不同。2.2 四针连接器的定义与线对分工从站侧面板类设备用的是一排 4 针连接器一根线束同时把电和信号送过去引脚信号名文档里的描述实际作用1DL1差分信号数据线主站写、从站读2DL2差分信号时钟/同步线由主站驱动3Return电源回线面板电子的回流路径4VRS33 V面板供电正端这里有个文档自身的不一致我踩过连接器表把 DL1、DL2 都写成“Differential – signal for RSL”看着像一对差分信号但正文 4.1.4.1 明确写了 L1 是数据线、L2 是时钟线用于同步。接线时以正文为准——它是两根独立功能的单端信号共模判据是拿 L1 相对 L2 来做参考的不是真正的差分对。提示如果你的板子上 DL1/DL2 接反了现象不是完全不通而是能收到一串毫无规律的位因为时钟线被当成数据线在采。先拿示波器确认哪根上有 100 µs 的规律脉冲那根就是 DL2。2.3 电平判据-635 V 是耐受不是逻辑电平物理层表格里最容易看错的一行是信号电压范围-6.0 V 到 35.0 V。这是绝对最大耐受范围不是判据。真正的判据是分两档的参数最小最大单位数据线绝对电压-6.035.0Vdc共模抑制电压—4.0Vdc逻辑 0-6.00.8Vdc逻辑 117.035.0Vdc供电电压17.735.0Vdc供电压降—2.0Vdc注意逻辑 0 和逻辑 1 之间有一大段空白0.8 V 到 17 V 之间是未定义区。这不是留的余量是因为总线上挂着几十上百个从站长线反射和负载差异会让边沿变缓落在中间区的样点本来就应该被丢弃。共模判据更值得琢磨高电平VL1 ≥ VL2 0.8 V低电平VL1 ≤ VL2 0.3 V也就是说采样的时候不能拿一个固定的地参考去比而要拿时钟线 L2 当时的电平作为浮动参考。0.3 V 和 0.8 V 之间那 0.5 V 是回滞带用于抑制噪声引起的判据抖动。做接收电路时比较器的一端接 L1另一端接 L2 加一个偏置而不是接 GND——这一点如果做错长线上会因为地电位差随机丢位而且这种丢位是“今天好明天坏”的玄学非常难查。2.4 线材、抽头与 300 米上限的算法传输介质的要求写得很具体两条数据线用双绞端到端特性阻抗约 100 Ω分布电容约 60 pF/m最大串行线长 300 m单条抽头长度 2 m。60 pF/m × 300 m 18 nF这个容性负载和 100 Ω 阻抗配起来边沿会被明显拉缓。100 µs 的位宽对边沿不敏感这是它能跑 300 m 的根本原因位宽太宽了但对反射敏感——2 m 的抽头限制就是为了压反射。实际布线时会遇到的做法是主干走双绞、总线型串到底每个从站从主干上“摘”一小段出来这段不超过 2 m不要做成星形从一点发散出去。注意星形接法在实验室短线上经常能跑通装到现场就出问题。我见过一条 200 m 的主干从中间分出去四路各 1.5 m 的支线静态测试全过一上电就间歇性丢帧最后改成菊花链才稳。电源线那一对可以双绞也可以平行要求没数据线那么严但阻抗和电容是同一套指标。工程上一般直接把两对线放在同一根四芯护套里用同一规格的线材省得现场接错。2.5 电源预算17.7 V 下限怎么倒推线径供电标称 33 V允许范围 17.735 V配电线路上的压降不超过 2.0 V。这三个数放在一起其实是在给整条线的电阻定预算。假设一个面板从站取 30 mA一条主干上挂 20 个最远端累计电流按 600 mA 估这是最坏情况全部集中到末端2.0 V / 0.6 A ≈ 3.3 Ω 的往返电阻预算。300 m 往返是 600 m铜线电阻率按 17.5 Ω·mm²/km 算600 m 对应 10.5 Ω·mm²除以 3.3 Ω 得到截面积约 3.2 mm²——远超常见的 0.5 mm² 信号线。所以实际工程里几乎不会真的靠一根线供 20 个面板常见做法是分段供电或者面板侧电流做得极小。文档只给了电压窗口和压降上限没给电流值原文写的是“board specific”这部分必须按你实际的板子去算。我心里的一条经验是远端电压低于 20 V 就说明余量不够了因为线上还有动态压降静态测量合格不代表满载合格。3. 链路层时序800 µs 一帧、64 帧时隙主站怎么打拍子3.1 帧结构拆解时钟脉冲、5 个位、100 µs 死区链路段是整个协议的骨架。一帧标称 800 µs由三部分组成一个 100 µs 的时钟脉冲、5 个各 100 µs 的数据位、以及界定数据位的 100 µs “死区”时隙。这里有个理解上的坑100 5×100 只有 600 µs剩下 200 µs 从哪来文档的说法是“数据位被 100 µs 死区界定”正确的读法是死区嵌在位时间内部而不是额外叠加——每一位的 100 µs 窗口里有效采样区在中间两头留出保护带。如果按“600 死区另算”去推怎么凑都凑不到 800 µs我第一次就是在这个数字上卡了半天。5 个 bit 的排布在时序图上给的是位 1 到 5主站在时钟脉冲之后依次驱动从站在同样的位置采样。一帧只有 5 位意味着这条总线上每个从站每轮能交换的信息量是 5 bit 写 5 bit 读够点几个灯、读几个按钮但要传楼层显示就得靠 ELD 那套帧格式攒。3.2 三种子周期写、同步、读主站驱动的一轮完整数据周期由三段顺序组成写周期、同步周期、读周期。时序图上标得很清楚写段 51.2 ms、同步段 1.6 ms、读段 51.2 ms。51.2 ms ÷ 800 µs 64正好是 64 个帧时隙。同步段的 1.6 ms 是 2 个帧时隙文档写的是“两个不带时钟脉冲的帧”插在每一次写/读之间。这两个空帧的作用是给总线一个明确的段落分隔——从站靠它判断“写段结束了接下来轮到我说话”也是靠它做帧计数的重新对齐。一轮总时长约 104 ms也就是差不多每秒 9.6 轮。这个刷新率对外呼按钮和指示灯完全够用对楼层显示的数字刷新也够但如果要做动画类的东西就别想了。注意同步段的判定不能靠“数满 64 帧就切换”因为上电时你可能从任意一帧开始收。正确做法是靠“连续两个无明显时钟脉冲的帧”这个特征去捕获同步段然后从同步段之后重新计数。这是从站能长期稳定工作的关键。3.3 公差窗口788835 µs 意味着什么帧时序表给了三个参数的上下限参数最小典型最大单位周期时间788800835µs时钟宽度80100146µs数据位宽80100146µs把周期时间拆开看标称 800允许 -12 / 35。也就是说主站的拍子本身就有 1.5%4% 的抖动空间。这个数字对实现方式有直接约束。如果你用软件延时循环去“凑”100 µs在 8 位机上误差很容易超过 10%一轮 130 帧累计下来就是几百微秒的漂移跑几分钟就会错位一帧而且错位之后不会自己恢复看起来像“偶发丢站”。必须用硬件定时器的捕获/比较或者至少用定时器中断做基准。时钟宽度上限 146 µs 这个数比典型值高了 46%说明标准允许比较宽的时钟脉冲接收侧不要用“必须精确 100 µs”的思路去做判据。判据应该是区间判断落在 80146 µs 之间就认为是一个有效位时隙落在外面就准备重新对齐。3.4 从站采样实现定时器捕获加状态机从站侧真正要写的代码不多核心就是一个状态机加一个时间戳。下面是从站接收的骨架用定时器捕获时钟上升沿按半位宽偏移采样数据线/* rsl_rx.c —— 从站侧接收骨架定时器捕获对齐帧边界 */ #include stdint.h #define CLK_MIN_US 80 /* 文档 5.3时钟宽度下限 */ #define CLK_MAX_US 146 /* 文档 5.3时钟宽度上限 */ #define BIT_PERIOD_US 100 /* 位标称宽度 */ #define BITS_IN_FRAME 5 #define FRAMES_PER_SEG 64 /* 写段/读段各 64 个帧时隙 */ typedef struct { uint8_t bits; /* 本帧已收位数 0~4 */ uint8_t frame; /* 当前帧号 0~63 */ uint16_t shadow; /* 本帧暂存低 5 位有效 */ uint16_t table[FRAMES_PER_SEG]; } rsl_rx_t; static rsl_rx_t rx; /* L2 上升沿中断进入一个位时隙 */ void RSL_CLK_ISR(void) { static uint16_t last_edge 0; uint16_t now TIM_GetCounter(); /* 1 us 分辨率 */ uint16_t dt (uint16_t)(now - last_edge); last_edge now; /* 间隔跳出公差带可能是同步段空档也可能是噪声 */ if (dt CLK_MIN_US || dt CLK_MAX_US) { if (rx.bits ! 0) { /* 半途中断本帧作废 */ rx.bits 0; rx.shadow 0; rx.frame (uint8_t)((rx.frame 1) % FRAMES_PER_SEG); } return; } /* 上升沿后半个位宽采样避开边沿抖动区 */ delay_us(BIT_PERIOD_US / 2); rx.shadow (uint16_t)((rx.shadow 1) | (DL1_READ() ? 1u : 0u)); rx.bits; if (rx.bits BITS_IN_FRAME) { rx.table[rx.frame] rx.shadow 0x1F; /* 只保留 5 位 */ rx.shadow 0; rx.bits 0; rx.frame (uint8_t)((rx.frame 1) % FRAMES_PER_SEG); } }逻辑说明dt做的是相邻两个时钟沿的间隔测量落进公差带才认为这是一个有效位半位宽偏移采样是因为边沿附近电平和反射最不稳定凑满 5 位就落进该帧的表项帧号自增溢出自动回绕到 0。参数说明CLK_MIN_US/CLK_MAX_US直接来自 5.3 的时钟宽度区间改小会让抗噪变差改大容易把噪声脉宽当成有效沿FRAMES_PER_SEG对应写段 64 个时隙如果你的模块版本不同要按实际改BIT_PERIOD_US/2是采样点偏移在长线上可以适当往后挪到 0.6 倍位宽因为长线的上升沿更缓。提示中断里调delay_us只是骨架写法量产必须换成硬件方案——定时器比较输出触发 DMA 连续采样或者用输入捕获记录边沿时间戳、事后再算采样点。长阻塞会拖垮主循环而且延时的精度本身也不够稳。3.5 错误检测别自己发明校验文档在链路层末尾用一节讲错误检测。这里最容易犯的错是因为流传的版本这一节内容不全就自己拍脑袋加一个 CRC-8 上去。不能这么干。原因很直接——主站侧不认。RSL 的帧结构里只有 5 个数据位塞完业务信息基本没有空间放强校验标准给出的检测手段大概率是基于时序、位计数、帧计数的轻量判据而不是报文级校验。你额外加字节会直接把帧长打乱。正确的做法是把这一节原文逐字对着实现判据是什么、在哪个环节判、判定失败后是丢弃还是重发全部照抄。如果手上的版本文档这一节是缺的那就不实现只做“时序越界即丢弃本帧”这一条——比自作聪明加一个双方都不认的校验要安全得多。4. 应用层三种位映射Basic、ELD 与 Global Aesthetics 怎么选4.1 Basic 格式主写从读与主读从写应用层最基础的一套叫 Basic RSL 数据格式只有两个方向的定义主站写/从站读以及主站读/从站写。它规定的是那 5 个 bit 分别对应哪个物理点不涉及任何编码转换。这套格式是“够用就好”的典型按钮、钥匙开关这类位输入指示灯、蜂鸣器这类位输出直接一位对一位。对接老式外呼面板用这一套就够了寄存器里的 5 个 bit 一一映射到面板上的五个点位不需要解码层。选它的判断标准很简单如果你的从站设备上的信息全是开关量不要往 ELD 上凑。有些实现为了“统一”把开关量也套进 ELD 帧格式结果每轮多绕一层编解码调试难度翻倍收益为零。4.2 ELD 帧7 段与 16 段位图加字符码表ELD 是电致发光显示器这类字符型面板的数据格式也是这份文档里内容最厚的一块。它给了几样东西ELD 帧的结构定义、7 段和 16 段 LCD 的字符位图、7 位和 16 位的字符码表、帧描述、以及一组 ELD 命令。这里的组织方式是“双表”一张是字符码表把业务语义比如某个方向箭头、某个楼层位映射到码值另一张是位图把码值映射到具体点亮哪几段。实现时的顺序是先用码表查到码值再用位图查到段码最后把段码塞进帧的对应位置。7 段和 16 段的差别不只是段数。7 段只能显示数字和少量字母16 段能显示更多字符形态所以同一个面板型号可能两种都用。麻烦在于段序a 到 g 谁在前、额外段排在哪个 bit是厂商自己定的文档里给了定义但网上的通用段码表大多按另一种排法。直接照抄通用表现象是数字能对、字母全乱或者反过来。4.3 Global Aesthetics帧 0 与帧 1 的分工第三套格式叫 Global Aesthetics文档里按帧切分Frame 0 和 Frame 1。这套的定位是通用的面板外观件比 ELD 更“宽”因为它要适配不同形态的显示和指示设备所以用了两个帧来做分工——一个帧承载一类信息具体哪类按文档 7.3 的定义走。工程上的选择建议如果从站是明确型号的显示器优先按它的模块文档走 ELD如果从站是通用外观件、型号不固定走 Global Aesthetics 更稳因为它的帧定义本身就是为了兼容做的抽象。两套不要在一条总线上混用写段和读段的 64 个时隙分配会打架。4.4 位图反查把段码翻译成人能读的字符调试时最有用的一件事是能把抓到的段码直接翻成字符否则你面对的是一串十六进制。下面这个反查表可以当模板用# seg_decode.py —— 7 段位图反查字符 # 段序 a~g 对应 bit0~bit6这是临时排法 # 落地必须按文档 7.2.2 的位图定义重排不能照抄 SEG7 { 0b0111111: 0, 0b0000110: 1, 0b1011011: 2, 0b1001111: 3, 0b1100110: 4, 0b1101101: 5, 0b1111101: 6, 0b0000111: 7, 0b1111111: 8, 0b1101111: 9, } def decode(bits: int) - str: 输入一帧 7 位段码输出对应字符未知组合返回 ? return SEG7.get(bits, ?) if __name__ __main__: for raw in (0b0111111, 0b0000110, 0b1101101): print(f{raw:07b} - {decode(raw)})逻辑说明字典的键是段码整型值值是字符。用.get而不是下标是为了让未定义的组合不至于抛异常中断整批解码——调试阶段你会遇到大量“本来就不该出现”的段码这些恰恰是最有信息量的。参数说明位序哪个 bit 对应 a 段必须和你实际抓到的数据对齐。做法是先抓一个已知显示比如面板上明确显示“8”看它哪几位是 1反推出位序再去重排字典。这一步不能省省了就会得出“协议解析错了”的错误结论。16 段的表结构一样只是键变成 16 位、条目更多。建议把它单独放一个文件从设备配置文件里读别硬编码在业务代码里——不同面板型号的段序可能不一样换型号时改配置比改代码安全。5. 避坑与排查五条从现场带回来的记录5.1 接线与电平类的三条**第一条上电后从站完全没反应主站侧看本文还有配套的精品资源点击获取