To copy and send a code

[humanus]

I want to copy just a single command of a remote for air conditioner into a PIC and later resend it by this PIC. How will it be possible? How can I find the exact timings of a this kind of remote's code? Will it be enough If I send the same timing, i.e. the same periods and pulse widths through an output of the PIC (let's say 12F629) to execute the same command.

[ElizabethD]

Is this PIC description what you speak of http://en.wikipedia.org/wiki/PIC_microcontroller ?
What Air conditioner?
What specific function do you want to send?

There are jp1 upgrades in the file section (see above). if you can find something related to what you're asking the experts might suggest what timings make sense and how the signal should be structured.
Do you have a learning remote or two? You could record a signal from any to a learning remote, then examine the signals. To do so you'll need jp1 cables, which I suspect you do not have.

[cauer29]

I want to copy just a single command of a remote for air conditioner into a PIC and later resend it by this PIC. How will it be possible? How can I find the exact timings of a this kind of remote's code? Will it be enough If I send the same timing, i.e. the same periods and pulse widths through an output of the PIC (let's say 12F629) to execute the same command.

Yes, if you duplicate the timing reasonably closely, it should work. There is a small possibility that the protocol in question changes one or more bits from one button press to the next, but I wouldn't expect this on something like an air conditioner. As for how you can find out the timing for this particular AC, if you can capture the signal via one means or another, then you should be able to duplicate it.

Many folks here use something called a "widget" which is a special made device for exactly these sorts of things. If you want to really cheap out, you can get away with just connecting an IR LED across the microphone input on a PC and fire the original remote at it, whilst "recording" on the PC. You won't be able to find out the pulse frequency, but you can at least measure the on/off baseband modulation. The pulse frequency is rarely that critical and 38KHz works for most applications, even if it might not have the ultimate range.

On a final note, if you tell us the make/model of AC, we may be able to tell you the particulars of the IR protocol used.

A.A.

[humanus]

Many thanks for the aswers. The air conditioner is Daikin. Model is FTY453.

[vickyg2003]

We don't have an upgrade here, but there is a CCF file over at remote central for the Daikin Airconditioner

[cauer29]

Many thanks for the aswers. The air conditioner is Daikin. Model is FTY453.

From the link that Vicky provided, here is the pronto hex for the off button:

Code: Select all

0000 006e 00db 0001 0080 0041 000f 0031 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0031 000f 0031 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0031 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0456 0080 0041 000f 0031 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0031 000f 0031 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0031 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0011 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0011 000f 0031 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0031 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0011 000f 0031 000f 0031 000f 0031 000f 0031 000f 0031 000f 0e98

There is a doc here in the file section that describes the pronto hex format. From that, you can decipher the details that you need to replicate this with a PIC. There are 8 other buttons in the ccf, heat, cool, auto, power heat, power cool, power auto, fan, dry. If you tell me which button you need, I can extract the pronto hex for that button from the ccf.

A.A.

[johnsfine]

I don't have time to go through that CCF to confirm or contradict any of the following, but the one signal you posted looks generally like other AC signals that tend to have the following big problem and further complication:

1) The actual signal is usually too long for a learning remote to learn, so the signals posted in CCF files often don't work and represent only the beginning of a correct signal.

2) Usually the remote remembers the entire state of the AC, so a button to make a specific state change (such as one step cooler) doesn't send a command specific to that button. Instead the button changes the state stored inside the remote and then the remote sends a signal that encodes every aspect of the new state (both changed and unchanged aspects).

[The Robman]

So humanus, if we give you the carrier frequency and the timings for the burst pairs, do you know what to do in order to program that info into your PIC?

Here's some of the info:

leadin: +3400 -1724
ONE: +400 -1300
ZERO: +400 -450
leadout1: +400 -29456
leadout1: +400 -99142

The signal is sent in two parts. The first part is 8 bytes long and fixed.

The second part is 19 bytes long with some bytes fixed and some that vary.

Is that the info you need? If so, I'll give you the data for each button, keeping in mind what John said that these codes might be exactly as advertised.

[cauer29]

I don't have time to go through that CCF to confirm or contradict any of the following, but the one signal you posted looks generally like other AC signals that tend to have the following big problem and further complication:

1) The actual signal is usually too long for a learning remote to learn, so the signals posted in CCF files often don't work and represent only the beginning of a correct signal.

2) Usually the remote remembers the entire state of the AC, so a button to make a specific state change (such as one step cooler) doesn't send a command specific to that button. Instead the button changes the state stored inside the remote and then the remote sends a signal that encodes every aspect of the new state (both changed and unchanged aspects).

If the signal is too long for a learning remote, then a widget or homebrew capture device is in order.

If the remote is an integral part of the AC system, then only a complete reverse-engineering of how it works, is going to be effective.

Perhaps it would be easier just to make the PIC electrically "press" the button on the existing remote?

A.A.

[humanus]

Could anyone tell me which protocol air conditioner remotes( e.g. Daikin)use? Isn't this code that Vicky supplied a standart one like (RC5, NEC, etc.) Sorry, my question will be somewhat nonsense for you, but I am a real newbie about these remote protocols.

[humanus]

So humanus, if we give you the carrier frequency and the timings for the burst pairs, do you know what to do in order to program that info into your PIC?

Here's some of the info:

leadin: +3400 -1724
ONE: +400 -1300
ZERO: +400 -450
leadout1: +400 -29456
leadout1: +400 -99142

The signal is sent in two parts. The first part is 8 bytes long and fixed.

The second part is 19 bytes long with some bytes fixed and some that vary.

