Помогите с контрольной суммой, ПД308 от Тензо-М

Здравствуйте. Есть прибор ПД308 от Тензо-М, он непрерывно шлет посылку 22 байта: 255 3 204 151 15 15 16 0 0 0 0 0 0 0 0 0 0 0 0 70 255 255,(1 - разделитель, 2 - адрес, 3 - команда, 4-19 - коды ацп, 20 -crc, 21-22 - разделитель, много нулей это потому что подключены 2 датчика из 8) пытаюсь рассчитывать CRC для проверки целостности пакетов. вот мой код на C# (писал по примеру который есть на сайте Тензо-М да и в этой ветке он выше описан с пометкой рабочий):

private static int getCRC(byte[] InputData, int BytesNumber, int Offset) { int i, j;

        byte Data, CrcCode = 0, Polinom = 105; 

        for (i = Offset; i < BytesNumber + Offset; i++)
        {
            Data = InputData[i];

            
            for (j = 0; j < 8; j++)
            {
                if ((CrcCode & 128) >  0)
                {
                    CrcCode = (byte)(CrcCode * 2);

                    if ((Data & 128) > 0)
                    {
                        CrcCode++;
                    }
                    CrcCode = (byte)(CrcCode ^ Polinom);
                }
                else 
                {
                    CrcCode = (byte)(CrcCode * 2);
                    if ((Data & 128) > 0)
                    {
                        CrcCode++;
                    }
                }
                
                Data = (byte)(Data * 2);
            }  
        }
           
        return CrcCode;
    } 

В функцию передаю буфер байт без разделителей и байта контрольной суммы то есть: 3 204 151 15 15 16 0 0 0 0 0 0 0 0 0 0 0 0

У меня получается: 136

Товарищи, второй день сижу, что я делаю не так так?

Я проверил своим кодом на C - у меня тоже 136 получается.

Возможно у тебя другой полином.

А байты точно такие он шлет? Может ошибка где?

эх молодежжжжжжжжжжж, опять весы

def Crc_8(n, poly, crc = 0):
    n = n ^ crc
    for bitnumber in range(0,8):
        if  n & 0x80:
            n = ( n << 1) ^ poly
        else:
            n = n << 1
    return n & 0xFF
  
message = [0xcc, 0xc3, 0x0f, 0x3f, 0x12, 0x6c, 0x26, 0xe0, 0x34, 0x12, 0x36, 0x72, 0x2e, 0xb1, 0x1c, 0xfa, 0x19]
crc = 0
for i in message:
    crc = Crc_8(n = i, poly = 0x69, crc = crc )
print(hex(crc))

написано как решение алгоритма в лоб, обычно делают на таблицах, если места много

только не говори что не знаешь как проверить контрошку :) я этого не переживу

Извини, а ты вообще о чем?

Вот в целом, на какой вопрос ты сейчас отвечал?

И почему ты решил, что я чего-то там не могу проверить? А?

да, забей, по диагонали прочел

Погоди, тут интересная вещь.

Твой код правильно считает контрольную сумму на пакете killla !

То есть то что мы в самом конце обсуждаем.

А «мой» код, считает неправильно, так же как и его код на C# выше. Но - правильно на пакетах от моих весов.

Твой код неправильно считает на моих пакетах.

Где-то то тут подвох.

Вот что у меня

uint8_t crc8(uint8_t input, uint8_t crc)
{
  for (int i=0; i<8; ++i) {
    int major = (crc & 0x80);
    crc <<= 1;
    if ((input & (1<<(7-i)))!=0)
      crc |= 1;
    if (major)
      crc ^= 0x69;
  }
  return crc;
}

насколько помню у разных весов которые я видел контрошка иногда считается только с данных, но не с управляющих символов. хотя на мой взгляд это косяк проектирования

иными словами, откидываем старт стоп пакета, считаем контрошку всей посылки либо только данных, но не управляек

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

3 204 146 16 1 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=101 | my_crc= 204

3 204 146 16 0 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=154 | my_crc= 9

3 204 146 16 255 254 16 0 0 0 0 0 0 0 0 0 0 0 PD_crc=0 | my_crc= 102

3 204 146 16 254 16 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=48 | my_crc= 143

3 204 146 16 254 16 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=48 | my_crc= 143

3 204 147 16 254 16 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=88 | my_crc= 169

3 204 148 16 255 254 16 0 0 0 0 0 0 0 0 0 0 0 PD_crc=0 | my_crc= 178

3 204 149 16 0 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=235 | my_crc= 251

3 204 149 16 2 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=124 | my_crc= 24

3 204 150 16 4 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=20 | my_crc= 62

3 204 150 16 6 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=131 | my_crc= 221

3 204 149 16 9 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=154 | my_crc= 9

3 204 148 16 11 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=101 | my_crc= 204

3 204 148 16 11 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=101 | my_crc= 204

3 204 147 16 12 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=59 | my_crc= 183

3 204 146 16 11 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=124 | my_crc= 24

3 204 146 16 10 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=131 | my_crc= 221

3 204 145 16 8 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=172 | my_crc= 84

3 204 145 16 6 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=242 | my_crc= 47

3 204 144 16 4 17 0 0 0 0 0 0 0 0 0 0 0 0 PD_crc=13 | my_crc= 234

Ббблиин, ты прав, я - идиот. Можешь начинать не переживать :)))

Проблема была в том, что в «мою» функцию надо подставлять данные + 0 вместо контрольной суммы. Тогда все совпадает. У себя я именно так считаю, а тут сегодня я взял пакет killla и подставил без этого дополнительного байта.

А твоя функция считает без этого.

То есть, killla, ты просто добавь в конец еще один 0 байт, и попробуй, все должно работать. Получается 70.

Да, это понятно - тут считается только на данных, без управляющих символов.

хм, 0 - знакоместо для crc?

если да, то плохие новости, это не очень правильно :) например при без буферной реализации. хотя наверное это не очень актуально, моя функция тоже не будет работать с битстримом, надо переписывать

если да, то плохие новости, это не очень правильно :)

Согласен. Ну будут проблемы - переделаю.

Спасибо огромное!!! Все работает!!! Ураааааааа!!!!

Спасибо Morin что пнул в нужную сторону.