Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RC5 IR remote decoder using 12 LEDs
60 views
Skip to first unread message
Bill Bowden
Nov 5, 2012, 12:39:51 AM11/5/12
to
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
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
Jasen Betts
Nov 5, 2012, 4:12:40 AM11/5/12
to
On 2012-11-05, Bill Bowden <bpe...@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.
> 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?
missle of each bit and use that change to trigger your bit clock.
>
> Thanks,
>
> -Bill
--
⚂⚃ 100% natural
Frnak McKenney
Nov 5, 2012, 10:28:47 AM11/5/12
to
On Sun, 4 Nov 2012 21:39:51 -0800 (PST), Bill Bowden <bpe...@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.
[...]
> 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.
> ... 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?
Bill,
> sort of clock to sample the data at the right time?
If you're doing this for the sheer enjoyment of the exercise, please
feel free to skip this particular post. <grin!>
On the other hand, if your goal is to simply detect,record, or send
RC5-format messages, you might consider investing $20 in this gadget
or something like it:
USB Infrared Toy v2
<http://www.seeedstudio.com/depot/usb-infrared-toy-v2-p-831.html?cPath=174>
Infrared Toy v2 hardware design overview
http://dangerousprototypes.com/docs/USB_IR_Toy_v2
Hope this helps...
Frank
--
Nearly every feature of the American system of manufacturing, from
the elements of the new textile machinery to the concept of
interchangable parts, had actually been conceived earlier by
Europeans. But while a few Europeans could see the possibilities,
their communities kept them powerless to give their ideas a free
trial. Too many had a stake in the older ways. Industrial progress
in Europe required extraordinary courage to break the prevailing
pattern; in America it required a willingness to try the obvious.
American genius was less for invention or discovery than for
experiment.
-- Daniel J. Boorstin / The Americans: The National Experience
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com
tuinkabouter
Nov 5, 2012, 2:35:46 PM11/5/12
to
--
pim.
Bill Bowden
Nov 11, 2012, 10:57:46 PM11/11/12
to
On Nov 5, 1:12 am, Jasen Betts <ja...@xnet.co.nz> wrote:
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
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
John Fields
Nov 12, 2012, 8:36:13 AM11/12/12
to
I think there is; pretty easy anyway.
Since the first start bit signals the beginning of a data frame and is
valid for 889µs, generating a clock stream with the first rising edge
delayed by 444.5µs from the rising edge of the start bit and having
14 successive rising edges 1.778ms apart would capture all 14 bits if
used as the data clock of a shift register 14 bits wide.
Then, generating a narrow pulse a little after the rising edge of the
14th data clock pulse would allow the data captured in the shift
register (using something like a couple of HC594s) to be latched and,
if displayed using LEDs on the latched outputs, would appear to be
solidly illuminated or not.
The latching pulse would also be used to reset the clock generator,
counter, and data shifter (but not the latch) to wait until the next
start bit came by and started the cycle anew.
It also seems possible that, since the shift register would be reset
on power-up, the start bit appearing at Q14 could be used to clock the
latch, reset the shift register and clock generator, and eliminate the
counter.
Sounds fun... I'll simulate it and post what I find later on today.
--
JF
Jasen Betts
Nov 12, 2012, 2:37:38 AM11/12/12
to
On 2012-11-12, Bill Bowden <bpe...@bowdenshobbycircuits.info> wrote:
> On Nov 5, 1:12 am, Jasen Betts <ja...@xnet.co.nz> wrote:
>
>> 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
The middles are approx 1.778ms apart, so at each middle start a one-shot
> On Nov 5, 1:12 am, Jasen Betts <ja...@xnet.co.nz> wrote:
>
>> 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
that runs for 1.3ms, while it's on ignore every transition.
> but I thought there might be an easy hardware solution.
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.
--
⚂⚃ 100% natural
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
David Eather
Nov 12, 2012, 11:21:36 AM11/12/12
to
running a interpreted basic and can be programed using a usb port (+
cable) or RS232 plus 3 resistors. It has built in commands to send and
receive Manchester codes
http://www.picaxe.com/BASIC-Commands/Digital-InputOutput/infraout/
Daniel Pitts
Nov 12, 2012, 7:12:34 PM11/12/12
to
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 :-).
John Fields
Nov 21, 2012, 8:23:09 AM11/21/12
to
Bill,
I've posted some related stuff for you at abse under message ID:
news:glkpa8h2qb9qb4iub...@4ax.com
--
JF
Bill Bowden
Dec 1, 2012, 9:54:24 PM12/1/12
to
On Nov 21, 5:23 am, John Fields <jfie...@austininstruments.com> wrote:
> On Sun, 4 Nov 2012 21:39:51 -0800 (PST), 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. 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
>
> On Sun, 4 Nov 2012 21:39:51 -0800 (PST), 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. 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
>
> Bill,
>
> I've posted some related stuff for you at abse under message ID:
>
> news:glkpa8h2qb9qb4iub...@4ax.com
>
> --
> JF-
>
> I've posted some related stuff for you at abse under message ID:
>
> news:glkpa8h2qb9qb4iub...@4ax.com
>
> --
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
John Fields
Dec 1, 2012, 11:23:46 PM12/1/12
to
I don't know how to do that either.
Helmut Sennewald is the right person to ask, and he moderates:
http://groups.yahoo.com/group/LTspice/
and is at:
helmuts...@yahoo.com
--
JF
John Fields
Dec 2, 2012, 7:40:12 AM12/2/12
to
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.
--
JF
Bill Bowden
Dec 4, 2012, 11:25:42 PM12/4/12
to
On Dec 2, 4:40 am, John Fields <jfie...@austininstruments.com> wrote:
> On Sat, 01 Dec 2012 22:23:46 -0600, John Fields
>
> On Sat, 01 Dec 2012 22:23:46 -0600, John Fields
>
>
> ---
> 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.
>
> --
> JF-
> ---
> 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
John Fields
Dec 5, 2012, 4:01:29 PM12/5/12
to
On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden
<bpe...@bowdenshobbycircuits.info> wrote:
>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.
---
<bpe...@bowdenshobbycircuits.info> wrote:
>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.
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.
---
>Need more time to study it all.
May I offer a circuit description?
--
JF
Bill Bowden
Dec 5, 2012, 10:08:53 PM12/5/12
to
On Dec 5, 1:01 pm, John Fields <jfie...@austininstruments.com> wrote:
> On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden
>
> On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden
>
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
John Fields
Dec 6, 2012, 7:20:45 AM12/6/12
to
On Wed, 5 Dec 2012 19:08:53 -0800 (PST), Bill Bowden
<bpe...@bowdenshobbycircuits.info> wrote:
---
The HC191 (U7) down-counts the 12 serial data clocks output from U3-4,
and when it gets to 0, latches the data accumulated by U8 and U9 into
their outputs, disables itself as well as U4 and U5, and drives U1-2
high.
If the data LSB is 1 at the time, then 445盜 later it'll go low, the
RS latch U1a/U1b will be reset, and the circuit will wait until for
the next start bit to begin a new data acquisition cycle.
If the data LSB is 0 at the time, however, U1a/U1b will be reset as
soon as U7 counts down to zero, and the circuit will wait for the next
start bit to start a new cycle.
--
JF
<bpe...@bowdenshobbycircuits.info> wrote:
The HC191 (U7) down-counts the 12 serial data clocks output from U3-4,
and when it gets to 0, latches the data accumulated by U8 and U9 into
their outputs, disables itself as well as U4 and U5, and drives U1-2
high.
If the data LSB is 1 at the time, then 445盜 later it'll go low, the
RS latch U1a/U1b will be reset, and the circuit will wait until for
the next start bit to begin a new data acquisition cycle.
If the data LSB is 0 at the time, however, U1a/U1b will be reset as
soon as U7 counts down to zero, and the circuit will wait for the next
start bit to start a new cycle.
--
JF
John Fields
Dec 7, 2012, 7:50:57 AM12/7/12
to
On Thu, 06 Dec 2012 06:20:45 -0600, John Fields
<jfi...@austininstruments.com> wrote:
>---
>The HC191 (U7) down-counts the 12 serial data clocks output from U3-4,
>and when it gets to 0, latches the data accumulated by U8 and U9 into
>their outputs, disables itself as well as U4 and U5, and drives U1-2
>high.
>
>If the data LSB is 1 at the time, then 445盜 later it'll go low, the
>RS latch U1a/U1b will be reset, and the circuit will wait until for
>the next start bit to begin a new data acquisition cycle.
>
>If the data LSB is 0 at the time, however, U1a/U1b will be reset as
>soon as U7 counts down to zero, and the circuit will wait for the next
>start bit to start a new cycle.
>
>
---
<jfi...@austininstruments.com> wrote:
>---
>The HC191 (U7) down-counts the 12 serial data clocks output from U3-4,
>and when it gets to 0, latches the data accumulated by U8 and U9 into
>their outputs, disables itself as well as U4 and U5, and drives U1-2
>high.
>
>If the data LSB is 1 at the time, then 445盜 later it'll go low, the
>RS latch U1a/U1b will be reset, and the circuit will wait until for
>the next start bit to begin a new data acquisition cycle.
>
>If the data LSB is 0 at the time, however, U1a/U1b will be reset as
>soon as U7 counts down to zero, and the circuit will wait for the next
>start bit to start a new cycle.
>
>
Oops!
I think I found an error.
I'll work on it and post what I find.
--
JF
John Fields
Dec 7, 2012, 2:06:59 PM12/7/12
to
On Fri, 07 Dec 2012 06:50:57 -0600, John Fields
---
My error; no error ;)
--
JF
My error; no error ;)
--
JF
Jim Thompson
Dec 7, 2012, 2:12:05 PM12/7/12
to
On Fri, 07 Dec 2012 13:06:59 -0600, John Fields
What was that all about? Bait to entice Larkin to claim a digital
hazard, so you could whack him ?>:-}
...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
hazard, so you could whack him ?>:-}
...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
John Fields
Dec 7, 2012, 2:47:58 PM12/7/12
to
Larkin?
What is this "Larkin" to which you refer?
What it's all about is that Bill Bowden and I have been having a
civilized discussion about a remote control decoder, he asked about
how the start bit got everything going and I thought, after having
posted the explanation, that I'd made a mistake.
When I see something that looks like I've made an error I like to post
about it immediately in case anyone has plans for realizing the
circuit in hardware, and if I find later that I was wrong about being
wrong, (as in this case) then no harm done when I post a retraction.
--
JF
Jim Thompson
Dec 7, 2012, 4:23:34 PM12/7/12
to
On Fri, 07 Dec 2012 13:47:58 -0600, John Fields
It's a virus that's been infected by a trojan ;-)
>
>What it's all about is that Bill Bowden and I have been having a
>civilized discussion about a remote control decoder, he asked about
>how the start bit got everything going and I thought, after having
>posted the explanation, that I'd made a mistake.
>
>When I see something that looks like I've made an error I like to post
>about it immediately in case anyone has plans for realizing the
>circuit in hardware, and if I find later that I was wrong about being
>wrong, (as in this case) then no harm done when I post a retraction.
>
>What it's all about is that Bill Bowden and I have been having a
>civilized discussion about a remote control decoder, he asked about
>how the start bit got everything going and I thought, after having
>posted the explanation, that I'd made a mistake.
>
>When I see something that looks like I've made an error I like to post
>about it immediately in case anyone has plans for realizing the
>circuit in hardware, and if I find later that I was wrong about being
>wrong, (as in this case) then no harm done when I post a retraction.
0 new messages