Need to imitate an A/C IR remote

[Sceadwian]

Right, you use two timers, one PWM timer, and the other one set at the length of a bit. The exact frequency of the carrier signal is flexible because it's so low and even a slow PIC isn't going to have a problem generating the baud rate required with enough accuracy. Every time you get a compare match or an overflow on your bit length timer you set the PWM on or off based on table data. A LOT of instructions can be run in that idle time and the slight jitter that the running code creates is going to be negligible.

 

[Nigel Goodwin]

Don't you think that's a lot of work?, and for no good reason? - this is to create a remote control transmitter, you press a button and it sends out the data stream - there's nothing else happening while you're sending the datastream?, so no point.

By requiring PWM and two timers you're limiting the PIC's and I/O pins you can use - and only achieving a lower level of accuracy at the expense of much greater complexity.

 

[Sceadwian]

Who knows what else he might have his PIC doing? Sure if that's all the device is ever going to do then just writing up some delay loops and be done with it.

 

[mneary]

The original post said nothing about other functions. Scanning the keyboard wasn't mentioned, but probably isn't done while a code is being transmitted.

 

[Nigel Goodwin]

The original post said nothing about other functions. Scanning the keyboard wasn't mentioned, but probably isn't done while a code is being transmitted.

You don't scan the keyboard while you're sending data, what would be the point?.

 

[mneary]

I wouldn't scan the keyboard while sending data, but it seems like it would be something to caution against.

 

[Nigel Goodwin]

I wouldn't scan the keyboard while sending data, but it seems like it would be something to caution against.

Bit like cautioning not to take a bath while driving the car? - two activities that you wouldn't think of trying to do at the same time!.

 

[3v0]

I agree.

To some degree we keep building the same circuits over and over.
Does anyone recall a circuit called the Xanadu Zapper from some years back? It records and plays back IR remote signals.
FWIW The circuit can still be found here .

The original article has more info. I have a paper copy that I can scan if anyone is interested. I do not recall if it included code.

 

[winterhunter]

Thanks a lot for your input, guys!

To clear some points up:
+ I will be using an 16F877A PIC, since it is either that or a 18F (I have nothing else lying around here). So PWM could be an option (I must confess that it looks "elegant" - jsut a matter of taste, of course).
+ The first signal was measured using a 36 kHz decoder (which was sold to me as a 38 kHz one!). I'm now waiting for the correct one to arrive at my mailbox...
+ The signal I've posted was sampled using a photodiode. So we have carrier plus data.
+ The PIC will be doing other things but, even though I, as a matter of principle, do not like blocking code on a non multitasking system, it is OK for it to stay "blocked" for the 200 ms or so that the transmission seems to last.
+ Sceadwian is right, I don't need to decode the bitstream, just put the same signal out to control this damn A/Cs (my wife just "likes" to leave them on when she leaves for work - actually, even I forget to turn the three things, in different rooms, off). Understanding the coding method would be a nice bonus for me, but in no way essential.

Thanks again, I now think that with your help I'm on the right track!

 

[ardhuru]

Hi,

Sorry to enter this thread late, but here are some suggestions.

Use **broken link removed** to get a perfect display of the signal, alonwith the timing involved and also identify the protocol. This utility works brilliantly, but only on native serial ports, not USB-toRS232 cables.

Alternately, if you dont want to build the hardware, just connect a 3 pin IR demod. module to the line in on your PC and grab the signal using sound editors like Audacity (free) or Goldwave (shareware). This capture too can be picture perfect once you get the input level setting on the PC right.

Once you have this signal, it should not be too difficult to control a PWM output (running at your carrier frequency) by the desired sequence of 1s and 0s for the required pulse / space lengths.

Regards,

Anand

 

[winterhunter]

Hi everyone,
Thanks for all your answers.

However, the problem seems a little bit more difficult than I expected. Here's the current situation:

I have now a signal which, on the oscilloscope, looks pretty much the same as the signal generated by the IR, only difference being the carrier, which is 37,88 kHz instead of 38 kHz (38 kHz is not an exact fraction of any of the crystals I have here - best I can do is 37,88 kHz). The only other difference is that at 38 kHz all signal blocks are composed by an integer number of cycles (a 1 is 16 cycles oscillating and 16 cycle off) while to keep the same timing I get a fractional number of cycles (a 1 is 15 comma something cycles oscillating and the same amount off)

However, the XXXX (<--- please replace with your favorite expletive) air conditionner simply refuses to acknowledge the signal... I'm seriously beginning to think about "opening the hood" of the machine, and run two wires in parallel to the IR detector, and use a PIC with a 433 MHz module to feed the 2400 baud signal directly....

Any other clues? Can an off-the-shelf detector be so specific as to reject 37,88 kHz?

 

[mneary]

You say that you are generating 37,88 KHz and the receiver is refusing it because it insists on 38.00 KHz?

 

[ardhuru]

The IR module is not *that* critical of the carrier. If that was the only issue, it would work, albeit with a reduced range.

Also, the no. of carrier pulses within a pulse being 'non-integer' would not cause a problem, in my opinion, as the demodulation is an analog process within the module.

The problem lies elsewhere. Are you faithfully reproducing the preamble/start bit?

Also, are you sure your code is in fact generating a carrier of 37.88 khz?

Dont give up, we'll do this yet!

Regards,

Anand

 

[Nigel Goodwin]

Yes, the IR modules are not frequency critical at all, you're presumably not duplicating the signal correctly?.

 

[winterhunter]

@all:
I will double check on everything, as soon as I manage to get some free time.

Anyway, I will probably open the A/C just to check that they didn't just go the whole way on cost reduction and they did put a decoder (as opposed to wiring the microcontroller directly to a photodiode, in which case it could be VERY sensistive to frequency and number of cylces per pulse - Well, I'm just speculating here, maybe it makes no sense to eliminate the decoder).


@mneary, ardhuru :
The carrier I generate is at 37,87-37,88 as measured by my oscilloscope, and (in software) is equal to 132 cycles at 200 ns per cycle = 37,87879 kHz.

 

[winterhunter]

Firstly, I've stopped measuring the output signal on the PIC side, but with the same circuit (using a phototransistor) that I've used to capture the remote signal. That helped me realize that the signal strength was low, which was promptly solved with a NPN transistor.
I've then fine tuned the number of wait cycles on the timer (TMR1), and now the signal is correctly recognized.

Thanks a lot guys!!!!