Maker Pro
Maker Pro

RC5 IR remote decoder using 12 LEDs

B

Bill Bowden

Jan 1, 1970
0
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. 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?

Thanks,

-Bill
 
J

Jasen Betts

Jan 1, 1970
0
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.
 
T

tuinkabouter

Jan 1, 1970
0
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. 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?

Have a look at lirc. It can decode a lot of remote controls.
 
B

Bill Bowden

Jan 1, 1970
0
look up manchester code, because that's what you've got.


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
 
J

Jasen Betts

Jan 1, 1970
0
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

The middles are approx 1.778ms apart, so at each middle start a one-shot
that runs for 1.3ms, while it's on ignore every transition.
but I thought there might be an easy hardware solution.

Should be possible with 3 DIP parts and few passives on a 50 column
solderless breadboard.

http://lmgtfy.com/?q=manchester+code+decoder+hardware+schematic

The firat hit appears to be undergraduate lab notes from an Indian
university, the schematic has unreadable part numbers but may be
enough for inspiration.
 
D

Daniel Pitts

Jan 1, 1970
0
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
The change direction is what specifies the data value. The only
difficulty I can see is filtering out which transition is the "Data"
transition, and which one is just the boundary between two clocks.
Perhaps a PLL would help?

Take my comments with a grain of salt, as they are basically what I've
gleaned from a few minutes on Wikipedia :).
 
B

Bill Bowden

Jan 1, 1970
0
Bill,

I've posted some related stuff for you at abse under message ID:

John, the simulation worked fine but took several hours to complete.
My question now is how to save the simulation data so I can close
LTspice and come back later to review the simulation without starting
over. I didn't see an easy way to do this.

-Bill
 
B

Bill Bowden

Jan 1, 1970
0
I just found out how to do it.

If you've previously plotted the sim, there'll be a .raw file
corresponding to the .asc file, so all you have to do is click on the
.asc file for LTspice to bring up the schematic, right-click on the
background and then left-click on "Visible Traces" in the dialogue
box.

The plot pane will appear, and if you left-click in the drawing pane
the probe will appear when you get close to wires and you'll be able
to plot whatever you want to.

Yes, that works. I can get back to the sim without re-running it. I
downloaded the datasheets for the 595, 191, and 40103. Interesting
chips I haven't seen before. I guess you are counting down from 1778
to zero to get the strobe to see the data in the right place every
1.778 mS. Need more time to study it all.

Thanks,

-Bill
 
B

Bill Bowden

Jan 1, 1970
0
---
Exactly right.

Prior to that, however, the rising edge of the first start bit causes
4001 to be loaded into the counters so that after they count down 4001
clocks (4.001ms) they generate the first data clock in the middle of
the MSB.

After that, the RS flop U14-U15 changes state and sets up the
broadside load of 1778 into the counters for the remaining 11 bits.

Sure, if you want to write it up. I was wondering how the whole thing
got into sync on the rising edge of the start bit. That's the hard
part. I see an output at pin 1 of the 'HC32 or gate' which sets the
AB flip flop and controls the preset condition of the down counters.
The function of the HC191 is elusive. How does the circuit know when
the end of transmission occurs and it's time to reset and get ready
for the next transmission?

-Bill
 
Top