RDM协议详解及其实现-精品文档RDM协议详解及其实现RDM（Remote Device Management）是远程设备管理协议，以DMX512-A为基础DMX512（1990）是单向传输的在DMX512里面，并没有地址信息，所以接收设备可以接收所有的数据，正因如此，只要是DMX512设备，必须设定地址码地址码就是告诉接收设备，从DMX512信号中，接收哪部分数据现代舞台上大量使用了LED灯和摇头灯对使用者来说，最直观的感受，是否有一种简单的方法，直接对这些灯具的DMX地址进行设定，搜索扫描统计外面有多少灯具，返回灯具的基本信息RDM协议可以实现以上的想法RDM是半双工通信，设定0号数据为0xCC，接收设备收到0号数据为0xCC的时候，可以判断为接收到RDM协议本文将从开发者的角度，详细说明RDM协议最小集合实现过程1 预备知识1.1 DMX512知识一帧典型的DMX信号，如图1所示，DMX头电平是一个不小于88μs的低电平，然后一个不小于4μs（典型值8μs）高电平，接着是0号数据，再加上512个真正的数据，DMX信号波特率是250K如图1，1号数据黑色部分是真正的数据，共计11个位，真正有效位是8个，所以数据值范围是0～255，这些真正的数据在不同的接收设备中可以解释为不同含义，例如在一个LED灯具中，灯具特性：通道数为4，通道1红（Red），通道2绿（Green），通道3蓝（Blue），通道4白（White），灯具地址码设定为8，则灯具接收从DMX512的第8个数据开始，接收4个数据，把接收到的4个数据按照顺序解释为红绿蓝白的亮度数据。
1.2 RDM基础知识RDM数据包第3～8字节共计6个字节是UID的信息，对接收端来说，通过UID来判断这个数据包是否属于我RDM数据包第20号数据为Command Class （CC）即命令类型，第21号和第22号数据组合为Parameter ID （PID）即参数类型，通过CC 和PID这两个字段，接收端可以快速的判断RDM要做什么事情，返回什么信息1.3 典型发送和接收的结构图不管中间有多少放大器，都可以简化如图2所示，DMX信号在485电平基础上，从发送端开始发送，接收端接收灯光控制台就是发送端，LED灯、电脑灯、调光柜就是接收端在DMX协议中，发送端一直处于发送状态，接收端一直在接收状态，整个状态是单向的RDM协议，是半双工的，即发送端在一定的时机，切换为接收状态，此时，某个接收端为发送状态在图2中，如果有设备不按照时序翻转接收和发送状态，导致在RS485线路中两个设备同时处于发送状态，那整个状态是混乱的，所有的接收设备收到的信息都是错误的基于不能两个设备同时处于发送状态的原理，RDM协议严格规定了设备的发送和接收状态翻转时间发送端和接收端在不同的时机会状态转换，在RDM中，把收集信息的发送端定义为Controller，提供信息的接收端定义为Responder。
1.4 厂商编码RDM需要采集外面所有的设备，必然需要给每个设备一个唯一的编号，制定RDM协议的ESTA组织把这个问题简化为：给每个厂家一个16 bit的全球唯一码（Manufacturer ID）每个厂家对自己的设备进行一个32 bit的编码这样组合成一个48 bit 的设备码48 bit为6个字节如何向ESTA申请厂家ID，请看链接http：// RDM协议概述2.1 最小命令集一个RDM协议的样本：如图3，这是Controller发给Responder，序号Slot从0开始，0号字节为DMX512的0号字节，在DMX定义为0，在RDM 中定义为SC_RDM=0xCC1号字节定义SC_SUB_MESSAGE=0x01这两个字节是固定的值，在RDM数据包中数值是不变化的2号字节是指示整个数据包的长度，这个长度不包括最后的2个字节的校验和，所以确切的说，一个RDM数据包最长是256+2个字节，最短是24+2个字节3～8和9～14的字节是目的UID和源UID，是由两个字节的厂商ID编码+厂商对自己设备的6个字节编码组合而成第15号字节是发送的RDM信息包的个数需要密切?P注是20号字节Command Class （CC）命令类型，RDM协议定义了3种不同的命令类型，Controller端，DISCOVERY_COMMAND，GET_COMMAND，SET_COMMAND，Responder端在20号字节回应为：DISCOVERY_COMMAND_RESPONSE，GET_COMMAND_RESPONSE，SET_COMMAND_RESPONSE。
第21号和第22号数据组合为Parameter ID （PID）即参数类型，在不同的CC命令类型时，参数类型PID分为不同的类型，列表如表1、表2所示这两个表格说明了RDM协议的最小集RDM是使用大端模式保存和发送数据的2.2 RDM时间一个正常的RDM数据是以DMX数据包为基础的，有头电平，但是时间有一定的区别图4是有3条时间数据第1条，是Responder接收器在接收DMX512的时间第2条，是Responder接收RDM的时间，Break是头电平，时间和DMX是不一样的，头电平在176μs和352μs范围MAB是头电平和0号数据之间的高电平，12μs～88μsInter-slot-Time 是真正数据之间的间隔高电平的时间，最大为2ms在2ms后，还没有接收到下一个数据，可以认为一帧数据已经完成看Total Packet Time统计的时间，这是最大的一帧RDM数据包的时间，440μs是352μs+88μs，n44μs，n是发送的数据个数，包括0号数据，RDM数据和DMX数据都是250 K波特率，每个数据位是4 us，11个数据位，所以一个数据是44μs，（n-1）76μs，是数据间隔高电平的时间，76μs是平均值。
第3条，这个数据包就是Responder对Controller端的DISC_UNIQUE_BRANCH参数类型进行回应的，回应的是特殊的RDM 数据包，没有头电平，中间的数据格式定义也和其他的数据包不一样，在RDM中，这是唯一一个特殊的和平常RDM数据包不一样的包下面分析各个数据包包括对这个特殊数据包的说明有意思的是：RDM规定头电平是176μs和352μs之间，但是笔者在Responder端发送RDM时候，把头电平减少到90μs时候，某一个厂家的Controller接收端同样接收非常稳定这其实是一个兼容性的问题3 RDM数据包详解3.1 Controller端DISCOVERY_COMMAND数据包20号字节Command Class （CC）命令类型=DISCOVERY_COMMAND时，21号和22号数据组合为Parameter ID（PID）参数类型分为3种类型，请看表2-1下面详解这3种数据包，这3种数据包是为了查找线路中的RDM设备，当读者彻底理解的时候，会发现这种在485串行口线路中查找多个设备的思路是如此经典3.1.1 CC=DISCOVERY_COMMAND，PID=DISC_UNIQUE_BRANCH请看图2典型发送和接收，RDM协议是半双工收发的。
在一个发送的时候，其他的设备都是处于接收状态，必须只能是一个发送当接收设备认为自己需要发送的时候，切换为发送状态；同样，原来发送的设备必须处于接收状态，需要无时无刻地保证发送的设备只能是一个Controller端（例如灯光控制台）开机后，并不知道外面有多少Responder（例如LED灯），Controller 发送一个如图5的RDM数据包在图5，Port ID是从第16号字节开始，在第3～8字节中填写广播地址码0xffffffffffff关键的地方就是Lower Bound UID（低UID）和Upper Bound UID（高UID）?化UID前16位是厂商代码，后面32位是厂商设备编码协议规定，当Responder 自身的UID在低UID和高UID之间的时候，需要回应一个数据包显然Responder端回应是简单的，此时比较困难的地方有两个1）Controller端，如何不断的调整低UID和高UID？RDM 协议提出了一个二分法，把0～（248-1）的空间划分为0～（247-1）和247～（248-1），当247～（248-1）在2ms内没有回应，就可以判定这段空间没有RDM设备存在，继续搜索0～（247-1）空间。
2）冲突是必然的如果在0～（247-1）空间有两个RDM 设备，这两个设备，几乎会同时从接收状态翻转为发送状态，两个RDM设备同时发送路上，是线与的关系，等于低电平优先，正常的RDM数据包是有一个头电平的，时间176μs～352μs，这段头电平其实是低电平；当一个设备在发送头电平时，另外一个设备已经在发送正常数据，Controller端收到的都是低电平可以这么说，在冲突检测的时候，头电平是有害的，正常数据和头电平同时发送，信息都变成了低电平为了更加有效的检测冲突，RDM定义了如下Responder回应信息格式：如图6，这个数据包是RDM里面唯一一个特殊的数据包无头电平，定长为24个字节，包含了大量的重复信息，这一切的设计，都是为了Controller端快速的检测是否有冲突！比如19号字节和20号字节不同，校验和不同，21和22字节不同，等等都可以认为是冲突了特别是前面设计的1-7个字节为0xFE，串口状态的接收切换为发送，并不是瞬间完成了，常用的串口芯片74LS184就需要80μs左右的时间才能稳定翻转为另外一个状态，芯片性能的不同，Controller端为兼容性的考虑，可以考虑接收4个以上的0xFE就认为是正常的，从0xAA开始，正真有效的数据开始接收并处理，从9号字节到20号字节就是RDM设备的UID号，重复而已，Controller端找到一个真正有效的UID号，才可以下一步控制。
当Controller检测到冲突时，可以认为有两个及以上的RDM 设备发送数据，再次调整低UID和高UID的范围，直到一个范围内没有冲突，最差情况就是：低UID=高UID=设备UID，至此找到了一个真正的RDM设备可以推算出最差的情况就是有两个RDM设备的UID是连续的3.1.2 CC=DISCOVERY_COMMAND，PID=DISC_MUTE和PID=DISC_UN_MUTE从这里开始后面的RDM数据包都是正常的数据包上面搜索查询RDM设备的思路和构造的特殊回应数据包都是比较经典的，但是配上DISC_MUTE和PID=DISC_UN_MUTE数据包，更加完美在现实中，不是所有的Responder端同时开机的，由于这个情况，Controller端需要周期性的搜索外面的设备，那原先已经搜索到的RDM设备，需要重新再次响应一遍，是不是很繁琐？这个时候，PID=DISC_MUTE包出现了如图7所示当Responder接收端收到属于自己（RDM数据包中第3-8号字节UID 等于自己本身的UID）的这个数据包后，回应一个如图8的数据包如图8，Responder回应的数据格式，ACK=00，。