CRC16真是不可靠啊，这就是什么“碰撞”吗？

只看该作者 · 2012-3-15 22:27

下面的m1_cmd_buf中是收到的随机数据，竟然经常性的CRC16也自然吻合，，，我晕呐。
开始总发现间断性的有错误数据，还以为软件哪里有问题，后来竟然发现这等事。。

4万 · 2012-3-15 23:41

应该是你的理解有误。

1万 · 2012-3-16 00:32

碰撞率是多少？理论应为 1/65536

2万 · 2012-3-16 08:12

如果经常，那么你的运气肯定是超级好，可以去买彩票了，估计中大奖的概率会很大

2万 · 2012-3-16 08:59

理论碰撞几率为 1/65536，不知道LZ的贴图想说明什么。

只看该作者 · 2012-3-16 09:55

是在调试一个射频接收板时发现的，
m1_cmd_buf中实时的移入接收的数据，
每移进来一个bit，就会计算CRC是否吻合，吻合就留下，不符就整个数组左移一次并把下一个bit移进来，再计算。
m1_cmd_buf[9]、m1_cmd_buf[10]是默认的CRC16的位置。

然后在调试的时候发现有错误的数据进来，与设计的功能严重不符，后来就查，结果发现这些随机数据，竟然他自己吻合了CRC16.

整个m1_cmd_buf数据中的数据，都是一个bit一个bit的随机进来的.

后来，就加长了帧的标识头，又试了很久，没再发现这个问题了。

只看该作者 · 2012-3-16 10:00

理论碰撞几率为 1/65536？
不懂CRC原理，不过如果真是这个几率的话倒也可以解释了，因为数据的速率很高，短期内有大量的随机数进来，逮到几个也可以理解了吧。

我怀疑是不是2^16。。。

只看该作者 · 2012-3-16 10:05

3# dengm

dengm多谢啦，当时试验的时候，大概...一个小时内总能碰到两三次，

后来就把帧头加长了2个B，这样相当于把这个可能性又降低到1/65536了，后来测了很久，没再发现！

只看该作者 · 2012-3-16 10:06

4# yewuyi

yewuyi老大，一个小时内大概能逮到2、3次，，，

2万 · 2012-3-16 10:11

理论碰撞几率为 1/65536？
不懂CRC原理，不过如果真是这个几率的话倒也可以解释了，因为数据的速率很高，短期内有大量的随机数进来，逮到几个也可以理解了吧。

我怀疑是不是2^16。。。 ...
helloop 发表于 2012-3-16 10:00

呵呵，2^16不就是65536嘛~

只看该作者 · 2012-3-16 10:33

哈，多谢xwj，我的疑惑是不是几率就2^16这么小，感觉伟大的CRC应该可靠性超级高才对...
我的移动硬盘里几百G的文件复制过去后，再按内容比较，从来都没发现过哪怕一个字节的错误啊。

另外，这个就是叫“碰撞”吗？网上搜，都解释的云里雾里的。。

这些数据真的是随机逮到的，发射机肯定也没发射，把发射机的电池都拿掉了，而且还有频谱仪在旁边看着

2万 · 2012-3-16 10:47

呵呵，速率高了当然总会有“中彩”的时候，只是中彩几率问题。
不然咋会有“暴力**”呢？

你这个就是过滤条件太简陋，被噪声信号“暴力**”了:lol

只看该作者 · 2012-3-16 12:13

mark

3万 · 2012-3-16 12:39

你的通信协议还缺少一个"Len"域……
一般的做法是：
1-收到帧头，清空缓冲区
2-收到帧尾，则认为收到一个完整帧，接着使用一系列方法判断是否正确：CRC,命令是否合法，长度是否合法……
3-其他字符，则丢到缓冲区，并接着检测缓冲区是否满，如满则清空

2万 · 2012-3-16 13:17

LS正解。

帧头、长度、检验，这是必须的。

不过第3点不是很科学，应该改进

只看该作者 · 2012-3-16 13:18

len是有的，这里没显示，这个数组不包括len段，多谢啊

只看该作者 · 2012-3-16 13:31

可以再简单的加一个垂直检验的域，当垂直检验通过时再进一步检测CRC16域
这样速度可以再快些，当然数据量相对会大些
其实说白了就是多加几位检验，加大码距

另外，LZ的图没看懂

只看该作者 · 2012-3-16 13:50

17# linjing
垂直检验？具体什么意思呢？

贴的这三张图，都是从射频模块过来的随机数据（保存在m1_cmd_buf中的，且包括CRC的两个字节都是），可是这些随机数据中，总能逮到个别的段落符合CRC16。
就这个意思。

多谢大家回帖，有点领悟，这似乎不是什么所谓的碰撞，xwj点醒了，多谢多谢。