Thank you, everyone who responded.  This is a great starting place for
me!  Once I have a working code snippet/circuit I plan on putting it on the
net for others to reap the beniffits from.  Again, I appreciate your help.

Scott


At 08:39 PM 2/23/2004, you wrote:
>Scott,
>
>On the sending end you can use on/off control of a 38Khz square wave or
>pulse stream. You can use a standard UART protocol for the data format.
>
>The PIC can be used to produce the 38Khz frequency, or you can relegate that
>job to a lowly 555 timer. The PIC would then control the output of the 555.
>One way is to connect output of 555 to 10k resistor to base of Q1 npn
>transistor. Q1 emitter to ground. Q1 collector to cathode of ir LED. LED
>anode connected via limiting resistor to +5. Base of Q1 connected to
>collector of npn Q2. Q2 emitter to ground. Base of Q2 via 10k resistor to
>PIC output pin. HIGH on PIC output will result in NO ir pulses. LOW on PIC
>output will allow ir pulses to be produced.
>
>At receiving end a standard 38Khz ir module would connect to PIC input pin.
>You may need inversion of signal by PIC to ensure that a HIGH out from
>transmitting PIC results in a HIGH received. Inversion (if needed) can be at
>either sending or receiving end.
>
>*************** Alternate IR Driver
>
>Alternately, you can have the PIC generating a 38Khz signal via an interrupt
>routine. The internal square wave signal would be sent to the proper PIC pin
>based on the state of a memory variable. If the state is HIGH, you would
>pass the square wave on to a PIC output pin. If it was LOW, you would output
>a LOW to the base of the IR driver transistor Q1. (in this case we don't
>need Q2, since Q1 would be directly driven by the PIC output).
>
>*********** FSK transmitter method
>
>The above deals with a 38Khz data carrier that is sometimes on, sometimes
>off. If you want, you can use Frequency Shift Keying (FSK) instead. Instead
>of turning the 38Khz output on and off, this method uses two different
>frequencies. One of the frequencies is within the capture range of the 38Khz
>receiver module. The other is far enough away from 38Khz that it is not
>locked onto by the receiver. In general, the time it takes to lock onto the
>38Khz frequency is shorter for FSK.
>
>The non-FSK method conserves power by having the LED off more than it is on.
>
>In all of the above methods you must ensure that a BIT time is long enough
>for the receiving IR module to produce a clearly distinguishable received
>waveform. For example, at 38Khz it might take 8 cycles to achieve lock, so
>error would be 8*100/38 = 21% (in this case a negative error). When
>switching from the 38Khz signal to 0 or out-of-lock frequency, it might take
>21% of a bit time before loss of lock occurs. If the error here is +21% then
>the TOTAL error is more like about 2% in the real world, with the received
>waveform being slightly delayed in time, but with only about 3% longterm
>timing error.
>
>If your data rate is too high, then lock error time begins to predominate.
>For example, if your DATA rate was equal to about 25% of your carrier
>frequency, then error soars to almost 100%
>
>Fr. Tom McGahee

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body