Home     Contact     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS     Terms of services     Privacy policy  
   
 Home      Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science   



Reverse Engineering a Fidji Air Conditioning IR Remote ControlAuthor
Giorgos Lazaridis
July 29, 2012

PAGE 2 of 3 - Identifying the Air condition remote control transmission protocol


Now i had to identify the transmission protocol. It turned out to be a hard job and i had to make a lot of tests, but i finally managed to decipher it. First of all, i made some changes to my software. Now that i know what sort of modulation is used, i can de-modulate the signal from the oscilloscope's data. I added a few fields and a long text box which shows the zeros and aces of the transmuted signal in sets of 8-bits:


 
 


And then i began the long process of acquiring different data sets for first analysis. I decided to begin by only changing the temperature setting from 31 (max) to 16(min) degrees. Then i pasted all these data to an A4 sheet and printed:


 
 


There are 2 regions in the transmitted code which changed when the temperature is changed. That was rather strange because i only expected one region to change. To further identify the protocol, i began taking samples and analyze the digital data (zeros and aces) instead:


 
 


There are 14 sets of 8-bit bytes in the protocol. Each byte is sent from left to right, so the LSB is always left and the MSB right. The bits probably must be inverted for proper calculations. The first 5 bytes never change, so i suppose this is the identification code. The 6th byte changes only if a turn-off command is set.

The 7th byte appears to change only when i select different mode (DRY-FAN-HEAT-FEEL-COOL). Only the first 4 bits are used.

The 8th byte seems to have the temperature setting. Only the first 4 bits are used. A 4-bit number can be from 0 to 15, and this explains why the minimum to maximum value is 15 (31-16=15). When the temperature is 16 degrees, the byte is 00001111, and when it is 31 it is 11111111.

The 9th byte seems to have two functions. The first 3 bytes are changed when i select the FAN speed (LOW-MID-HIGH-AUTO). The next 3 bytes are "111" when no SWING is selected, and they become "000" when i enable the SWING.

The next 4 bytes appear to be unchanged all the time. The remote control has some extra functions such as SLEEP mode and on/off TIMER, so probably these bytes are used for these functions. Additionally, notice the green bits. It is obvious that the remote control is responsible to avoid wrong setups. This is precisely the reason why the remote control must always send the compete parameter set upon a button press. For example, notice what happens when i change the MODE from COOL to HEAT. The temprature was set to 16 degrees. Probably, the manufacturer decided that HEAT operation cannot be used with such low temperature, so the control automatically sets the temperature to 24 degrees. Similarly, the FAN is not allowed to me in AUTO if the air-condition is used as a simple FAN.



The last byte was the hardest
At first, i thought that the last byte represents the temperature change, because if you notice, the last byte is change whenever the temperature is changed. One degree of change in the temperature equals to one change in the last byte. But then i noticed that the last byte changes not only with the temperature. As a matter of fact, any change that is done the last byte changes as well. So, the last byte is something like error correction. But what kind of error correction?



I tried to XOR bytes to see if there is a logical result, but i failed. After many observations and tests, i remembered that the the last byte is changed by one when the temperature is changed by one. There is one mathematical function which can achieve this; The addition!

At first, i inverted all the bits because it seemed to be more logical. Then i added the bytes 7-8 and 9 for all the previous samples. To my surprise, when i subtracted this result from the last byte, i always had a constant result of decimal 57, with one exception: The OFF command. This command gave me a different result. Obviously, the 6th byte had to be included in the addition.

So i added all bytes fro 6 to 9. To my surprise, everything looked prettier now! By subtracting the result of this addition from the last byte, i always had constant subtraction result of 21! Normally, this would be the end! To re-create the last byte, i only had to add the bytes form 6 to 9 and then add another 21 and that's all. But since my curiosity always overcomes my practical instincts, i had to find out where this "21" comes from.

The bytes 10 to 13 have no interest since they are all 0 (remember that i invert all bits). So the secret should be hidden somewhere in the first bytes. Unfortunately, none of them is 21. And if i add all these bytes, the result was very high...

BYTE 1: 11000100 = 35
BYTE 2: 11010011 = 203
BYTE 3: 01100100 = 38
BYTE 4: 10000000 = 1
BYTE 5: 00000000 = 0

Addition result = 277

And then, after and hour of tests and research, it just came to me! What if i just ignore the 9th bit of the previous addition which results from the 8-bit overflow???

277 - 256 = 21

This is why i like reverse-engineering that much!


Finally...
Finally, regarding the last byte. This byte is a simple error correction. To generate this byte, i only need to add the 13 bytes of the protocol and completely ignore any overflow from the 8th to the 9th bit. A very simple operation for any microcontroller!







Continue reading. Click here to go to the next page >>>.



Comments

  Name

  Email (shall not be published)

  Website

