My Setup

Raspberry Pi

I have both an IR LED and a IR receiver hooked up to my Raspberry Pi Type B which is running Raspbian.

My Air Conditioner

I have a Daikin FTXS25DVMA split system air conditioner with the manufacturers remote (remote model: ARC433A46).

Home-made Oscilloscope

I also have made a home-made oscilloscope of sorts by soldering an IR Phototransistor to a cut headphone cable. This assembly is then connected to the microphone port of my Windows 7 computer. To view the waveforms of the IR signals and their timings I used software available here: www.ostan.cz/IR_protocol_analyzer/.

Types of Remotes

For this question there is an important distinction to be made between types of IR remotes. (I have no idea of their actual names if they have ones)

Button by Button

Firstly there is the common type which I am going to call 'Button by Button' which assigns a unique code or number to each button on the remote control. This code is sent every time that button is pressed (e.g. 'play' might send a code of 01010101 and 'stop' might send a code of 10101010)

Everything at Once

Secondly there is the type used with many air conditioners (like mine) which I am going to call 'Everything at Once'. This remote type sends every single setting on the remote every time a button is pressed. These codes are a lot longer than 'Button by Button' codes.


So here is my question: Does LIRC support 'Everything at Once' remotes? And, if so, how do I go about making a file for it? I can not get the irrecord command to work with the my air conditioner's remote (my guess is that irrecord doesn't support 'Everything at Once' remotes).

Receiving Signals from Manufacturers Remote

I have got this side of my project down. I have created a Python script which runs an instance of LIRC's mode2 command which reads the timings, converts them to binary then extracts the settings using the protocol below.

Sending Signals to Air Conditioner

This is the part I am struggling with. I have written a Python module in C which reads from a binary string then encodes and sends using the IR LED and delays. This however, as fine tuned as I could get it, didn't work when I pointed it at my air conditioner. When I pointed it at my IR receiver above it decoded the message no problem.

So, My thoughts are that my Python module isn't accurate enough and LIRC might be.

You can download my Python module here: onedrive.live.com/redir?resid=C604C49A28DD31D!23508&authkey=!AH_ye0xItEzO6T4&ithint=file%2c.zip. To install it run python setup.py install. To test it out run python test.py (default pin is GPIO PIN 4 but can be changed in test.py).

Daikin Protocol

I have posted my finds about the Daikin Protocol here.

Thanks, JamesStewy

  • Welcome to raspberrypi@stackexchange and thank you for an excellent and well researched question. I can't answer it right away, but I'm sure someone will look into it soon! I would like to ask you to remove the excellent Daikin Protocol documentation from this question, tough. It is, as you say, not really relevant here. Please create a new question that you can answer yourself with this documentation. (I.e. make a question "Is there any documentation for daikin", and answer yourself "Yes, here it is!") That way it's a lot easier to find.
    – Bex
    Apr 25, 2014 at 12:02
  • TL;DR. LIRC does support RAW mode, where it does try to interpret the ir pulses, but just remember their timings. Try running irrecord --force instead.
    – Gerben
    Apr 25, 2014 at 19:30
  • Bex - Fair Enough; Gerben - This is a confusion I have. Is 'RAW' (in terms of LIRC and irrecord) used to capture remotes I described above as 'Everything at Once' remotes?
    – JamesStewy
    Apr 26, 2014 at 2:26

4 Answers 4


The most accurate way to send pulses from the Pi is probably my pigpio library.

Examples include a Python morse code program transmitting to a LED, with the basic pulse length being 40 microseconds. The pulses can be as short as 1 microsecond.



I'm trying to do much the same with my own Daikin a/c. Haven't progressed as far as implementation as I was trying to get a handle on the codes first. I'm not sure how far you have progressed since April but a few things I have found that may be of use, if you haven't already discovered them.

Chris Rieger has an interesting project which appears to be well documented at Chris Riegler. This didn't really solve my problems as I wanted to get a better idea of the codes sent but his project is very similar to the one I am looking at. It certainly appears that lirc will work, though, but there a few items concerning a need to make sure that the formatting of lirc.conf is correct. As with all things electrical the manufacturers create their own protocols for each device and given the remote control IDs change with models I suspect that the IR codes may also. However I'm in the process of working through the codes from first principles at the moment and currently working out the header timings.

Alex Bain also has several pages, from early 2013, looking into getting lirc working and on this page there is a note that the kernel was updated early in 2014, and around the time you were having problems, which solved a problem with timings. Perhaps it is now working for you? Seem to be several working projects in the comments section with info.

  • Hi Tim, I have got to the point where, using pipgio I can send a message with an IR LED and it can be received by my IR receiver. I have also made a python script that works with lirc to decoded the message. My current sticking point however is my AC simply doesn't pick up the message sent by my IR LED as I don't know my ACs carrier frequency. I also realized my server is currently down so you probably didn't see my findings on my ACs protocol. Here is the word document instead.
    – JamesStewy
    Nov 27, 2014 at 22:41
  • Thanks for the document, I had the impression that others had managed to get Daikins working, particularly Chris Reiger, or do they change the carrier frequency on each model? I should add that I also had the IR receiver working on my W7 machine and was in the process of 'decoding'. This document will help.
    – Tim Barker
    Nov 29, 2014 at 1:49
  • I imagine they would change it around for different models but I will definitely will give those articles a read when I get some free time.
    – JamesStewy
    Nov 29, 2014 at 5:35
  • Think I'm having some success. Mind you it appears to be somewhat different. The aircon is a model FTY50GAV1A with a ARC423A17 remote.
    – Tim Barker
    Nov 30, 2014 at 23:25
  • Sorry, pressed enter in the middle of writing the comment. So here is the full comment:- Think I'm having some success. Mind you it appears to be somewhat different. The aircon is a model FTY50GAV1A with a ARC423A17 remote. So far :- Only 2 bursts of data, structure, 50 micros start bit followed by 20 micros trough. Then a fixed header of 7 bytes followed by the second burst, similar 50 micros + 20 micros peak/trough followed by 13 bytes of data. In the process of decoding the latter but at the moment it looks like the temps are not reversed decimal.
    – Tim Barker
    Nov 30, 2014 at 23:33

