Can you add new CRC16 method calculate for "Massa-K" device in your repo?

[DamianMorozov]

The CRC16 in my case calculated for bytes[5..last-2].
For example, CRC16 for request "F8 55 CE 01 00 23 23 00" will be "23 00".
For example, CRC16 for response "F8 55 CE 0D 00 24 00 00 00 00 01 01 00 01 00 00 00 00 FC 23" will be "FC 23".

[nullfx]

I'll try to have a look at it this week. Its been a busy week for me last week.

To be honest, I don't recognize the algorithm off the top of my head. It looks like like a CCITT but its not. I think it may just be a custom CRC algorithm used by the weight scale.

Is the scale an RS232/485 (or emulated RS232 over USB) device? I've worked with a number of different devices over the years, so I'm just curious. They may have created their own CRC based on communication errors their device might be prone to, rather than using a standard CRC checksum.

a good site to validate payloads with the CRC you're expecting (when trying to determine the type of CRC you need if you don't know that information) is this site: https://crccalc.com/ but none of the ones listed there produce 0x2300 or 0x0023 from 0xF8 0x55 0xCE 0x01 0x00 0x23 (assuming the last 2 bytes were the CRC) or 0xFC23 / 0x23FC from 0xF8 0x55 0xCE 0x0D 0x00 0x24 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 (again, removing the
last 2 bytes assuming they are the CRC)

If it is a proprietary checksum calculation I'm not sure how beneficial it would be in adding it in with the others. Hopefully i can figure out the algorithm and help to add support for it.

---

Я постараюсь взглянуть на него на этой неделе. На прошлой неделе у меня была напряженная неделя.

Честно говоря, я не узнаю алгоритм с головы до ног. Он выглядит как CCITT, но это не так. Я думаю, что это может быть просто пользовательский алгоритм CRC, используемый весами.

Являются ли весы устройством RS232/485 (или эмулированным RS232 через USB)? Я работал с различными устройствами в течение многих лет, поэтому мне просто интересно. Возможно, они создали свой собственный CRC на основе ошибок связи, к которым может быть склонно их устройство, вместо того чтобы использовать стандартную контрольную сумму CRC.

Хороший сайт для проверки полезной нагрузки с ожидаемой CRC (при попытке определить тип CRC, который вам нужен, если вы не знаете этой информации) - этот сайт: https://crccalc.com/, но ни один из перечисленных там не выдает 0x2300 или 0x0023 из 0xF8 0x55 0xCE 0x01 0x00 0x23 (предполагая, что последние 2 байта являются CRC) или 0xFC23 / 0x23FC из 0xF8 0x55 0xCE 0x0D 0x00 0x24 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 (опять же, удаляя последние 2 байта, предполагая, что они являются CRC).
последние 2 байта, предполагая, что они являются CRC).

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

[DamianMorozov]

I'll try to describe my case.
The CRC16 in my case calculated for bytes[5..last-2].
First part: 1..3 bytes - it's head of packet "F8 55 CE".
Second part: 4..5 bytes - it's length of packet.
Third part: 5..last-2 bytes - it's packet.
Fourth part: last-2..last bytes - it's CRC16 Massa-K.

For example, CRC16 for request "F8 55 CE 01 00 23 23 00" will be "23 00". This means that CRC16 was calculated for "23".
For example, CRC16 for response "F8 55 CE 0D 00 24 00 00 00 00 01 01 00 01 00 00 00 00 FC 23" will be "FC 23". This means that CRC16 was calculated for "24 00 00 00 00 01 01 00 01 00 00 00 00".