IRForum

Advanced IR Decoder & Analyzer - Arduino, ESP8266/ESP32/NodeMCU, Photon, PIC, RPi & MCUs
https://irforum.analysir.com/

Checksum headaches

https://irforum.analysir.com/viewtopic.php?t=1052

Page 1 of 1

Checksum headaches

Posted: Fri Mar 18, 2022 9:41 pm
by skydvrz
I have been struggling for the better part of a week trying to reverse engineer the checksum algorithm for a Blueridge mini-split heat-pump AC that uses a YB1FAF remote. The model number of the indoor unit is BMKH09-D3DNA2D/I. I get the impression that the Blueridge unit is rebadged - maybe a Gree?

I have all the IR control bits figured out, but the method by which the checksum is calculated escapes me. The Checksum Calculator shows nothing close.

I am using a custom ELECTROLUX67_134AC protocol (provided by Analysir support) in AnalysIR and a LearnIR USB dongle.

I really want to build IR signals dynamically instead of creating a bunch of RAW constants in my emulation code, but I can't do that without a calculated checksum.

I have attached an AnalysIR session with a broad range of buttons clicked / modes changed. The checksum seems to be held in the nybble at the right end of the hex value in LSBB mode, but I could be wrong.

Any ideas?

Temperatures are in Fahrenheit; h76 means heat 76F; c80 means Cool 80F.

Thanks in advance!

Kevin

Re: Checksum headaches

Posted: Sat Mar 19, 2022 5:14 pm
by AnalysIR
Unfortunately, have not been successful on this one for many years of trying.


Part of the reason is that it is 67 bits and not a multiple of 8 or 4 bits.

However, my best guess is
- using LSB8
- sum of nibbles excluding last nibble
- There seems to be some consistency with the 3rd bit of the nibble flipped or 0 or ignored.
- on some signals the checksum did not change (temp empty/blank/out etc. Suggests 1 nibble or byte is ignored
- similarly with the light on/off...so it may be that some bits are totally ignored
- also fan doesn't change checksum
- Summary..identify the nibbles that don't change the checksum and exclude them . Then see if it makes more sense



It looks like you best option is to send the variations from HEX stored in flash.

Looks like you already have 170 signals captured. Most people will only use a handful of options (in my experience)

Re: Checksum headaches

Posted: Mon Mar 21, 2022 12:37 pm
by skydvrz
Thanks for the ideas!

I actually have 5 of these mini-split ACs in my metal-building workshop (it gets very hot here in Florida). My shop office temp is frequently at 32C. The main shop area gets up to 38C at times and takes the better part of an hour to cool down with the AC going full blast. You might say that I am highly motivated to make this work :-)

My application is a Arduino hardware/software bridge between my home automation controller, smart thermostats and Alexa.

You are correct that only a few of the signals are required. However, my goal is to create an open source driver for this protocol similar to the other ones covered by IRRemote.

Re: Checksum headaches

Posted: Sat May 07, 2022 11:05 pm
by chuckindixon
Appears that Blueridge heat pumps are manufactured by Midea, a huge Chinese company whose heat pumps are sold under many names.

Here's a post by a guy who cracked the checksum for a Senville unit (also apparently by Midea).

https://www.eevblog.com/forum/projects/ ... -checksum/
His project code is at https://github.com/kpishere/homie_heatPump

Re: Checksum headaches

Posted: Tue May 10, 2022 3:58 pm
by AnalysIR
@chuckindixon
I checked the link out and it does not seem to work for me. We have already used techniques like this and more using AnalysIR's built-in reverse engineering tool and checksum calculator, without success.......so far!

Based on the signals posted, some of the bytes/nibbles/bits changing don't result in in any checksum change....which suggests that some bytes/nibbles/bits are not included in the checksum calculation, which makes it even more challenging.

Re: Checksum headaches

Posted: Tue May 10, 2022 4:24 pm
by skydvrz
The hex format shown in the link seems to be different than what I have seen using AnalysIR. My guess is that if my AC unit is indeed a re-branded Midea unit then they are using some other bit map/protocol for the Blueridge brand than the one shown in the link.

My solution was to make a couple of heat/cooling lookup tables with raw hex (that includes pre-calculated checksums gleaned from AnalysIR runs). I wrote an ESP8266 Arduino algorithm to read in a row of hex and send it out to an IR LED using the correct timing. This seems to work well, but sadly I can't control AC features other than the temperature, mode and on/off.

