Checksum field within IR protocol

Question

I am trying to reverse engineer the IR protocol for my air conditioner (GREE - remote control YAP1FF) and with the data I found online and a lot of testing with a IR receiver there is only one field I still cannot calculate.

I am pasting some different messages and the field I am interested in is 8 bit long, delimited by brackets.

The values within m1 have no influence on the field. The field only has data when I set a time for automatically power on or to power off. The times are on m2.

m2:

• 11 bits = minutes remaining until power on time (1 to 1440)
• 1 bit = '1'
• 11 bits = minutes remaining until power off time (1 to 1440)
• 1 bit = '0'
• 1 bit = '0' if power off function is disabled, 1 if enabled
• 1 bit = '0' if power on function is disabled, 1 if enabled
• 2 bits = '00'
• 4 bits = general checksum (m1 and m2 together). I have the formula for this checksum

All the fields are stored in reverse bit order (little endian?)

If the power on time is 1 to 14 minutes from current time the field is always 00010000; from 15 to 29 minutes it's 10010000; from 30 to 44 it's 00011000. It changes every 15 minutes so I guess the 4 first bits are not being used to calculate it.

m1=100100001010[00011000]011000000110010 m2=10011001101110101100000011001110
m1=100000000110[00110010]010000000110010 m2=00101001101100000000000001000111
m1=100000000110[10111100]010000000110010 m2=10001001101100000000000001001011
m1=100000000110[00111100]010000000110010 m2=10010110101100000000000001000101
m1=100000000110[10110100]010000000110010 m2=10101010101100000000000001000001
m1=100000000110[10110100]010000000110010 m2=11001010101100000000000001000001
m1=100000000110[10110100]010000000110010 m2=00011100101100000000000001000110
m1=100000000110[00110100]010000000110010 m2=11101100101100000000000001000110
m1=100000000110[00110010]010000000110010 m2=11111001101100000000000001000111
m1=100100000010[00011000]011000000110010 m2=01111001101101011100000011001101
m1=100000000110[00010000]010000000110010 m2=10000000000100000000000001001000
m1=100100000010[10011000]011000000110010 m2=00001000000100110010000011001010
m1=100000000110[10010000]010000000110010 m2=00001000000100000000000001000100
m1=100100000010[10011000]011000000110010 m2=10010100000110100110000011001111
m1=100000000110[00011000]010000000110010 m2=01110100000100000000000001000010
m1=100100000010[00010100]011000000110010 m2=11100010000111000001000011000000
m1=100000000110[10011000]010000000110010 m2=00110010000100000000000001000110
m1=100100000010[10010100]011000000110010 m2=11000110000111111001000011000111
m1=100100000010[00010100]011000000110010 m2=01010110000100000000000001001111
m1=100100000010[00011100]011000000110010 m2=11000001000111111101000011001000
m1=100100000010[10010100]011000000110010 m2=00010001000100000000000001001000
m1=100100000010[10011100]011000000110010 m2=00010001000100100011000011000110
m1=100000000110[00010000]010000000110010 m2=00000000000101000000000010001100
m1=100000000110[10010000]010000000110010 m2=00000000000110001000000010000100

If both power on and power off functions are disabled, the field will always be 00000000

Answer 1

I don't have an actual answer but this grew too long to be a comment so I'm adding it down here.

I'm sure you've noticed that the bit-patterns of that byte you're interested in aren't particularly random. Three are fixed either at 0 or 1, and among the others there are few that actually look evenly distributed the way you'd expect with an effective checksum. Given the pattern you observed in the m2 to use 1 by itself to act as a separator it seems likely that the 4th bit (or 3rd if we're starting at 0) is one such separator.

It might be useful to do some correlation analysis (a bit like differential cryptanalysis) to determine which potential input bits in m2 are well-correlated with some of those more random seeming output bits in your byte.

Additionally, if you use the idea I suggested above of using the 1 as a separator then you're actually just looking at two distinct values where the first is only ever 0, 1, 4, and 5 and the second is 0-4. Maybe using those values while looking at the data in m2 will be useful.