Reverse engineering Hitachi air conditioner infrared remote commands

Reverse engineering Hitachi air conditioner infrared remote commands

Updated 2 April 2015

Background

As part of a home automation project me and a friend started to reverse engineer the infrared remote control protocol used by a Hitachi split type air conditioner. The model in question was a RAS-25SX8 (manual here) but there is no reason to believe that the protocol isn’t the same for many other models and the methods we used to reverse engineer the codes should work with pretty much any remote control.

Most remote controls or at least the remote controls we’ll be talking about here work by sending a series of 38KHz PWM pulses mixed with pauses of various length.
Finding out the length of the PWM pulses and the length of the pauses between them is the key to cracking the protocol.
A remote control for a TV usually sends a code of one byte or so telling which key the user is pressing and it keeps sending the same code over and over until the key is released. There is a different code for each key on the remote control.
Air conditioner codes on the other hand are quite long because it’s the remote control that keeps track of the settings and it sends the complete set of settings everytime a key is pressed.

The only information we managed to find about any Hitachi remote control protocols was this blog: http://mroxanas.blogspot.com/2011/09/infrared-remote-control-code-hacking.html

They managed to turn a device on or off using recorded codes but provide no source code so we couldn’t quite wrap our heads around how to send the codes. We also wanted to do a bit more than just turning on and off so we started to dig.

Aquiring authentic commands

We first needed to take a look at code from a real remote control to get an understanding about how it’s constructed.

As suspected and as mroxanas mentioned, the codes used are quite long – much longer than we managed to record using Arduino and some standard IR libraries such as Arduino-IRremote.
In the end we decided to go with an Arduino sketch from analysir.com with which we managed to record several long codes which all seemed consistent enough to be correct recordings. The sketch can be found at http://www.analysir.com/blog/2014/03/19/air-conditioners-problems-recording-long-infrared-remote-control-signals-arduino/

The AnalysIR sketch dumps puls lengths and pause lengths in microseconds like this:

Raw: (595) 3280, -1704, 468, -1168, 472, -400, 448, -428, 444, -428, 444, -428, 444, -428, 448, -428, 444, -432, 444, -428, 444, -432, 444, -428, 444, -428, 444, -1192, 468, -404, 444, -428, 444, -436, 440, -432, 444, -428, 444, -428, 444, -428, 444, -432, 444, -428, 444, -428, 444, -436, 440, -432, 444, -432, 440, -428, 444, -432, 444, -428, 444, -428, 444, -1188, 472, -408, 444, -1188, 448, -1188, 444, -1188, 448, -1188, 444, -1192, 444, -1188, 444, -432, 444, -1192, 444, -1192, 444, -1188, 444, -1192, 444, -1188, 448, -1188, 444, -1188, 448, -1188, 444, -1196, 444, -428, 444, -428, 444, -432, 440, -432, 444, -428, 444, -428, 444, -432, 444, -432, 444, -428, 444, -428, 444, -1192, 444, -1192, 444, -428, 444, -428, 444, -1192, 444, -1192, 448, -1188, 444, -1188, 448, -428, 444, -428, 444, -1188, 448, -1188, 444, -428, 444, -436, 444, -1188, 472, -1164, 444, -1188, 472, -404, 444, -428, 444, -1188, 448, -428, 444, -1192, 444, -432, 444, -428, 444, -428, 444, -1188, 448, -1188, 448, -428, 444, -1188, 444, -432, 444, -432, 444, -428, 444, -1188, 448, -428, 444, -428, 444, -428, 444, -1192, 444, -432, 444, -1192, 444, -1188, 444, -428, 448, -1188, 444, -1188, 448, -1188, 444, -432, 444, -1192, 444, -432, 440, -432, 444, -1188, 472, -400, 448, -428, 444, -1188, 444, -1192, 468, -408, 444, -1192, 468, -1164, 448, -428, 444, -1188, 444, -1192, 468, -404, 444, -428, 444, -1196, 444, -428, 444, -428, 444, -432, 444, -428, 444, -428, 444, -428, 444, -432, 444, -432, 444, -1188, 472, -1164, 444, -1188, 472, -1164, 444, -1188, 448, -1188, 448, -1188, 472, -1164, 448, -428, 444, -428, 444, -428, 444, -432, 440, -432, 444, -428, 444, -428, 444, -436, 444, -1188, 444, -1192, 444, -1188, 448, -1188, 444, -1188, 448, -1188, 444, -1188, 448, -1192, 444, -432, 440, -432, 444, -428, 444, -428, 444, -428, 444, -432, 444, -428, 444, -432, 444, -1192, 444, -1188, 448, -1188, 464, -1172, 444, -1188, 444, -1192, 444, -1188, 444, -1196, 444, -428, 444, -428, 444, -432, 444, -428, 444, -428, 444, -428, 444, -432, 444, -432, 444, -1188, 472, -1164, 444, -1192, 444, -1188, 444, -1192, 444, -1188, 448, -1188, 444, -1192, 448, -428, 444, -428, 444, -428, 444, -432, 444, -428, 444, -428, 444, -432, 440, -436, 444, -1188, 444, -1192, 444, -1188, 448, -1188, 444, -1188, 448, -1188, 444, -1192, 444, -1192, 444, -432, 444, -1188, 444, -1192, 444, -428, 444, -1188, 448, -428, 444, -1188, 448, -432, 444, -1188, 444, -432, 444, -428, 444, -1188, 448, -428, 444, -1188, 444, -428, 444, -1196, 444, -1188, 448, -428, 444, -428, 444, -432, 440, -1192, 444, -1188, 448, -1188, 444, -1192, 448, -428, 444, -1192, 444, -1188, 444, -1192, 444, -428, 444, -428, 444, -428, 444, -436, 444, -428, 444, -428, 444, -432, 444, -428, 444, -428, 444, -428, 444, -432, 440, -436, 444, -1188, 448, -1188, 444, -1192, 444, -1188, 444, -1192, 444, -1188, 464, -1172, 444, -1192, 448, -428, 444, -428, 444, -428, 444, -432, 440, -432, 444, -428, 444, -428, 444, -436, 440, -1192, 444, -1192, 444, -1188, 444, -1192, 444, -1188, 448, -1188, 444, -1188, 448, -1192, 444, -428, 444, -432, 444, -428, 444, -428, 444, -432, 440, -432, 444, -428, 444, -432, 444, -1192, 444, -1188, 448, -1188, 444, -1192, 444, -1188, 444, -1192, 444, -1188, 444, -1196, 468, -1164, 448, -1188, 444, -1192, 444, -1188, 444, -432, 440, -432, 444, -428, 444, -432, 444, -432, 440, -432, 444, -428, 444, -428, 444, -1192, 444, -1192, 444, -1188, 444, -1192, 448,