Code: Select all

unsigned char OffCommands[9] = { 0x82, 0xE0, 0x04, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x00 }; // off

// all temperatures in Fahernheit

unsigned char HeatCommands[][9] =
{
		{ 0x32, 0x00, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x00 }, // h61
		{ 0x32, 0x80, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x80 }, // h62
		{ 0x32, 0x80, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xA0 }, // h63
		{ 0x32, 0x40, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x40 }, // h64
		{ 0x32, 0x40, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x60 }, // h65
		{ 0x32, 0xC0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xC0 }, // h66
		{ 0x32, 0xC0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xE0 }, // h67
		{ 0x32, 0x20, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x20 }, // h68
		{ 0x32, 0xA0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xA0 }, // h69
		{ 0x32, 0xA0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x90 }, // h70
		{ 0x32, 0x60, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x60 }, // h71
		{ 0x32, 0x60, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x50 }, // h72
		{ 0x32, 0xE0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xE0 }, // h73
		{ 0x32, 0xE0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xD0 }, // h74
		{ 0x32, 0x10, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x10 }, // h75
		{ 0x32, 0x10, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x30 }, // h76
		{ 0x32, 0x90, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x90 }, // h77
		{ 0x32, 0x50, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x50 }, // h78
		{ 0x32, 0x50, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x70 }, // h79
		{ 0x32, 0xD0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xD0 }, // h80
		{ 0x32, 0xD0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xF0 }, // h81
		{ 0x32, 0x30, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x30 }, // h82
		{ 0x32, 0x30, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x00 }, // h83
		{ 0x32, 0xB0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xB0 }, // h84
		{ 0x32, 0xB0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x80 }, // h85
		{ 0x32, 0x70, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x70 }  // h86
};

unsigned char CoolCommands[][9] =
{
		{ 0x92, 0x00, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xB0 }, // c61
		{ 0x92, 0x80, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x70 }, // c62
		{ 0x92, 0x80, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x40 }, // c63
		{ 0x92, 0x40, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xF0 }, // c64
		{ 0x92, 0x40, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xC0 }, // c65
		{ 0x92, 0xC0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x00 }, // c66
		{ 0x92, 0xC0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x20 }, // c67
		{ 0x92, 0x20, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x80 }, // c68
		{ 0x92, 0xA0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x40 }, // c69
		{ 0x92, 0xA0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x60 }, // c70
		{ 0x92, 0x60, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xC0 }, // c71
		{ 0x92, 0x60, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xE0 }, // c72
		{ 0x92, 0xE0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x20 }, // c73
		{ 0x92, 0xE0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x10 }, // c74
		{ 0x92, 0x10, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xA0 }, // c75
		{ 0x92, 0x10, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x90 }, // c76
		{ 0x92, 0x90, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x60 }, // c77
		{ 0x92, 0x50, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xE0 }, // c78
		{ 0x92, 0x50, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xD0 }, // c79
		{ 0x92, 0xD0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x10 }, // c80
		{ 0x92, 0xD0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x30 }, // c81
		{ 0x92, 0x30, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x90 }, // c82
		{ 0x92, 0x30, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0xB0 }, // c83
		{ 0x92, 0xB0, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0x50 }, // c84
		{ 0x92, 0xB0, 0x06, 0x3A, 0x58, 0x0C, 0x40, 0x00, 0x70 }, // c85
		{ 0x92, 0x70, 0x06, 0x1A, 0x58, 0x0C, 0x40, 0x00, 0xD0 }  // c86
};

Re: Checksum headaches

Posted: Sun May 15, 2022 2:02 pm
by AnalysIR
AS many of the bytes don't change in your signals you can save memory by hard-wiring those bytes into your code...will save lots of RAM.

In addition by storing the buffers in Flash, you can store many more signals on most platforms...giving you the option for hard-wiring in all the signals you actually want/need.

Re: Checksum headaches

Posted: Mon May 16, 2022 3:29 pm
by skydvrz
It turns out that there is plenty of room on a Node MCU ESP8266 Arduino for the WiFi, REST/JSON, home-automation-controller API, LED driver and logic code plus the heat/cool/off command lookup tables.

That plus I wrote an AnalysIR session file parser that decodes the ones and zeros (skipping header, gap and trailer) from the pulse timing info and automatically builds the text hex tables shown in my example code. It was easier than getting clever with invariant-value array elements :-)
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited