>> On 2012-11-05, Bill Bowden <bper...@bowdenshobbycircuits.info> wrote:

>> > I'm attempting to construct an IR receiver circuit capable of
>> > receiving and displaying IR signals in binary format (using LEDs) from
>> > hand held IR remote controls. The protocol I'm interested in is the
>> > RC5 format originally developed by Phillips. The format consists of 2
>> > start bits followed by a toggle bit indicating a new key is pressed,
>> > followed by 5 address bits, and then 6 command bits for a total of 14
>> > bits. I plan to display the bits using 12 LEDs. The RC5 code uses a
>> > system where each bit is one cycle of equal time where a "1" is
>> > represented by the first half cycle
>> > being low followed by the second half cycle high and visa versa for a
>> > "0". This yields a weird waveform where the end of one bit may be the
>> > same level as the beginning of the next.

>> look up manchester code, because that's what you've got.

>> > What would be the best approach to decode the data using a couple
>> > shift registers and some sort of clock to sample the data at the  
>> right time?

>> esasiest decode is probably to rely on the state changing in the
>> missle of each bit and use that change to trigger your bit clock.

> Problem is, it's hard to see the middle of the bit when the levels may
> be changing at a 1.778 mS rate, or half that at a 889uS rate depending
> if the code is all ones or zeros, or alternating ones and zeros. Some
> of the clock edges may be missing, so it's hard to synchronize a
> clock. For example a code of all ones or zeros would be a series of
> narrow pulses, while a code of alternating ones and zeros would be a
> series of wider pulses. The total number of data edges is not
> constant. I think I might figure it out using a pic processor and
> measuring the time intervals between edges, but I thought there might
> be an easy hardware solution.

> Thanks,

> -Bill