The command in this example contained the settings for Heat mode, 25 C degrees, Auto fan speed.

Analysing the pulse format

The text “Raw: (595)” is not a part of the code. It’s just part of the output from AnalysIR telling us type and length of the captured code. The code starts with 3280.
Positive numbers are pulses (38KHz PWM pulse) and negative numbers are pauses (silence). The number indicates the duration in microseconds (us).
If we look at the beginning of the code it differs a bit from the rest of the code.
3280 is a pulse with a length of 3280 us. It’s followed by -1704 which is a pause for 1704 us.
The code continues with 468 us pulse, 1168 us pause, 472 us pulse, 400 us pause, a new pulse and another pause and so on for the rest of the code. The code must always end with a pulse. The last pause wouldn’t be a pause if it didn’t have a pulse after it, would it?
The exact duration of the pulses and pauses varies a little bit between the recordings but not significantly. They do however differ a bit from the numbers in mroxanas blog. Our guess is that the relation between the lengths are more important than the actual lengths.

All the pulses are roughly the same length. Our average was around 450us.
The pauses are either long like 1168us or short like 400us.
Our averages were around 1180us and 400us so that’s the numbers we used in our tests and they worked well.
Here’s all the lengths:
First pulse: 3200 us
First pause: 1700 us
Pulse: 450 us
Long pause: 1180 us
Short pause: 400 us

The first pulse and pause is some start code.
The rest of the pauses are the bits that make out the data in the command. The pulses are just there to separate the pauses from eachother.
A long pause is binary one
A short pause is binary zero

The amount of bits is normally 296 (37 bytes). There seems to be some extra bits on the end if you use an alternate address setting on the remote control.

The data captured by the AnalysIR could be used as it is with the IRremote library’s sendRaw function. But to crack the protocol and gain higher flexibility when sending commands it’s neccessary to perform some deeper analysis. We must therefore conver all the raw data to bits.
We did this with a quick and dirty powershell script that takes the input from the AnalysIR sketch, strips out all the positive numbers and converts all the negative numbers to either 1 or 0 depending on how long they are. If it’s > -800 it’s a 0 and if it’s < -800  it's a 1.