Is that the info you need? If so, I'll give you the data for each button, keeping in mind what John said that these codes might be exactly as advertised.

As I examined some other standart protocols I saw that no other protocol has so much bytes. What may be the reason for such a long code?
If I can find the exact timings, for example the "ON" button, I can rebuild it by program with a PIC. I do not need any carrier frequency. Because I will use the IR demodulator output of a TSOP type in order to enter the signal rebuilt. I just need the timings of the whole "ON" signal .

[cauer29]

So humanus, if we give you the carrier frequency and the timings for the burst pairs, do you know what to do in order to program that info into your PIC?

Here's some of the info:

leadin: +3400 -1724
ONE: +400 -1300
ZERO: +400 -450
leadout1: +400 -29456
leadout1: +400 -99142

The signal is sent in two parts. The first part is 8 bytes long and fixed.

The second part is 19 bytes long with some bytes fixed and some that vary.

Is that the info you need? If so, I'll give you the data for each button, keeping in mind what John said that these codes might be exactly as advertised.

As I examined some other standart protocols I saw that no other protocol has so much bytes. What may be the reason for such a long code?
If I can find the exact timings, for example the "ON" button, I can rebuild it by program with a PIC. I do not need any carrier frequency. Because I will use the IR demodulator output of a TSOP type in order to enter the signal rebuilt. I just need the timings of the whole "ON" signal .

I think that an explanation was given already and that was that the remote may not send a simple repeatable stream for a given button press. If that is the case, then what you're trying to do, is going to be a lot more complicated, as you will need to reverse-engineer the operation of the remote in order to duplicate exactly what the remote is sending from one key press to the next.

That said, your talk of using a TSOP IR demodulator, is confusing me. Are you trying to capture what the remote is sending? I thought the goal here was to use the PIC to replicate what the remote sends, in which case, you need a modulator, not a demodulator. If you're just trying to capture what the remote is sending so that you can figure out how to replicate the signal, then I wouldn't bother programming a PIC to do the capture. That's just re-inventing the wheel here. Get yourself a proper widget, or wire up the output of this TSOP IR demod to the line input of your soundcard and use an audio recording program to record the signal. It will look a little wonky due to the ac coupling, but it will be very precise in terms of the on and off timings of the bursts. I'm assuming here, that you don't have access to a digital storage scope.

A.A.

[johnsfine]

As I examined some other standart protocols I saw that no other protocol has so much bytes. What may be the reason for such a long code?

That seems to be the way protocols for Air Conditioners are designed (much longer signals than those in ordinary IR protocols).

If I can find the exact timings, for example the "ON" button

As I explained before, there might not be a signal associated with the "ON" button. Instead, each complete state of the system may have an IR signal associated with it. So if you press "ON" the remote may remember the complete state as it was before the AC was last turned off and may send a signal to recreate that state.

That might be exactly what you want. But might have unexpected results, especially once both the remote and the PIC are in use. Then an ON command would not restore the state the AC was actually in before being turned off. Instead it might restore the state the remote thought the AC had been in, ignoring all changes made by the other controlling device.

I do not need any carrier frequency. Because I will use the IR demodulator output of a TSOP type in order to enter the signal rebuilt.

I have only a guess at what you mean. If this guess is incorrect, please explain (our help will be incorrect if we misunderstand what you're trying to do).

You found the TSOP device inside the AC (that is used by the AC to receive the IR signal)? You plan to modify the AC itself so you can mix an electrical signal from the PIC into the output of the TSOP? You don't intend the signal from the PIC to be converted to IR and then back from IR to electrical. Instead the signal from the PIC will be wired directly into the AC?

[humanus]

As I examined some other standart protocols I saw that no other protocol has so much bytes. What may be the reason for such a long code?

That seems to be the way protocols for Air Conditioners are designed (much longer signals than those in ordinary IR protocols).

If I can find the exact timings, for example the "ON" button

As I explained before, there might not be a signal associated with the "ON" button. Instead, each complete state of the system may have an IR signal associated with it. So if you press "ON" the remote may remember the complete state as it was before the AC was last turned off and may send a signal to recreate that state.

That might be exactly what you want. But might have unexpected results, especially once both the remote and the PIC are in use. Then an ON command would not restore the state the AC was actually in before being turned off. Instead it might restore the state the remote thought the AC had been in, ignoring all changes made by the other controlling device.

I do not need any carrier frequency. Because I will use the IR demodulator output of a TSOP type in order to enter the signal rebuilt.

I have only a guess at what you mean. If this guess is incorrect, please explain (our help will be incorrect if we misunderstand what you're trying to do).

You found the TSOP device inside the AC (that is used by the AC to receive the IR signal)? You plan to modify the AC itself so you can mix an electrical signal from the PIC into the output of the TSOP? You don't intend the signal from the PIC to be converted to IR and then back from IR to electrical. Instead the signal from the PIC will be wired directly into the AC?

I may find a digital scope. But in order to have the precise timing which one is better according to your opinion? Can a scope display such a long bit stream? I have not used any one of them yet. However, many thanks for all of you. These are very useful replies for me.

[cauer29]

I may find a digital scope. But in order to have the precise timing which one is better according to your opinion? Can a scope display such a long bit stream? I have not used any one of them yet. However, many thanks for all of you. These are very useful replies for me.

Digital scopes can be had with 64 Megasamples or even more which is way more than you'd ever need length-wise. Such a scope would provide a trace with far greater accuracy than you're ever likely to get out of a PIC. Even the soundcard trick is going to top the accuracy you'll get with a PIC.

A.A.