[=AK= 10]

Я вычисляю CRC-16-CCITT для некого массива N байт, big endian. После этого приписываю в конец этого массива два байта вычисленного CRC, сначала MSB, потом LSB, и посылаю массив с добавленным CRC приемнику.

Приемник принимает массив, включая два байта CRC, и вычисляет CRC всего принятого массива.

Можно ли утверждать, что, при отсутствии искажений и помех в канале, приемник, в результате вычисления CRC полного массива (т.е. включая два байта CRC), всегда будет получать значение 0x0000? Хотелось бы узнать математически достоверное доказательство, всегда ли результатом  будет 0 или нет.

[Arlleex 131]

16 минут назад, =AK= сказал:

Можно ли утверждать, что, при отсутствии искажений и помех в канале, приемник, в результате вычисления CRC полного массива (т.е. включая два байта CRC), всегда будет получать значение 0x0000? Хотелось бы узнать математически достоверное доказательство, всегда ли результатом  будет 0 или нет.

Возьмите ручку и на листочке нарисуйте цепочку XOR-элементов, образующих Ваш полином.

Возьмите начальное значение, равное вычисленному CRC по массиву.

Задвигайте побитово такое же значение - на последнем бите результат схлопнется в 0.

Хотя должно быть понятно и так, что X XOR X == 0.

 

Ну и ради прикола можете накидать программку, которая по 16 битам будет проверять все вариации начального значения и задвигаемого полуслова.

Это будет даже не математически, а практически выверенным поведением

[геннадий75 1]

Последний два байта также участвуют в подсчёте CRC , соответственно 0х0000 не получишь.

[Aleksandr Baranov 1]

CRC - это остаток от деления данных на полином. Вы это остаток добавляете к блоку данных и снова делите на тот же полином. Значит, вы получите ноль в остатке.

Изменено 16 июля, 2020 пользователем Aleksandr Baranov

[=AK= 10]

18 hours ago, Aleksandr Baranov said:

CRC - это остаток от деления данных на полином. Вы это остаток добавляете к блоку данных и снова делите не тот же полином. Значит, вы получте ноль в остатке.

Спасибо. Почитал английскую Википедию - все именно так и есть, и даже пример приведен.

The validity of a received message can easily be verified by performing the above calculation again, this time with the check value added instead of zeroes. The remainder should equal zero if there are no detectable errors.

11010011101100 100 <--- input with check value
1011               <--- divisor
01100011101100 100 <--- result
 1011              <--- divisor ...
00111011101100 100

......

00000000001110 100
          1011
00000000000101 100
           101 1
------------------
00000000000000 000 <--- remainder

 

[геннадий75 1]

Как то у вас всё просто . При добавлений двух байт в подсчёт CRC добавляется не одна операция XOR с полиномом а 16 .

И нули никогда не получишь . Проверяется легко в онлайн калькуляторах .

https://crccalc.com 

[andrew_b 14]

23 минуты назад, геннадий75 сказал:

При добавлений двух байт в подсчёт CRC

Не просто двух байт, а двух байт этой самой CRC. И не просто двух байт CRC-16, а сначала младший, а потом старший.

24 минуты назад, геннадий75 сказал:

И нули никогда не получишь

Получишь-получишь.

[=AK= 10]

9 minutes ago, andrew_b said:

Не просто двух байт, а двух байт этой самой CRC. И не просто двух байт CRC-16, а сначала младший, а потом старший.

И у меня в исходном посте, и в примере из Википедии первым идет старший бит, поэтому добавляется сначала старший байт, а потом младший.

 

50 minutes ago, геннадий75 said:

Как то у вас всё просто . При добавлений двух байт в подсчёт CRC добавляется не одна операция XOR с полиномом а 16 .

И нули никогда не получишь . Проверяется легко в онлайн калькуляторах .

https://crccalc.com 

Я проверил, получилось. Исходное число 0x123456789ABC после вычисления CRC-16/CCITT дало результат 0xA840. Приписав A840 в хвост исходного числа получаем в результате 0.