The code converted to binary:

10000000000010000000000000000010111111011111111100000000001100111100110011100101000110100010001011011101001001101101100100000000111111110000000011111111000000001111111100000000111111110000000011111111011010101001010110001111011100000000000011111111000000001111111100000000111111111111000000001111

Analyzing protocol data

To get a better overview of the data it would make sense to divide the data into bytes if that’s the way it’s organized.

       1        2        3        4        5        6        7        8        9       10       11       12       13       14       15       16       17       18       19       20       21       22       23       24       25       26       27       28       29       30       31       32       33       34       35       36       37
10000000 00001000 00000000 00000010 11111101 11111111 00000000 00110011 11001100 11100101 00011010 00100010 11011101 00100110 11011001 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 01101010 10010101 10001111 01110000 00000000 11111111 00000000 11111111 00000000 11111111 11110000 00001111

It’s quite obvious that the binary data makes out even bytes, just look at bytes 16-25.
It’s also obvious that every second byte starting with byte 5 has got all the bits from the previous byte inverted (bitwise NOT). So bits 4,6,8,10,12 etc are bytes with data while 5,7,9,11 etc are just parity bits.

To figure out what all the data is and where your settings are stored it’s neccessary to record several codes with only one change at a time and compare them to eachother so let’s compare the above example of 25 C temperature with 26 and 27 degrees:

            1        2        3        4        5        6        7        8        9       10       11       12       13       14       15       16       17       18       19       20       21       22       23       24       25       26       27       28       29       30       31       32       33       34       35       36       37
25C  10000000 00001000 00000000 00000010 11111101 11111111 00000000 00110011 11001100 11100101 00011010 00100010 11011101 00100110 11011001 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 01101010 10010101 10001111 01110000 00000000 11111111 00000000 11111111 00000000 11111111 11110000 00001111
26C  10000000 00001000 00000000 00000010 11111101 11111111 00000000 00110011 11001100 11100101 00011010 00100010 11011101 00010110 11101001 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 01101010 10010101 10001111 01110000 00000000 11111111 00000000 11111111 00000000 11111111 11110000 00001111
27C  10000000 00001000 00000000 00000010 11111101 11111111 00000000 00110011 11001100 11100101 00011010 00100010 11011101 00110110 11001001 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 01101010 10010101 10001111 01110000 00000000 11111111 00000000 11111111 00000000 11111111 11110000 00001111

There are only two bytes that changes – byte 14 and 15. Byte 15 is just parity so it’s byte 14 that contains the temperature.
25C: 00100110
26C: 00010110
27C: 00110110
If you know your binary numbers you will see that part of these bytes actually contain the temperature. The binary representation of 25 is 11001 but in the data from the remote it is written with the least significant bit first (LSB first) – 10011. in other words backwards.
After more tests it’s clear that the temperature is sent in byte 14 (and 15) no matter what mode the unit is operating in so that’s what byte 14 is used for.
The other bits of byte 14 has never changed in our tests so they are probably always 0.

We went through some basic settings to map out other functions and see what number correspond to certain codes but we have only been scratching the surface.

Mapped bytes

These are the bytes and bits that we know anything about today.

bytemap

We are quite sure about the green ones while we are just assuming that the orange ones are static.
The white bits are totally unknown or just indications which we haven’t investigated yet. Feel free to do so and let us know what you find in the comments.

Byte 12

Seems to be used differently by all remote control operations.
Combinations of bits seems to activate/deactivate different operations or modes but not all operations need byte 12 to work.

Observered variants
Operation Bits In combination with
Adding a timer 01000100 Minutes in bytes 18-24 and Timer type in byte 24 – bit 5 or 6
Removing a timer 00100100 Timer type in byte 24 – bit 5 or 6
Change fan speed 01000010 Byte 26
Change temperature 00100010 Byte 14
Plasma air purifying operation 10010010 Byte 28 – bit 8 = 0 (questionable)
Mold monitor operation 11010010 Byte 34 – bit 7 = 1
Internal cleaning operation 11110010 Byte 34 – bit 4 = 1
Ionized mist operation 00010110 Byte 30 – bit 1 = 1
Sleep operation 11010110 Byte 32 – bit 5 = 1
Toggle(?) vertical air deflector movement 10000001
Adjust horizontal air deflectors 00110001 Byte 10?
Air quality monitor operation 01000011 Byte 34 – bit 3 = 1

