Figure out how checksums are calculated for video sync mode

[subraizada3]

The code to send video sync data is implemented. However, each message sent to the monitor includes a checksum, and we need to figure out how to compute the checksum.

For the 'fixed' commands like "turn lighting on", the checksums were captured from the USB logs. For example, the turn on command is always the same:

5343cf02020100 de 4544

Where de is the checksum. It never changes since the command is constant.

However, the video sync commands are dynamically generated and we need to be able to calculate the correct checksum to put it into the command. Otherwise the monitor ignores the data we're sending.

I captured a few minutes of USB video sync transactions from the LG control application. I can 're-play' the captured video sync through the library, since the captured transactions have the checksums in them. But we can't send new data that we create.

I've uploaded some files which contain various commands and their checksums. We need to analyze these and figure out how the checksums are computed, so that we can generate correct checksums for new video sync data that we create.

The files are:

• general.txt: This contains various short HID messages and their checksums
• setcolor.txt: This contains the 176 short HID messages to set slot colors, and their checksums. I manually captured all 176 of these as a workaround for not having the checksum calculation details.
• videosync.txt: This contains all the video sync data messages captured from a few minutes of video sync usage with the LG control application.

---

Some details that may help with analyzing this data:

Every single USB HID message sent to the monitor follows the same format:

• It starts with 2.5 bytes (5 nibbles): 0x5343c
• There are a few command bytes and command data bytes. The command is always N.5 bytes (an odd number of nibbles) to balance out the extra nibble in the 0x5343c header. The data is always a whole number of bytes.
• There is a one-byte checksum.
• '0x4544' appears at the end of the message.
• The message is padded to 64 bytes with trailing zeroes.

For example, the HID message to switch to dynamic color mode is:

5343ca02020306df4544 followed by the zero padding

It can be broken down into:

• 5343c: header
• a02020306: command and command data
• df: checksum
• 4544: footer

The video sync data messages are like this, but the "command data" part is much, much longer. These messages follow the format:

5343c1029100ff0000ff0000ff0000...ff0000ff0000ff0000424544

That example will set the ring of LEDs to fully red.

The message can be broken down to:

• 5343c: header
• 1029100: command
• ff0000 repeated 48 times: command data, set all LEDs to red
• 42: checksum
• 4544: footer

[koshisan]

Very exited to see this happening :) You probably did google https://reveng.sourceforge.io/ yourself by this point? ;)

[subraizada3]

You probably did google https://reveng.sourceforge.io/ yourself by this point? ;)

I did suspect it might be CRC (because what else would it be?) but I did not google :)

Well, that was pretty easy with reveng. The parameters it found are:

width=8 poly=0x01 init=0x00 xorout=0x00 check=0x31

./reveng -c -w8 -p1 -i0 -x0 {bytes} correctly calculates CRCs for messages outside the 'training set' I fed it to reverse.

[subraizada3]

Resolved with https://github.com/subraizada3/27gn950controller/commit/c5be3ff553c286c1f0bbcf4f3b5b128d763c6c15