Trying to control Mitsubishi Heat Pump Air Conditioning Unit

Hi Chris,

I`m trying to replicate your work(http://wiki.crowe.co.nz/Mitsubishi%20Heat%20Pump.ashx) using an arduino ethernet with a mitsubishi(heavy industries) heat pump.

My aim is to remote(LAN/http) start the "sleep" mode, which is the button left down side on the remote. In heat mode the heat pump is going to a sort of low power mode over the course of a few hours and decreases the room temperature to 13°C. Sleep mode goes for a maximum of 10 hours which is exact what I need.

My remote(RKW502A200B) is nearly the same as your's.

  1. I was wondering if you had probably mixed up the fanspeed mode and the power modes of your heat pump.
    These are two different settings, see your mitsu manual. There is normal mode, high power and ECO mode.
    Only in normal mode I can choose the fan speed.

  2. When I use the timer buttons "sleep" "on" "off" the raw code jumps from 180 to 255.
    Can you replicate this?

Thanks for your awesome work on this remote code!

Hi

Yes I have seen the extra data bits that when uou use the timer functions, on time, off the etc.

Since I was not interested I ignored it, I was more interested in the base data functions only.

I did not look into it but the start time and end time are encoded into those bits and the sleep settings as well.

In regards to your Q1

I know I can not set fan speeds with powerful and Eco but I am unsure in what context you mention this?

Chris

zefix:
2. When I use the timer buttons "sleep" "on" "off" the raw code jumps from 180 to 255.
Can you replicate this?

Hi

There are infact 276 bits returned.

You need to modify the IRREMOTE.H file to increase the buffer

#define RAWBUF 276

And this time you need to modify the structure in IRREMOTEINT.H

typedef struct {
uint8_t recvpin; // pin for IR data from detector
uint8_t rcvstate; // state machine
uint8_t blinkflag; // TRUE to enable blinking of pin 13 on IR processing
unsigned int timer; // state timer, counts 50uS ticks.
unsigned int rawbuf[RAWBUF]; // raw data
unsigned int rawlen; // counter of entries in rawbuf

//uint8_t rawlen; // counter of entries in rawbuf
}
irparams_t;

Change the uint8_t rawlen to an unsigned int as shown above.

The uint8 is in fact an unsigned char = so its values are limited to 0 - 255.

This will now allow you to return the full 276 bits of binary data.

I have had a quick look but not yet decoded the additional 96 bits of data.

I will keep you posted.

Chris

I am not getting to far.

I have gone though 24 hours of values for the ON TIMER, with the off timer set to the same value.

So far I am not seeing a good pattern for the times.

Chris

Hi Chris,

I was fiddling around with this but my Mitsu won't accept any raw codes that I generated with your guide(including rasing the RAWBUF to 276), except for a peep sound but nothing else.
Then I used the standard "IRrecord" sektch from Ken Shirriff(with your changes to the config .h/.cpp) to record and send to my Mitsu and only that worked. The recorded "sleep" timer is also accepted by my Mitsu.
I do not have however tested it for the whole 10 hours and checked if it goes in low power mode an shuts itself off, but I will over the next days. Update: Works perfect!

the "IRrecord" raw data normal on heat etc...without "sleep" timer:
 m3200 s1300 m300 s500 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s500 m300 s1300
 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500
 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s500
 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300
 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500 m300 s500 m300 s500
 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s500
 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500
 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500
 m300 s500 m300

the "IRrecord" raw data "sleep" timer(10 hours, heating etc.):
 m3200 s1300 m300 s500 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s500
 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s1300
 m300 s1300 m300 s500 m300 s500 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300
 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s500
 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 
s1300 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500 m300
 s500 m300 s500 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300
 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s500 m300
 s1300 m300 s500 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500 m300 s1300 m300 s1300 m300
 s1300 m300 s500 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500 m300
 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s500
 m300 s500 m300 s500 m300 s500 m300 s500 m300 s500 m300 s500 m300 s500 m300 s1300 m300 s1300
 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s500 m300 s500 m300 s500
 m300 s500 m300 s500 m300 s500 m300 s500 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s1300
 m300 s1300 m300 s500 m300 s1300 m300 s1300 m300 s1300 m300 s500 m300 s1300 m300 s500 m300 s500
 m300 s1300 m300 s500 m300 s500 m300

I'm no programmer at all but I looked at the numbers in excel for easier comparing them and I noticed that the normal on/off RAW code without "sleep" timer, using the "IRrecord"sketch, counts only 179 single RAW numbers. When I use the "sleep" timer this number raises to 275.
And when I use the "sleep" timer there is a change in the first 179 RAW numbers. RAW number 116 switches from 1300 to 500 and No.132 switches from 500 to 1300. This seems to be the only change.

I hope that's for some help....

Hi Chris...

Great work with the protocol reverse engineering. I do have some questions - I don't actually have a Mitsubishi A/C unit, but am wanting to build the capability to control it into a device I am building.

  • Do you have any better idea of the timings, apart from being divisible by 400 uSec?
  • Any idea what carrier frequency the Mitsubishi uses?
  • What is the definition of Allergan in the spec?
  • What is the difference between Up/Down Swing Manual and Up/Down Swing?
  • What is the Temperature Range? Is it Temperature - 18C for the temperature field?

Anyway, great work on the protocol. FYI, I have had great success decoding IR using the USB IR Toy from DangerousPrototypes, and am having a lot of success using it, and more recently, using the Raspberry Pi running DMA and PCM

Darryl VK2TDS

Oh I have been thinking about doing this as well.
Is anyone offering the full sketch working sketch file by chance? I have the IR emitters and ardunio. Would love to try this.

Cheers heaps, John, Auckland NZ.

Hi Guys

I can not longer help with any details on this project as my Mitsubishi died - $2000 NZD to fix - so it is not getting fixed.

All that for a fan and a fuse!

What is the point of a fuse if it blows you have to replace the whole circuit board- sounds like a con to me!

Chris

Hopefully you dont kill your Mitsu with bugged IR codes from the arduino?

Maybe a power surge?

Cant you fix this on your own for a fraction of 2000,- NSD?

All the spareparts you need you could get from "www.mrespareparts.com.au". I even used their exploded drawings to fix mine over here in germany.

Thanks for the web site - I may look into that.

Cheers

Chris

Hello,

I'd be very interested in any news on this subject.

I tried to decode a Mitsubishi remote control today, using Chris's codes from the Crowe web site. Unfortunately, there was not much similarity with the recorded data I received.

The train of bits was much longer than I anticipated, and also were repeated once more from the remote.

As to the different lengths in the measurements you did with the arduino remote, the numbers indicate as follows :
A preamble comes first, with a logic 1 level for about 3200 uS, followed by a shorter low period.
A logic 1 is decoded if the low period is >1.5 times the previous high period. This has worked for me, anyway.
A logic 0 is decoded if the low period is shorter than the high period, or <1.5 times the high period.

I think the receivers might be particular to the timing of the high and low periods, but maybe not.

I would guess that the frequenzy of the PWM should be around 37kHz on the IR emitter. If the frequenzy is missed somewhat it is mostly the range that would be shorter. The more off, the shorter the range, until a point where it is not getting an IR signal through the receiving fiilter. A frequenzy between 34 to 42 on a 38kHz filter should pass without too much trouble.

I did not get a very good look at the repeating train, but assume it is a repeat of the first. Due to the first numbers not looking at all like Chris's decoded numbers, I did not dig in further. Yet :slight_smile:

A decoder can easily be made in Visual Basic within Excel, for instance, where the high+low times were compared with th 1.5 multiplier.

I'd also be very interested in the story of the defective Mitsu, whether it was a general failure or might have been caused by wrong codes being sent from the arduino. This is a bit scary, if you get the checksum right, and the command contains an impossible combination. One would think that the manufacturer of the pump would safeguard towards such an event, but they can hardly be held accountable as long as anyone tampers with the command.

If I can help with the decoding, please let me know.

Here's the recording I got, for temperatures from 16 to 31 degrees. I have separated the first bytes until temperature bits occur (at the '-' mark), trying to compare a header with what Chris found.

Temperature is 4 bit, but other bits also change later on. I suspect a checksum at the end.

The end is also a bit unstable, where the recorded length is different for some of the readings. Don't know why, might be my homemade recorder for all i know. Therefore, where differences occur towards the end, data is probably not trustworthy.

16:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0000 0000000000110101000111101110000000000000000000000000010010000000001000010000 0001101 01011000100110100110110010010000000000000000000010000010000 0000 0000000000110101000111101110000000000000000000000000010010000000001000010000000110100

17:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1000 0000000000110101001011101110000000000000000000000000010010000000001000010000 1001100 01011000100110100110110010010000000000000000000010000010000 1000 000000000011010100101110111000000000000000000000000001001000000000100001000010011000100

18:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0100 0000000000110101001011101110000000000000000000000000010010000000001000010000 0101100 01011000100110100110110010010000000000000000000010000010000 0100 000000000011010100101110111000000000000000000000000001001000000000100001000001011000100

19:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1100 0000000000110101001011101110000000000000000000000000010010000000001000010000 1101100 01011000100110100110110010010000000000000000000010000010000 1100 000000000011010100101110111000000000000000000000000001001000000000100001000011011000100

20:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0010 0000000000110101001011101110000000000000000000000000010010000000001000010000 0011100 01011000100110100110110010010000000000000000000010000010000 0010 000000000011010100101110111000000000000000000000000001001000000000100001000000111000100

21:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1010 0000000000110101001011101110000000000000000000000000010010000000001000010000 1011100 01011000100110100110110010010000000000000000000010000010000 1010 000000000011010100101110111000000000000000000000000001001000000000100001000010111000100

22:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0110 0000000000110101001011101110000000000000000000000000010010000000001000010000 0111100 01011000100110100110110010010000000000000000000010000010000 0110 00000000001101010010111011100000000000000000000000000100100000000010000100000111100000

23:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1110 0000000000110101001011101110000000000000000000000000010010000000001000010000 1111100 01011000100110100110110010010000000000000000000010000010000 1110 000000000011010100101110111000000000000000000000000001001000000000100001000011111000000

24:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0001 0000000000110101001011101110000000000000000000000000010010000000001000010000 0000010 01011000100110100110110010010000000000000000000010000010000 0001 000000000011010100101110111000000000000000000000000001001000000000100001000000000100000

25:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1001 0000000000110101001011101110000000000000000000000000010010000000001000010000 1000010 01011000100110100110110010010000000000000000000010000010000 1001 00000000001101010010111011100000000000000000000000000100100000000010000100001000010000

26:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0101 0000000000110101001011101110000000000000000000000000010010000000001000010000 0100010 01011000100110100110110010010000000000000000000010000010000 0101 000000000011010100101110111000000000000000000000000001001000000000100001000001000100000

27:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1101 0000000000110101001011101110000000000000000000000000010010000000001000010000 1100010 01011000100110100110110010010000000000000000000010000010000 1101 000000000011010100101110111000000000000000000000000001001000000000100001000011000100000

28:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0011 0000000000110101001011101110000000000000000000000000010010000000001000010000 0010010 01011000100110100110110010010000000000000000000010000010000 0011 000000000011010100101110111000000000000000000000000001001000000000100001000000100100000

29:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1011 0000000000110101001011101110000000000000000000000000010010000000001000010000 1010010 01011000100110100110110010010000000000000000000010000010000 1011 000000000011010100101110111000000000000000000000000001001000000000100001000010100100000

30:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 0111 0000000000110101001011101110000000000000000000000000010010000000001000010000 0110010 01011000100110100110110010010000000000000000000010000010000 0111 000000000011010100101110111000000000000000000000000001001000000000100001000001100100000

31:11000100 11010011 01100100 10000000 00000000 00000100 00010000 - 1111 0000000000110101000111101110000000000000000000000000010010000000001000010000 1110011 01011000100110100110110010010000000000000000000010000010000 1111 000000000011010100011110111000000000000000000000000001001000000000100001000011100110000

Dear All,

We are trying to reveres engineer the Mitsubishi Electric Air con remote to switch ON and OFF from Arduino IR. :slight_smile:
Followd the Chris as descried below.
http://wiki.crowe.co.nz/Mitsubishi%20Heat%20Pump.ashx

(Except the decode bit pattern on C# because we do not want all settings..just on /off).
So,we got the binary bit pattern. (89 bits 0 and 1 patern). On the bit pattern we do not know the timing of High(1) and Low (0) singal.

So, we tried , X-SAT / NEC protocol timing ( for example 550 micor second ON /1100 micro second OFF) for Sending . But NOT working even we match binary bit pattern of Mitsu remote.

  1. Is the carrier frequency of Mitsub is 38 KHz ?
  2. we have plan to find the original timing with Oscilloscope for ON /OFF

Any clue how to proceed ? or Suggestion or Question? :slight_smile:

With regards,
Chandra

Well, that was easy... Protocol reverse engineering : Solved.

The last byte is a CRC, and is calculated (addition) straight forward from byte 0 to byte 16, and truncated to 8 bit.

The pulse train is 145 bits long (with a logic "1" on the end), so 144 usable bits. Transmission is repeated once.

Can you also share some schematics or code?

Awesome thread. Im working on the same project with a Mitsubishi heat pump. I also get various lengths. Here is a dump of changing the temp from 16 to 31 degrees:

Here i am changing the mode

Seems to be consistent except the last bits... I dont know what it is for or why they differ in length. Anyone got a clue?

I am glad to find others that are trying to decode the Mitsubishi heat pump/AC ir. zappen999 and Fusebox, it looks like you are both using centigrade, while I am in the US and my heat pump is using F. That may be why yours are similar to each other, while I am getting a somewhat different code. The main problem I am having in deciphering this is that the code seems to change from, say, going up between going down in temperature. For example, if I hit the temp up button from 60F to 62F, then back down to 60F, I get the attached results. I thought maybe this was an error in reading, but it seems too consistent otherwise.

I cant wrap my head around this variable length thing. Is it supposed to be like this or is it a mistake when reading the sequence?

mdatum: Which pump do you have? I dont know farenheit but i get a different byte when reaching the endvalues (min & max temp). Dont know why though?

Fusebox, you said the last byte is a CRC. Can you tell explain some more about this? You have variable lengths in the result too. Would be really interesting to crack this.

zappen999: I have a dual zone. The indoor heads are 9600 BTU, and don't have the i-see sensor. They were installed about a year ago. I'm at work, so don't have the model number available.