Checksum calculation and bitstream insights

[wingspinner]

Hello, This isn't an "issue" but couldn't find a way to email you. I was hoping to learn how you came up with the checksum calculation. I'm at [email protected] if you'd prefer an email response. Thx, Ron

[skypeachblue]

Hi, I really appreciate your interest :)

Basically I collected a bunch of signals and noticed that the checksum changes in a predictable way.

For example:

state and speed stay the same, 1 bit flip in temperature => exactly 1 bit flip appears in the checksum as well

From there it was really just trial and error.
My first guess was that the state, speed and temperature were simply XORed together as that would be an easy straight-forward way to calculate a checksum. And that is pretty much the case here, some bits are just negated.

Hope this helps!

[wingspinner]

Hello, I was working on this very same problem about a year ago but put it on the back burner when I just decided to design a complete new board that uses more robust motor control components and has wifi and BT along with my own software. However I did get to where you have so kindly shared except for the checksum. I started looking at it again when I saw your git repository and how you got the checksum - great work!

One thing I determined that the raw encoding is simple NZRI-L However, the Arduino libraries deliver it inverted. Bit reversal was just a decision to send LSB first by the original software developers of the MaxxAir code. However I didn't know that until I experimented because I'd been asking myself the question since I began on this as to why the speed and temp values have some pattern but it's not clear what it was. Something I determined just recently though is that not only are the bits are all inverted as it comes from the IR Libraries. The second thing I determined is that not only are they inverted but msb-lsb the values are bit reversed so if you take your speed values and invert then reverse the bit order (in other words they are sent LSbit first they become 10 -100 and if you do the same to your temp values you get the temp in Fahrenheit which enables software not to have to have a translation table as your software shows. I'm guessing the status is also inverted-reversed.

I'm wondering what that does to the checksum algorithm. Could be they simply calculate the checksum after they've inverted and reversed them but I doubt it because if one is generating data to send one would normally just use the data as it is to calculate the checksum and the fact that data ends up being inverted-reversed is just an artifact of how it's transmitted. Any thoughts?

Cheers,
Ron

[skypeachblue]

Wow, thank you! Super interesting.
I've certainly been wondering about the speed and temp values, as there seems to be a pattern but I haven't been able to make sense of it.
I'm on vacation right now but I will look into this and get back to you.
Btw, I've added an email address to my profile ([email protected]) if you'd like to email me, but this discussion is probably interesting to other people as well.

Cheers,
Julia

[wingspinner]

Julia,

Have a wonderful vacation. I hope to hear from you when you return.

Best regards- Ron

[skypeachblue]

Hi Ron,

Thank you! I'm going to add the information about the bitstream being inverted and reversed to my code and the readme.

I've noticed that if you take the part of the signal I've marked here in red:

and XOR that with the state, temp, and speed you get the checksum!
I think this makes more sense than my theory of some bits being inverted for no reason.
It's the last 7 bits of the part I called 'unknown' in my code: https://github.com/skypeachblue/maxxfan-reversing/blob/229bd909d0d6fbcc71c3624f24ec979c6a059c23/generate.py#L138C40-L138C47

This suggests that that part of the signal is significant in some way. I wonder if you have any insights about that part, or any of the other bits that seem to always stay the same?