I've managed to document another Daikin remote control, or should I say almost fully document it. Details are as follows:

Daikin FTY50GAV1A ~12years old, a split system with a ARC423A17 remote control.

IR Receiver used:
Built on a TSOP4136 IR receiver purchased from Jaycar. Output to a 6mm jack socket which was then plugged into a professional audio DAC into my Windows machine. Individual commands recorded into WAV files and compared. Each wave file was flipped (phase reversed) before reading.

Much of the following uses your prior work on your Daikin remote with minor changes due to what is obviously an older remote. As you noted earlier decimal numbers seem to be reversed but the positions of your commands in the 'message' are different and there are only 2 bursts not 3. Each message sent from the remote consists of 2 byte streams with a short gap in between. Each byte stream consists of:-

1   a start bit peak of 50µs length
2   a start bit trough of 20µs
3   a stream of message bits where 0 is a 5µs peak followed by 10µs trough
                               and 1 is a 5µs peak followed by 20µs trough.
4   a final peak of 5µs

The first byte stream consists of a consistent fixed stream of bits on all commands as a header.

in bits <10001000 01011011 11100100 00001111 10110000 00000000 11110000>
in hex <88 5B E4 0F B0 00 F0>

The second byte stream consists of a constant length bit stream containing the encrypted commands in "All-at-once" form. I did note that occasionally the first "start bit peak" on ths stream was only 15-20µs in length rather than the standard 50µs in the table above. As I had no intention of using the in-built timer of the aircon I did not investigate these bytes which I assume in my case are bytes 8 and 9 of the 2nd message stream.

The second byte stream consists of a variable bit stream of constant length (13 bytes). The first 5 bytes (or 40 bits) are constant for all commands with the first 3 bytes a repeat of the first message

in bits <10001000 01011011 11100100 00000000 11001011>
in hex  <88 5B E4 00 CB>

Thereafter the bit stream depends on the parameters being set. Using your codes above

in bits <P000MMMM 100SVVVV 00000000 00000000 0TTTTT00 FFFF0000 00010000 CCCCCCCC>

I am still working on the checksum so if anybody has any suggestions... (oh, it doesn't appear to be same form as yours above).

P - 0 - turning system off    
    1 - turning system on

M - Mode of airconditioner
    1000 - Auto
    0100 - Dehumidify
    1100 - Cool
    0010 - Heat

S - 0 - Normal fan  
    1 - Powerful

V - 1000 - Normal Use
    1111 - Vanes rotating

T - Temperature - here it appears to be 5 bits long.  Take 10 degrees off the temp in celsius convert to binary and reverse the bit.  The temps available only run from 18 to 28.
    18 - 00010
    19 - 10010
    20 - 01010
    21 - 11010
    22 - 00110
    23 - 10110
    24 - 01110
    25 - 11110
    26 - 00001
    27 - 10001
    28 - 01001

F - Fan Speed
    Auto - 0101
    1    - 1100
    2    - 0010
    3    - 1010
    4    - 0110
    5    - 1110
  • This looks pretty similar to what I've decoded in mine. I found that reversing the bitstream made it easier to work on it, because the temperature, fan speed and timer settings made a bit more sense. Indeed, the temperatures were just the 5 bit value, and the timers are 12 bit "minutes until on/off": bitbucket.org/schinckel/daikin-controller/src/default/src/… Jun 15, 2018 at 12:24
  • Oh, and the checksum was the sum of all bytes, starting with bit 10, added together, minus 2, then & 0xFF. That was the main reason the bitstream needed to be reversed. Jun 15, 2018 at 12:26

Aircon remote commands in generally exceed the LIRC length limits. Lirc will allow you a maximum 64-bit header, 64-bit command, 64-bit tail. The header and tail are fixed.

For example, Olimpia remotes have a 96-bit command part so it is a total no-go.

The only way to do that is to drive the LIRC driver in the kernel yourself.

A detailed writeup on how to go about reverse engineering a remote (YMMV, you will probably fail and will resort to replaying mode2 recordings): https://primus.kot-begemot.co.uk/node/94

A detailed writeup on what it takes to replay an aircon remote on Raspberry Pi: https://primus.kot-begemot.co.uk/node/95

Tools of the trade to do the replay: https://github.com/kot-begemot-uk/lirc-replay

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.