Notify me of new posts via email


Write your comments below:
BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.


      

  • At 24 October 2013, 11:51:03 user Mohamed wrote:   [reply @ Mohamed]
      • Hello sir
      I've been trying to control AC via IR for a long time
      is there any way to get the software you made ?

  • At 9 July 2013, 19:36:34 user AnalysIR wrote:   [reply @ AnalysIR]
      • Hi Giorgos,

      Really enjoyed reading your post and particulary the flow & style of describing the project. We have been working on a similar project recently, details of which you can find below.

      For anyone interested in Decoding IR protocols - we have just launched a project on IndieGoGo for AnalysIR - IR Decoder & Analyzer GUI (Arduino & Raspberry Pi). Currently we support 17 IR protocols and are looking for more to add as part of the project. Suggestions Welcome!

      You can find out more about the project on http://igg.me/at/AnalysIR/x/3752156 or Screenshot via www.AnalysIR.com or Meet us at DublinMakerFaire on Jul 27th

  • At 21 June 2013, 6:41:21 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
      • @peeyush manglam I made it myself. It is not a released software.

  • At 18 June 2013, 13:17:18 user peeyush manglam wrote:   [reply @ peeyush manglam]
      • hello sir,
      i want to know which software you used in your PC to collect the data from the oscilloscope .
      please reply me as soon as possible .
      I have been searching for this since 2 week and unable to find any solution regarding this .

      regards
      Peeyush manglam

  • At 8 May 2013, 14:58:36 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
      • @fuzail Sure i am active. Better use the forum for your questions.
      http://www.pcbheaven.com/forum/

  • At 8 May 2013, 11:03:34 user fuzail wrote:   [reply @ fuzail]
      • hey.
      this is a very interesting project that you have done.
      i am trying to do something very similar.
      could use your help.
      are you still active ?

  • At 30 March 2013, 20:23:15 user Sergey wrote:   [reply @ Sergey]
      • Hello,

      Excellent post! Thank you.

  • At 14 March 2013, 6:07:05 user Esys wrote:   [reply @ Esys]
      • Thanks a lot for such nice post. If some one has further work on it kindly post it for the others.

  • At 21 December 2012, 2:51:16 user Christopher wrote:   [reply @ Christopher]
      • I did this same thing only with the WIRED controller port on a Grunaire (chigo built) A/C unit about 3 and a half years ago.. the actual but positions are a bit different but similarity in the type of encoding.. in fact on that unit the wired control protocol and the IR are the same wit hthe difference there's no carrier..

      in their case for error correction you first send a 5 byte string.. followed by the same 5 byte string only with the bits inverted.. AND it is a 2 way protocol as it sends Back to you the settings in the same manner.. along with the actual indoor and outdoor temperatures that display on the wired control.. it is carried out over 1 wire (plus ground).. 5 volt TTL level.. normally the unit sends to the wired controller and the wired controller responds back with its settings.. when you adjust a setting.. the wired controller pulls the line low for 100 mSec and then releases it high for 50 mSec and then sends its sequence...

      to the one above comment.. I did just what you were asking.. I created my own micro controller to mimic the wired control panel of the unit using a Zbasic.net micro and my home automation system can control my A/C units in this manner...

      the added advantage is that the wired control panel would display error codes too.. so I also get the benefit that my home automation will pick up on when an A/C unit issues an error code...

      awesome stuff and love to see others are doing similar to me!! its a lot of fun!!

  • At 5 December 2012, 8:22:11 user Fajar Rukmo wrote:   [reply @ Fajar Rukmo]
      • thank's for your explanantion, finally i know why AC bit code is more long than TV.

      your remote using same length but bit changing..
      but my samsung remote using variable length,and this is gonna make more hard to analyze...

      anyway thank's for explanation....

  • At 16 October 2012, 15:41:49 user Jure wrote:   [reply @ Jure]
      • Thanks fo this explanation. Anyone aware of similiar IR decoding for Fujitsu and Panasonic (that's what we have here).

      Has anybody tried to "hack" remote control to be controlled remotely via internet?

      Any advice welcome :-)

      Jure

  • At 10 October 2012, 12:41:34 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
      • @atlas Hello. I do not work with Arduino, but i plan to make for PIC

  • At 10 October 2012, 12:35:40 user atlas wrote:   [reply @ atlas]
      • Hello

      Thanks for your excellent post. I'm trying to do the same thing as you for my Friedrich AC/heater.
      Do you plan to write a new post about using your result with an arduino to be able to control your device?



    delicious
    digg
    reddit this Reddit this
    Faves



     HOT in heaven!


    NEW in heaven!



    New Theory: AC electric motor working principle


     Contact     Forum     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS   

    Site design: Giorgos Lazaridis
    © Copyright 2008
    Please read the Terms of services and the Privacy policy