Some of these operations like fan and temperature don’t need a specific code in this byte because they are all being set every time a code is sent. Is the same true for mist, sleep, monitoring modes and horizontal deflectors etc?
We have not tried to replicate all of these operations.
Must investigate further.

Byte 13

Bitwise NOT of Byte 12.

Byte 14

Temperature
Bits 1-2: Always 0
Bits 3-7: Room temperature setting in Celsius. Possible values:  16 to 32 for most modes, 10 to 32 for dehumidify.
Bit 8: Always 0

Bit 3 is LSB and bit 7 MSB so 22 degrees would be written 01101
Fill out with the other bits and you get 00011010.

Byte 15

Bitwise NOT of Byte 14.
At 22 degrees it would be 11100101

Byte 16

Possibly related to timers.

Byte 18+20

These bytes are used together to set a time for an OFF TIMER
The time is specified in minutes from now and stored as an LSB first 11 or 12-bit number starting at Byte 18, Bit 5 and ending in Byte 20, Bit 7 (or 8?).

Byte 18, Bit 1-4: Seems to always be 0000
Byte 18, Bit 5-8 (5 is LSB)
Byte 20, Bit 1-7 (7 is MSB)
Byte 20, Bit 8: Possibly bit 12 (MSB bit) but most likely always 0 since no valid numbers need that man bits.

Example

To specify 600 minutes.
600 binary = 1001011000
600 binary LSB first 0001101001
Byte 18 + 20 = xxxx0001 10100100

Byte 19+21

Bitwise NOT of bytes 18 and 20

Bytes 22+24

These bytes are used together to set a time for an ON TIMER
The time is specified in minutes from now and stored as an LSB first 11 or 12-bit number starting at Byte 22, Bit 1 and ending in Byte 24, Bit 3 (or 4?).
Two bits in byte 24 are also used to activate on timer or off timer or both (on/off timer).

Byte 22, Bit 1-8 (bit 1 is LSB)
Byte 24, Bit 1-3 (bit 3 is MSB)
Byte 24, Bit 4: Possibly bit 12 (MSB bit) but most likely always 0 since no valid numbers need that man bits.
Byte 24, Bit 5: Activate off timer when set to 1
Byte 24, Bit 6: Activate on timer when set to 1

Example

To specify 600 minutes.
600 binary = 1001011000
600 binary LSB first 0001101001
Byte 22 + 24 = 00011010 0100xxxx

Byte 23+25

Bitwise NOT of bytes 22 and 24

Byte 26

Modes + Fan speed
Bits 1-4: Mode setting. Possible values: Not fully known
Bits 5-7: Fan speed. Possible values: 1 (silent) to 5 (automatic)
Bit 8: Always 0

Modes

All 16 binary combinations listed even though all aren’t known and some may not be valid.

Setting No. Bit 1 Bit 2 Bit 3 Bit 4 Mode
0 0 0 0 0 ?
1 1 0 0 0 ?
2 0 1 0 0 ?
3 1 1 0 0 Cool
4 0 0 1 0 Dry Cool
5 1 0 1 0 Dehumidify
6 0 1 1 0 Heat
7 1 1 1 0 Automatic Operation
8 0 0 0 1 ?
9 1 0 0 1 Auto Dehumidifying
10 0 1 0 1 Quick Laundry
11 1 1 0 1 ?
12 0 0 1 1 Condensation Control
13 1 0 1 1 ?
14 0 1 1 1 ?
15 1 1 1 1 ?
Fan speed
Setting No. Bit 5 Bit 6 Bit 7 Fan Speed
1 1 0 0 Silent
2 0 1 0 Low
3 1 1 0 Med
4 0 0 1 Hi
5 1 0 1 Auto
Byte 27

Bitwise NOT of Byte 26.
If Byte 26 is set to Mode=Cool and Fan=Hi (11000010), Byte 27 would have to be 00111101.

Byte 28

Power On/Off + Sleep timer(?)
Partly unknown.

Bit 1-4: Has always been 1000 in our tests.
Bit 5: Turn unit on (1) or off (0). Should always be 1 when changing other settings.
Bit 6-7: Has always been 11 in our tests.
Bit 8: Function is not investigated but turns to 0 when sleep timer is activated. Otherwise 1.

