Deciphering a checksum/CRC

Question

I'm trying to figure out an error-check on the following data streams. The data comes from a commercial remote control for programming electric radiator heaters.

I have extensively researched most IR protocols (RC5, NEC etc), and from what I can tell it doesn't fit any. I can't confirm that it isn't IrDA, however.

The hardware I am using is a standard Vishay IR 38kHz receiver connected up to an old PC running WinLIRC, so I can see the raw pulse/space train, and have confirmed through various tests/adjustments the basic parameters in the config (such as time stamp which has a resolution down to seconds), that the data comes out the IR as 10-bit, one start bit, 8-bit data byte, and a stop-bit. Then I have inverted the data bytes, bit-swapped MSB-LSB to get me to a point which stacks up with the programming schedule.

My one sticking point is the last byte which I believe is the error-check, I know this because I have set up a test rig to send the data with a different error check and the heater doesn't accept it, and with a correct value as recorded is accepted.

Below is the data stream, followed by 2 more iterations, but with the time stamp advancing by 1 second in each case. I can see some mathematical similarities between the error-checks but I have tried all 8-bit CRC/checksum XOR, added, subtracted, etc decoding methods and also used reveng which hasn't yielded an answer.

Any help on this is much appreciated!

1ST ROUND OF DATA

BINARY HEX DECIMAL NOTES

11111111 FF 255
00000000 0 0
00001111 F 15
10110011 B3 179
01001100 4C 76
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000011 3 3
00000010 2 2 HOURS
00010010 12 18 MINUTES
00000000 0 0 SECONDS
01101011 6B 107 CRC CHECK?

2ND ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: -

00000001 1 1 SECONDS
00110101 35 53 CRC CHECK?

3RD ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: -

00000010 2 2 SECONDS 11010111 D7 215 CRC CHECK?

4th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: -

00000011 3 3 SECONDS
10001001 89 137 CRC CHECK?

5th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: -

00000100 4 4 SECONDS
00001010 A 10 CRC CHECK?

6th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: -

00000101 5 5 SECONDS
01010100 54 84 CRC CHECK?

7TH ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP MINUTES: -

00011000 18 24 MINUTES
00001101 D 13 SECONDS
01110001 71 113 CRC CHECK?

8TH ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP MINUTES: -

00011011 1B 27 MINUTES
00111011 3B 59 SECONDS
01000111 47 71 CRC CHECK?

Need more data. Please provide at least ten samples. If you can get some for different length messages, that would be useful as well. — Mark Adler
Hi, here is some more data, I've included the same above for ease:- — AaronT
4th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: - 00000011 3 3 SECONDS 10001001 89 137 CRC CHECK? 5th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: - 00000100 4 4 SECONDS 00001010 A 10 CRC CHECK? 6th ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP SECONDS: - 00000101 5 5 SECONDS 01010100 54 84 CRC CHECK? — AaronT
7TH ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP MINUTES: - 00011000 18 24 MINUTES 00001101 D 13 SECONDS 01110001 71 113 CRC CHECK? 8TH ROUND OF DATA SAME AS 1ST ROUND UPTO THE TIME STAMP MINUTES: - 00011011 1B 27 MINUTES 00111011 3B 59 SECONDS 01000111 47 71 CRC CHECK? — AaronT
not sure how to add a bigger comment, so I've broken the data up, and also the formatting is wrong now....perhaps I should start another post? — AaronT

regregex regregex · Accepted Answer · 2017-12-01T16:22:58

CRC RevEng finds a solution to the original problem set readily. This is a Bash command line for compactness:-

reveng -w 8 -s ff000fb34c00000003000000000003000000000003000000000003000000\
00000300000000000300000000000300000302\
{12006b,120135,1202d7,120389,12040a,120554,180d71,1b3b47}

which returns:-

width=8  poly=0x31  init=0xa5  refin=true  refout=true  xorout=0x00  check=0x67  residue=0x00  name=(none)

As all the streams are the same length, CRC RevEng cannot compute both Init and Xorout. xorout=0x00 is a guess which forces init=0xa5 so as to correctly compute the streams in the problem set. Streams of length other than 52 bytes will need both parameters, and finding one will give you the means to calculate them.

poly=0x31 appears only once in the Catalogue under CRC-8/MAXIM, which is also reflected but has init=0x00; if this is indeed the algorithm in use, then init=0xa5 is an image of bytes fed into the algorithm that shouldn't be (i.e. the first n characters would not be fed into CRC-8/MAXIM); unfortunately I couldn't find any prefix of the data streams that equated to an initial value of 0xa5.

If you require code to calculate these CRCs, other packages are available that will convert the Rocksoft™ model output by CRC RevEng into C, for instance pycrc or Mark Adler's crcany.

Deciphering a checksum/CRC

2 Answers