Контрольная СУММА, Какой вид выбрать ? Опции

[Kaibara]

Добрый день !!!
У меня вопрос ,как правильно прописать контрольную сумму?
В описании протокола :
“The destination address is included in order to prepare a future enhanced version of the protocol.
For heat meters the destination address is 3Fh. The logger top module use 7Fh and the logger base module use BFh.
Included in the data link layer is a CRC with reference to the CCITT-standard using the polynomial 1021h.
Only deviation from the standard is the initial value, which is 0000h instead of FFFFh.
The CRC result is calculated for destination address, CID and data. CRC is transmitted with MSByte first and LSByte last.”
Из следует что CRC-16 CCITT, Poly: 0x1021 x^16 + x^12 + x^5 + 1, Init : 0x0000 Revert: false XorOut: 0xFFFF/ “Это я правильно понимаю?”
Контроллер понимает вот такие виды CCITT :
CRC &endash; CCITT 1: контрольная сумма, получаемая из 16-битовых челых чисел, инициализируемых на нулевую величину.
CRC &endash; CCITT 2:: 16-битовое целое число, инициализируемое на величину 0xFFFF.
CRC &endash; CCITT 3: контрольная сумма, получаемая из байтов, инициализируемых на нулевую величину.
CRC &endash; CCITT 4: байты, инициализируемые на величину 0xFFFF.
Использую 1 , в итоге в порт уходит :
80 3F 02 (33 46) 0D а не нужные мне 80 3F 02 (35 E9) 0D
C Другими пробовал тоже не то значение =(
Вывод : я не знаю что делать и где искать правду =(

[Kaibara]

Добрый день !!!
У меня вопрос ,как правильно прописать контрольную сумму?
В описании протокола :
“The destination address is included in order to prepare a future enhanced version of the protocol.
For heat meters the destination address is 3Fh. The logger top module use 7Fh and the logger base module use BFh.
Included in the data link layer is a CRC with reference to the CCITT-standard using the polynomial 1021h.
Only deviation from the standard is the initial value, which is 0000h instead of FFFFh.
The CRC result is calculated for destination address, CID and data. CRC is transmitted with MSByte first and LSByte last.”
Из следует что CRC-16 CCITT, Poly: 0x1021 x^16 + x^12 + x^5 + 1, Init : 0x0000 Revert: false XorOut: 0xFFFF/ “Это я правильно понимаю?”
Контроллер понимает вот такие виды CCITT :
CRC &endash; CCITT 1: контрольная сумма, получаемая из 16-битовых челых чисел, инициализируемых на нулевую величину.
CRC &endash; CCITT 2:: 16-битовое целое число, инициализируемое на величину 0xFFFF.
CRC &endash; CCITT 3: контрольная сумма, получаемая из байтов, инициализируемых на нулевую величину.
CRC &endash; CCITT 4: байты, инициализируемые на величину 0xFFFF.
Использую 1 , в итоге в порт уходит :
80 3F 02 (33 46) 0D а не нужные мне 80 3F 02 (35 E9) 0D
C Другими пробовал тоже не то значение =(
Вывод : я не знаю что делать и где искать правду =(

[shylock]

CRC считается для "80 3F 02"? Это и есть "destination address, CID and data"? Почему адрес вторым байтом?

[GYUR22]

найдете разные реализации и посчитайте ими что совпадет с примером там и счастье (я так делал)
посчитайте сразных мест и байты иногда верхний нижний меняют

[Kaibara]

CRC считается для "80 3F 02"? Это и есть "destination address, CID and data"? Почему адрес вторым байтом?

80 это стартовый
3F адрес
02 CID
33 46 CRC
0D Стоповый

Тут считается для сида и адреса , тк данные жестко забиты в памяти .
Для считывания изменяющихся данных формат немножко отличается
10 01 00 80 CID and data

3F 10 01 00 80 Destination address added

3F 10 01 00 80 D4 08 CRC added

3F 10 01 00 1B 7F D4 08 Byte stuffing

80 3F 10 01 00 1B 7F D4 08 0D Start and stop byte added


Сообщение отредактировал Kaibara - 2.4.2010, 6:48

[Kaibara]

GYUR22 . меня больше смущает то что в поле формат есть выбор , и не самый большой (Decimal ASCII, Hex as ASCII, Binary) . ASCII ?!

[shylock]

То есть в приведённом примере CRC должен считаться от 3F 02 (без стартового байта)?

[Kaibara]

То есть в приведённом примере CRC должен считаться от 3F 02 (без стартового байта)?
да

[Kaibara]

Ну в общем ,Контроллер Unitronics v570. ПО можно взять на сайте VisiLogic.
Вот думаю в порт посылать жестко прописанный запрос ,а принимать по стартовому и стоповому ,потом уже в самом контроллере разбивать и считать .Только еще не знаю как это правильно сделать и какая при этом будет скорость.

[GYUR22]

че за протокол то?

[Kaibara]

KMP Kamstrup Heat Meter Protocol

Прикрепленные файлы

 5512447_M1_GB.pdf ( 301,32 килобайт ) Кол-во скачиваний: 55

 

[GYUR22]

насколько я понял crc считается до байт стаффинга (замены символов) и для всей посылки- включая адрес, перед добавление стартового и конечного байтов (80 и 0D)
отличие CRC от стандарного в начальной инициализации -0000h (вмесо FFFFh)
смотрю уже на который тепловой счетчик и меня не покидает чуство что его делали если не извращенцы то очень странные люди - как то все неудобно (через жо...у)

[Kaibara]

Ну , телефон и меж город мне в руки =)

[GYUR22]

?

[Kaibara]

Hex as ASCII вот в этом дело .Протокол КМП нормальный , все понятно. В самом контроллере контрольная сумма считается даже правильно ,но в порт выбрасывает не 2' HEX а 4' ASCII .