一、概述
GV RCL矩阵控制协议，全称Grass Valley Route Control Language，是Grass Valley公司推出的一款视频矩阵通用控制的协议，该控制协议目前开放，广电系统中很多设备均支持GV RCL，经过这次4K IP转播车系统的设计和集成，应用GV RCL协议做了一些项目应用，在此对协议部分做一些说明记录。
PS：GV RCL协议参考文档链接是GV RCL控制协议说明
二、GV RCL协议中符号的说明
GV RCL控制协议，可通过RS232/RS422串口形式进行传输，也可以通过TCP/IP方式进行传输，在传输内容的格式上均保持一致；使用TCP/IP进行传输时，矩阵端作为TCP服务端，面板或控制端作为TCP客户端。
GV RCL协议说明文档中的符号说明如下图所示，"..."表示一个连续的序列，比如说src_name1...src_nameN表示src_name1~src_nameN共N个源名；"|"表示或，比如说ON|OFF表示开或者关；"[]"表示可选项，如果协议里的内容在可选项括号内，则表示这些内容对于协议来说可以用到也可以不用；"<>"表示必选项，该选项内填的内容是ASCII码或者其他选择性的字符；“,”表示水平制表符，用于传输数据之间进行分割。
三、GV RCL协议格式
RV RCL的一般协议格式如下图所示，图中从上到下为协议数据发送的顺序，发送端和接收端在协议的头尾需要对应上，每条发送请求对应有单独的返回信息。
“SOH”表示发送信息的开头，一般用ASCII码16进制“01”表示；
"protocol_id"表示协议的ID信息，一般用ASCII码16进制“52”表示；
"session_id"表示服务器端的ID信息，一般在服务器初始化的时候发送，固定2个字节的ASCII码，可以不发送；
“message_id”固定4个字节的ASCII码，用于服务器端和客户端通信时，通信信息的ID，ID每次发送随机生成，也可以约定好不发送；
“seq_number”表示发送信息的序列码，字节长度1~4不等，如遇到长数据包时会用到，一般情况下只用一个ASCII字节"30"表示；
"Reserved"表示预留的字节，最多4位，可以不发送；
“Data”表示发送的实际数据，如请求命令“request_cmd”、返回命令“response_cmd”、水平制表符“HT”(ASCII码用16进制"09"表示)和请求命令的参数“parameter”;
“checksum”两个字节码的校验位，校验位的计算如下：从"protocol_id"开始，到“Data”结束，所有16进制数据相加求和，求和后数据除以100取余数，然后再对余数取反码，得到的“checsum”数据，拆分成2个字节位，"checksum0"取高字节位，"checksum1"取低字节位，“checksum0”在“”checksum1“之前，所有操作均在16进制下进行，具体公式如下：
checksum=100-（"protocol_id"+"session_id"+""message_id"+"seq_number"+"Reserved"+"Data"）%100
checksum0=(checksum>>4)>0x09?((checksum>>4)+0x37):((checksum>>4)+0x30)
checksum1=(checksum&0x0F)>0x09?((checksum&0x0F)+0x37):((checksum&0x0F)+0x30)
"EOT"表示传输结束字符，1个字节16进制表示位”04“；
四、客户端到服务端RCL命名参数说明
客户端主要表示矩阵控制面板和控制软件，服务端主要表示矩阵主机，客户端发送请求到服务端，服务端接收到请求信息以后，按照客户端发送的格式，再返送回对应命令。
客户端到服务端的请求命令有40多种，这些命令主要放入在”Data“信息中，如设置源到目的、获取源名和目的信息、修改源名和目的信息、获取源名和目的索引、获取VITC时码信息等等，在此不一一阐述，挑几个比较重要的信息说明以下。
AS-Assign Source，设定源到目的地的信息：
发送端命令为”AS,fullqual_dest_name,nbr_srcs[,fullqual_src_name1…fullqual_src_nameN]“，其中AS用ASCII码表示为”41 53“，”，“为制表符用ASCII码表示”09“，”fullqual_dest_name“表示目的端口的名字，用字母转ASCII码后表示，”nbr_srcs“表示指派到目的地的源名数量（有可能1个目的地，不同的Level指派了不同的信号源），"fullqual_src_name"表示指派的源名名称，这里面源名的数量和“nbr_srcs”里面应该对应的上。
返回端的命令，如果接收并设置成功，则返回“ER,00”，如果接收失败，则返回“ER,nn”,这些所有的返回命令，也用ASCII码表示，并注意加入水平制表符“09”；
QJ-Query Destination Status by Index，获取目的地的源名索引信息，跟QD命令一样：
发送端的命令为“QJ”、“QJ[,fullqual_dest_index]”或”QJ[,area_bitmap:]“，其中只发”QJ“则要求返回所有的目的信息，“QJ[,fullqual_dest_index]”用的比较多，表示要求反回指定目的中的源信息；”fullqual_dest_index“表示全局的目的信息索引，它的全格式为”area_index:destination_index“，”area_index“表示区域的索引，占1个字节（有的矩阵可设置不同的区域，如果矩阵没设置区域，则不用填”area_index“），”destination_index“表示矩阵目的的索引，占4个字节；
返回端的命令为”JQ, fullqual_dest_index,nbr_sources[,src_name_entry1,..., src_name_entryn]“，其中”JQ“、”fullqual_dest_index“和之前发送端一致，”nbr_sources“表示目的地的源名数量，如果只有1个的话，就用ASCII码16进制”31“表示，”src_name_entry“表示对源名信息的一些描述，完整的”src_name_entry“定义”<‘N’|’P’><‘N’|’C’>,fullqual_src_index,level_bitmap,[prot_device_name],[fullqual_chop_src_index]“，”<‘N’|’P’>“表示源名受保护或者不受保护（一般选N），”<‘N’|’C’>“表示源名信息又没哟被分割（一般选N），”fullqual_src_index“表示指派源名的索引，跟”fullqual_dest_index“类似，如果没有”area_index“，就只需要填4位”sourse_index“即可；”level_bitmap“表示目的地址对应的level，1个字节长度，默认是1，用ASCII码表示位”031“；”prot_device_name“和”fullqual_chop_src_index“选填，根据之前”<‘N’|’P’>“和”<‘N’|’C’>“两个参数而定。
五、实际应用案例
在苏州台4K转播车项目中，TallyServer服务器需要从BMD的切换台中获取PGM母线上的交叉点信息，作为切换台Tally系统的备份，而TallyServer支持GV RCL协议，作为客户端，会一直从指定服务端获取交叉点信息。此次项目中，做了GV RCL协议到BMD Tally协议的转换，通过转换软件，先读取BMD PGM母线上的交叉点信息，再把交叉点信息转换成GV RCL协议，发送给TallyServer服务器。
程序接收和发送的核心代码如下：
接收端代码如下图，程序跟BMD切换台和TallyServer服务器建立连接以后，接收TallyServer发送过来的”QJ“请求命名并进行判定，请求命令的前5位用16进制表示为”01 4E 30 51 4A“，其中”01“为”SOH","4E"表示“protocol_id”，“30”表示“seq_number”，“51 4A”表示“QJ”；
当收到TallyServer发送来的QJ请求并判定正确后，软件中通过 “m_mixEffectBlock1.GetProgramInput(out programId)”方法，获取BMD切换台的PGM交叉点信息，将这些交叉点信息差分成2个16进制，并以ASCII码的方式进行转换。
发送端代码如下图，发送端返回给TallyServer的格式，参照之前TallyServer发送过来的，以JQ的方式，图中“sendPGM”数组表示要发送给TallyServer的数据，数据长度固定。
