Unicable 2.0技术摘要
简介
Unicable 2.0技术是第二代的一线技术,在原有技术的基础上,新增了双向通信的功能。区别于一代的由发送设备单向发送命令给接收器;二代的技术规定了一套双向通信的标准,接收端可以根据收到的不同命令回传对于的内容,极大地丰富了命令的多样性和操作空间。
双向通信的实现,为软件实现使用效率更高的、效果更加智能的Unicable控制实现了基础。通过软件更新(如空中下载新软件等方式),不需要更换接收端或者发送端的设备,就可以实现该功能。
DiSEqC 2.0协议
随着Unicable 2.0的技术更新,DiSEqC的通信协议也发生了变化。上述的因果关系可能不太准确,但两者之间的联系确是一直存在的。
关于Unicable 2.0的高低电压,兼容了1.0的功能等与前代相同的信息这里就不在重复叙述了,如果没有请自行阅读《Unicable 1.0技术摘要》。以下,主要讲述两代协议的不同点。
在DiSEqC 1.0命令中,命令的长度是固定的5位,由E0h开头最后由2位数据位收尾。但是在 DiSEqC 2.0中,一条命令的位数并不固定,不同命令的长度不一样。命令的长度从1位到33位不等,详细命令会在后面说明。
下面提及的命令主要以功能介绍为主,为后续静态和动态功能说明做下铺垫,具体的格式请自行参考相关内容,传送门会放于文章末尾。
1. ODU_Channel_change
该命令是单向命令,不需要接收器的回复。该命令用于改变当前所选的频道。该命令的具体格式如下所示,进行代码编写前请先详细阅读命令的格式说明。
操作代码如下图所示,阅读代码时请参考上图中ODU_Channel_change的数据格式,并进一步理解每一位数据的意义,了解每一位数据转换的流程。
2. ODU_Channel_change_PIN
该命令是单向命令,不需要接收器的回复。该命令用于改变当前所选的频道。使用该命令改变的频道会被接收器“加密”,如果下次想要改变当前频道中的内容,必须使用相同的“加密”内容才能成功的让接收器“解锁”实现改变。Data1,2,3内容与ODU_Channel_change完全一致,只有Data4由加密内容 PIN[0,7]组成,该内容由用户自己编写。具体实际用法与方法1相同。
3. ODU_UB_avail
该命令是双向命令,用于查询当前接收器所有可用的频道(UB通道)。接收器收到该命令后会回传一段数据加以说明。操作代码如下所示,可知在进行双向通信时,发送端发送完数据后就开始接收数据。
4. ODU_UB_PIN
该命令是双向命令,用于查询当前接收器所有被PIN“加密”的频道(UB通道)。接收器收到该命令后会回传一段数据加以说明。该命令使用方法与方法3相同。
5. ODU_UB_inuse
该命令是双向命令,用于查询当前接收器所有正在使用的频道(UB通道)。接收器收到该命令后会回传一段数据加以说明。该命令使用方法与方法3相同。
6. ODU_UB_freq
该命令是双向命令,用于查询某个UB通道下的中心频点。接收器收到该命令后会回传一段数据加以说明。
实际操作代码如下图所示,按照回传格式正确读取中频即可。
7. ODU_UB_switches
该命令是双向命令,用于查询某个UB通道下DiSEqC、LNB等信息。接收器收到该命令后会回传一段数据加以说明。该命令中Data2的解析请参考方法1,两者格式一致。
8. 所有 DiSEqC 1.0 命令
DiSEqC 2.0 向下兼容,所有第一代的命令都能在第二代使用。
静态与动态
动态是与静态相对的概念,在DiSEqC 2.0中并没有任何所谓动态搜索的命令,之所以普遍认为DiSEqC 2.0具有动态搜索的功能,只是因为上述的命令在经过重重组合后可以形成动态搜索的功能。下图为简略的动态搜索的流程图,可见即使是最简单的动态搜索,也需要多个命令来共同完成。一款成熟的动态搜索方案必然更加复杂,下面会同样附图一张,该图是某款产品的示意图(仅供学习使用)。
软件注意事项
1. 时序
动态搜索是由多个命令共同组合所完成的,我们必须要考虑到可能存在的时序冲突问题。发送命令时电压由13V上升到18V,发送命令结束会从18V下降到13V,电压直接上升下降的时间等因素都必须考量清楚。
2. 释放时机
如果多个接收端与发送端相连,或者单个接收端与多个发送端相连,甚至存在多个接收端与发送端相互交叉(这些情况都是可能存在的)。所以平衡什么时候我们释放掉单个操作的连线就很重要,如果释放过于频繁会让13V- 18V反复跳动,让时间变长影响效率。如果释放时间过长,会导致接收端(发送端)被长期占用,影响其他功能。