Examples

10001111: Power on unit or keep unit on when changing settings
10000111: Power off.

Byte 29

Bitwise NOT of Byte 28

Byte 30

Bit 5-6: Set to 11 to enable Powerful Operation (not tested)

Byte 31

Bitwise NOT of Byte 30

Byte 36

Bit 1-4: Has always been 1111 in our tests.
Bit 5-8: Humidity. Possible values: 3 (40%) to 9 (70%)

Setting No. Bit 5 Bit 6 Bit 7 Bit 8 Humidity
3 1 1 0 0 40%
4 0 0 1 0 45%
5 1 0 1 0 50%
6 0 1 1 0 55%
7 1 1 1 0 60%
8 0 0 0 1 65%
9 1 0 0 1 70%
Byte 37

Bitwise NOT of Byte 36

More bytes and bits will be added if we find any. If you have any additions or corrections please leave a comment.

Controlling the unit using Arduino

Now that we have a few known commands it’s possible to control the individual functions of the unit.
We need to send the full 37 bytes every time so it’s necessary to have a complete default command to fill out the areas that we don’t know much about. We can then replace selected parts of that default command to create a full custom command.

We went with one of the examples above as a starting point.
Heat, 25 degrees, Fan=Auto.

10000000000010000000000000000010111111011111111100000000001100111100110011100101000110100010001011011101001001101101100100000000111111110000000011111111000000001111111100000000111111110000000011111111011010101001010110001111011100000000000011111111000000001111111100000000111111111111000000001111

We put all the bits from the default command into an array. Then we replace the necessary bits with the values we want. If we want to change the temperature we need the binary LSB first representation of the temperature. That’s five bits.
We then replace the bits with offset 106-110 in our array with the five bits representing the new temperature.
If everything else in the default command is ok we can send the command now and the temperature will change.

Sending the command means doing a lot of pulsing at 38Khz. A pulse can be sent from arduino by toggling a pin with an IR LED between HIGH and LOW every 26us.
A function like this can do that and takes the length of the pulse as an argument:

void sendPulse(int pulseLength){
  int IR_on = 0;
  long startMicros;
  startMicros = micros();
  while (micros() &amp;lt; (startMicros + pulseLength)){
    // sending 38 KHz pulse
    if (IR_on == 0) {
      IR_on = 1;
    }
    else {
      IR_on = 0;
    }
    digitalWrite(IRPIN, IR_on);
    delayMicroseconds(26);
  }
  // turn off IR after pulse is complete
  digitalWrite(IRPIN, LOW);
}

According to what we learned from our analysis of the protocol we would have to begin the command with a special pulse and a special pause, then standard pulses and delays for either 0 or 1.
Literally:

sendPulse(3200);
delayMicroseconds(1700);
sendPulse(450);
delayMicroseconds(1180);
sendPulse(450);
delayMicroseconds(400);
sendPulse(450);
delayMicroseconds(400);
sendPulse(450);
delayMicroseconds(400);
...
&amp;lt;hundreds of bits&amp;gt;
...
sendPulse(450);
delayMicroseconds(1180);
sendPulse(450);
delayMicroseconds(1180);
sendPulse(450);

Of course you wouldn’t code it like this.
Instead you loop through an array with all the bits that needs to be sent as mentioned earlier and you just send the special pulses using a teqnique such as the example above.

Download a complete example sketch for sending a command here.
SendHitachiCode.ino

Here’s another sketch that takes commands from the serial monitor on the Arduino. It converts the supplied values and applies them to the right positions in the command and then sends the command.
HitachiACRemote.ino

Advertisements

