找不到正确的校验和算法

在阅读了很多帖子及其解决方案后，现在在CRC计算器中打孔已有几天了。我似乎找不到此代码基于哪个校验和。
背景
这是Echolab的视频混合器的控制面板和大型机之间的串行通信数据片段。 Echolab在7年前就破产了，多年来，那里的硬件一直在收集灰尘。作为将仍然良好的控制面板重新用于新硬件的项目，我需要将协议转换器连接到这些面板。但是这些面板来自他们建立的最后一个系列。因此，似乎他们在命令上放了一个校验和。而且，我需要处理这些字符串的数据里面，所以我需要找出哪些校验他们使用。




FFFFFF03006B0000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078B0C63AA00
FFFFFF03006C000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078E5A2D1920


FFFFFF03006F0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000079D3AEC7440

这里是顺序发送的8条消息的样本。
FFFFFF是协议中所有消息的标头，后跟消息标识符[03]，然后是黑色字节，后跟地址字节（在这种情况下为68-6F）。
由于有效载荷完全为空，我选择了这些消息。因此，我可以在此示例中表明校验和确实跳了很多。.

077CDDDE7A20   Addr 68  
078221EDC040   Addr 69  
0785774B0FC0   Addr 6A  
078B0C63AA00   Addr 6B  
078E5A2D1920   Addr 6C  
0791974997E0   Addr 6D  
079A775A4720   Addr 6E  
079D3AEC7440   Addr 6F  

因此，仅更改地址号，校验和确实发生了很大变化。这告诉我这不是一个简单的Xor或Add / count和Mod Checksum。
所以我想它是否在CRC域中？但是花了2天的时间在Scandacore和Defuse之类的在线Checksum计算器上。尝试带和不带Header，Message ID等的许多不同组合。有点迷失了..
我排除了校验和中有一个计时器。由于消息在稍后阶段重新出现，并且当存在相同的有效负载时仍具有相同的校验和。
这里有一些消息中有数据。 （你可以看到消息ID 05被重复一次组消息的两倍）



FFFFFF0507FF07FF40800000030000000010100001000000000000000000000000000000000000000000000000000000303A3130303A31300000000000000000313A3030313A30300000000000000000000000000000000000300032003301210039003A003B00380035009F00AB0000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000007F5F6C0

UPDATE EDIT 1
因此在发现4/6字节校验和之后。我深入研究了这是为什么。
半夜烧尽了锅，调查并清理（使其更具可读性）源捕获（1000多个行），我无法使自己满意。 />虽然用于捕获的大型机距离数周了，但我需要为自己找到一个大型机。
今天早晨从这里驱车了2个小时，无法确定大型机是否可以正常工作。我的面板。由于它们之间可能存在固件差异。
就这样！但是这是好的方面！我没有像以前那样的空消息以便于比较。.但是，拖尾使消息的构造更加清晰。特别是Checksum。
所以我还发现我在看错校验码。 （和错过了应包括字符串的校验和以2个字节
首先几个样品，下面的一些更多的说明：

FFFFFF0301560000000000000000000000000000001F43333F3C0143330C6601431E0C060F430C0C3C01430C0C6001430C0C661F5F0C0C3C000000000000000000000000000000000000000000000E000000001B000000001B000000000E000000001B000000001B000000000E00000000000000000000000000000000006F686ABF4D60
FFFFFF03015700000000000000000000000000000000063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037D7D6663030000000000000000000000000000006F6874AEFEE0
FFFFFF0301580000000000000000000000000000000770771611E00036316330003363303003736331E000336373000031461B3007714619E000000000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037B30F76F900FSF630F0SF630F6303F630F6303F630F6303F230F6303F0600F6303F0600F63F0160F0F63F63F0F3F0F3F0F3F0F3F0F3F0F1F3F0F1F3F0F1F3F0F1F3F0F0F1F1F3F0F1F1F3B0F1F1B3B1F3B3B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B1B 1800006031F8000060331800006633180003E3E318000000000001C39787EFC1C3B0D460C1E7B0D460C1E7B0C7E7C1B5B0D460C1B5B0D460C181979460C000000000000337B470000381B470000301B6F0000317B6F0000301B3B0000301B3B0000337B030000000000006F68FC406620

/>在这些样品中，我们有以下几点：

Header FFFFFF Message Type 03 Address double byte 0158 Data 120 bytes big X number 6F68 Seems to be data Checksum FEEB80A0 />X号是新的！与其他大型机相比，这确实有所改变。但是在此大型机中，所有346条将数组写入某些LCD智能按钮的消息均保持不变。所以校验和确实是4个字节。在较早的示例中，第一个字符是0。所以我假设他们在校验和的前面和后面都放置了0。
现在我们知道校验和只有4个字节。突出的是它总是以0结尾。我认为这是故意完成的。由于4位填充有点奇怪，您不觉得吗？
所以在我发布此消息后，我会用这一新知识重新制作CRC网站。但是我坚决想先更新这篇文章。