История изменений

Буду дальше анализировать посылки датчиков - у меня их 3, по 11 пакетов обмена на каждый датчик, может быть удастся понять как закодирована контрольная сумма, о которой Вы сказали.

Мне кажется, что закодирована она хитро. Ну, если только мы считаем, что последнее поле после 3B — действительно контрольная сумма. Я предполагаю, что это так, потому что она каким-то слишком непредсказуемым образом меняется. И вот пример почти одинаковых посылок, а последнее поле, то пять символов, то четыре:

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D

Отличие в одном байте у посылок. И странно, что то четыре символа, то пять. Однако я заметил одну особенность по тем данным, что ты изложил. Других нет. Особенность такая: последнее поле не содержит hex-символов A, B, C, D, E, F, а только десятичные цифры. Я предполагаю, что контрольная сумма в последнем поле записана в ДЕСЯТИЧНОМ виде в ASCII.

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
                                 6  9  5  2 -> 1B28 hex
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
                                 6  0  2  0  0 -> EB28 hex
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D
                                 3  1  5  2  9 -> 7B29 hex

Я в твоих данных не увидел ни одного символа A-F в последнем поле. Выше показано, что если перевести это число в hex, то будет число из двух байт (проверь встречаются когда-нибудь числа выше 65535?). Моя гипотеза, что это CRC16, но записанная в десятичном формате. Значит надо проверить, по каким данным она считается.

Она может считаться по сырым данным до перекодирования в ASCII, она может считаться по данным после перекодирования в ASCII, она может считаться без учета заголовка или без учета части заголовка. Она считается наверняка без учета OD. В общем, тут надо взять любой онлайн-калькулятор контрольных сумм или программу написать и тупо проверять гипотезу.

Буду дальше анализировать посылки датчиков - у меня их 3, по 11 пакетов обмена на каждый датчик, может быть удастся понять как закодирована контрольная сумма, о которой Вы сказали.

Мне кажется, что закодирована она хитро. Ну, если только мы считаем, что последнее поле после 3B — действительно контрольная сумма. Я предполагаю, что это так, потому что она каким-то слишком непредсказуемым образом меняется. И вот пример почти одинаковых посылок, а последнее поле, то пять символов, то четыре:

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D

Отличие в одном байте у посылок. И странно, что то четыре символа, то пять. Однако я заметил одну особенность по тем данным, что ты изложил. Других нет. Особенность такая: последнее поле не содержит hex-символов A, B, C, D, E, F, а только десятичные цифры. Я предполагаю, что контрольная сумма в последнем поле записана в ДЕСЯТИЧНОМ виде в ASCII.

07: FF 21 32 34 31 3B 30 31 3B  36 39 35 32 0D
                                 6  9  5  2 -> 1B28 hex
09: FF 21 32 34 31 3B 30 32 3B  36 30 32 30 30 0D
                                 6  0  2  0  0 -> EB28 hex
08: FF 21 32 34 31 3B 30 33 3B  33 31 35 32 39 0D
                                 3  1  5  2  9 -> 7B29 hex

Я в твоих данных не увидел ни одного символа A-F в последнем поле. Выше показано, что если перевести это число в hex, то будет число из двух байт (проверь встречаются когда-нибудь числа выше 65535?). Моя гипотеза, что это CRC16, но записанная в десятичном формате. Значит надо проверить, по каким данным она считается.