11 thoughts on “Reverse engineering Hitachi air conditioner infrared remote commands

  1. Awesome explanation and insights. Thanks a lot! Will do this to my Mirage and comment again soon.

  2. This is very interesting work.
    I tried to reproduce the result on another Hitachi ACRemote.

    – I used my soundcard to record the signal on the pins of the leds. Works good. The soundcard has internal band filter, so I dont see the 38kHZ signal, I only see high level when there is a burst. This is enough information to decode the data, and I created a pyaudio program to decode the signal.

    – The layer 3 protocol is completely different. Instead of the weird “every other byte is parity”, I only have a checksum byte in the end of the burst.

    – The layer 5 is also completely different. As my AC as fairly different feature this makes sense.

    – I also get a bunch of the data space which is always unvariant for me whatever button I press.

    I eventually managed to recreate the signal using my edison + grove IR, using the PWM pins capability of the edison.

  3. could you please try to provide IR detecter circuit, so we can check whole sequence (waveform) in oscilloscope. Can we directly use TSOP1738 receiver to receive by aiming remote to the TSOP. Please guide me how to purchase all AC codes for project purpose and cost for the same.

  4. Thanks for posting this information. I’m trying to decode a different model Hitachi IR remote that does not have humidity control and thus only sends out 264 bits (33 bytes) as opposed to 37 bytes in your example. Due to some limitations on the controller system I am working with, I am unable to transmit the full 264 bits. I see that the last 16 bits are always the same and never change (last 8 is inverse of second to last 8). Does anyone know if the AC unit will reject what was sent earlier in the IR stream or does it really require the full length IR signal to decode the data properly? Thanks very much for any insight on this.

  5. I did something similar to reverse engineer my Hitachi AC commands using Pinguino board and IR receiver. My AC is without air purifier and humidity settings. You can compare my work with yours:

    Reverse Engineered RAS/RAC remote infrared protocol

    10000000 80
    00001000 08
    00000000 00
    00000010 02
    IIIIIIII inverse of the previous byte
    11111111 ff
    IIIIIIII inverse of the previous byte
    00110011 33
    IIIIIIII inverse of the previous byte
    01001001 49
    IIIIIIII inverse of the previous byte
    CCCCCCCC Command type
    11001000 – Power On, Power Off
    10000001 – Swing On/Off
    01000010 – Fan Control
    00100010 – Temperature Increase
    11000010 – Temperature Decrease
    10000010 – Mode Select
    01000100 – Timer On
    00100100 – Timer Off
    10001100 – Sleep Timer
    IIIIIIII inverse of the previous byte
    00TTTTTT TTTTTT temperature in big endian order 16..32
    IIIIIIII inverse of the previous byte
    00000000 always
    11111111 inverse of the previous byte
    0000MMMM see next
    IIIIIIII inverse of the previous byte
    MMMMMMM0 Timer-Off delay: MMMMMMMMMMM big endian, minutes
    IIIIIIII inverse of the previous byte
    KKKKKKKK see next
    IIIIIIII inverse of the previous byte
    KKK0XY00 X – 0:Timer-Off not placed 1:Timer-Off placed; Y – 0:Timer-On not placed 1:Timer-On placed
    Timer-On delay: KKKKKKKKKKK big endian, minutes
    IIIIIIII inverse of the previous byte
    MMM0FFF0 FFF – Fan – 101:Auto,001:Max,110:Mid,100:Min
    MMM – Mode – 100:Fan,111:Auto,011:Heating,101:Dehumidification,110:Cooling
    IIIIIIII inverse of the previous byte
    1000P011 8b/83 P – Power – 1:On 0:Off
    IIIIIIII inverse of the previous byte
    01001000 48
    IIIIIIII inverse of the previous byte
    01000000 40
    IIIIIIII inverse of the previous byte

    Examples:

    Decoding Bits
    10000000 80 00001000 08 00000000 00 00000010 02 11111101 fd 11111111 ff 00000000 00 00110011 33
    11001100 cc 01001001 49 10110110 b6 00100010 22 11011101 dd 00101010 2a 11010101 d5 00000000 00
    11111111 ff 00000000 00 11111111 ff 00000000 00 11111111 ff 00000000 00 11111111 ff 00000000 00
    11111111 ff 01101000 68 10010111 97 10001011 8b 01110100 74 01001000 48 10110111 b7 01000000 40
    10111111 bf
    Decoding Bits Done

    Decoding Bits
    10000000 80 00001000 08 00000000 00 00000010 02 11111101 fd 11111111 ff 00000000 00 00110011 33
    11001100 cc 01001001 49 10110110 b6 00100010 22 11011101 dd 00011010 1a 11100101 e5 00000000 00
    11111111 ff 00000000 00 11111111 ff 00000000 00 11111111 ff 00000000 00 11111111 ff 00000000 00
    11111111 ff 01101000 68 10010111 97 10001011 8b 01110100 74 01001000 48 10110111 b7 01000000 40
    10111111 bf
    Decoding Bits Done

  6. Hi.. it’s quite late comment .. but does anyone here success in using the arduino code? I decode it and use it for simple sending array without change anything and it’s not working.. it’s sending it , but my air conditioner does not receive it/not giving any response

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s