Air Conditionner IR protocol

[J]

Hello,

I'm trying to control an air conditionner remotely, so I built a simple atmega based IR transmitter. I'd like to understand the protocol used by the IR remote, in lieu of just repeating a previously recorded signal. However, I can't seem to find which protocol it uses, does someone have any clue ?

Here's what I'm getting for the 'On' button :


We can see a 'start' break at the beginning, do you think each larger pulse encodes the information (like 1 for short pulse, 0 for long) ? Do you have any idea of the underlying protocol ? (headers ?)

Thank you for your time.

[Psi]

Usually IR remote comms is just a long start pulse followed by a binary sequence that simply represents a specific button.
Occasionally you get codes that toggle for press and hold controls like volume

However your waveform is much longer than a typical IR code (~12 bits) so there could be some sort of message frame in there.
Have you tried converting it to ascii starting at the 2nd falling edge.

Do you know if the time between rising edge 1 and falling edge 2 is longer than the other big pulses or is the picture just deceptive?

[J]

Yes, but I don't really know what defines a 0 and what defines a 1. The saleae logic analyzer I use can't decode it properly (every single protocol I try gets errors or garbage, ie. async serial and 1Wire).

[amyk]

What encoder IC does the remote use?

See if the signal repeats, and how long it is.

[Jon Chandler]

Google "JP1 remote" and look for the JP1 forum.  JP1 is the protocol that universal remote controls use.  You'll be able to find a lot of explanatory material and possibly even the IR codes your A/C uses.

[J]

@amyk: I can't open it, it seems glued. I'll try harder !

@Jon :   Ho thank you, that's what I was looking for it seems.

Working on it, I'll keep you updated.

[SeanB]

Depending on the manufacturer they normally use a variant on the Phillips IR protocol. Panasonic uses thier own, Samsung another, but the universal remotes normally handle a large number of brands. Normally the remotes use a blob on board instead of a chip, so you are not going to easily get info there, otherwise a Holtek chipset like many IR remotes or a full custom ASIC is used especially if there is a built in LCD display.

[hlavac]

I have reverse engineered IR protocol of an LG AC unit a year ago. Your protocol seems to be different.


It was encoding ones and zeros as two different lengths (500us and 1500us) of pauses after 500us pulses. The pulses themselves were made of a 38kHz low duty cycle carrier tone.

There was a long (8.7ms) AGC pulse on the start, two 4bit nibbles of fixed header, four nibbles of command and one nibble of checksum (sum of the data nibbles).

[Psi]

If you capture a few more codes it may become obvious which is header/footer/checksum and which is data.

[David_AVD]

@amyk: I can't open it, it seems glued. I'll try harder !

There is sometimes a screw inside the battery compartment.  Even after removing it, most remotes require a fair bit of force to get open.  Once you get the case separated in one spot, the rest is easier though.

[lgbeno]

I've designed an IR remote for a commercial product and then also reverse engineered a decoder for the Syma micro helicopter.  This looks very typical, basically it is like you are suggesting.  A long pulse represents a 1 and short represents a zero.

Best thing to do would be to write a little code to decode the streams into ones and zeros and see what bits change when you push different buttons.  Sometimes there is a fixed ID field then a command byte that changes for every different button.  I think some protocols have a checksum or parity as well.

[joelby]

All air conditioners I've seen seem to rely on the remote control to maintain 'state', so I would assume that they transit all data each time you press a button.

Take the remote into another room or cover the LED and you can still change the temperature on the display. If it transmitted "increase temperature by 1" rather than "set temperature to 20", you could imagine that the control and the unit would quickly get out of sync!

[notsob]

Have a look at pcbheaven.com, georgios details a reverse engineer of a remote.

[Psi]

Joelby will be right,  that's why the code is so long.

The temp is probably sent in C or F so if you record a few IR codes for setting different temps, and note down which is which, it will probably be easy to find the C or F value (in either binary or ascii) inside the frame.

[lgbeno]

Uploading some code that I did for decoding the Syma S7 IR protocol w/ MSP430.  You're welcome to use or adapt it and any way that you see fit.

[paul23]

I have done quite a lot of work with air conditioning remotes and the suggestions you have so far are pretty much spot on. 

There isn't a generic ac remote format.  Each manufacturer has their own quirky way of doing things, but in general the remote will send all the settings with every button press.  This makes the codes quite long, especially of more up market systems.  The chinese makes like Midea or Aux are easiest to decode because they are simpler, usually they will have a mark and a space at the beginning, then the rest is basically just ones and zeros.  usually you will have around 20-30 bits for the identifier, then (not in particular order) 2-3 bits for the mode (cool, heat, etc) 2-3 bits for the fan speed, 4 bits for the temperature, and then a few 1 or bits for extra features like swinging the louvers, etc.  After that there is usually either a long bit at the end, the code is repeated or the code is repeated backwards.  In most cases it is just the long bit at the end.  If there are timers involved, then they are usually the last bit of the code. 

One trap to look out for is that sometimes you will get parts of the code that don´t do anything, they will be for features that you don´t have on your particular model, so don´t worry about them.

The hardest to decode are Daikin, they are really complex and long (around 500 bits depending on the model) and are hard to decode.