RC5 IR remote decoder using 12 LEDs

[Bill Bowden]

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

 

[Jasen Betts]

On 2012-11-05, Bill Bowden <bperryb@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.

Thanks,

-Bill

--
⚂⚃ 100% natural

 

[Frnak McKenney]

On Sun, 4 Nov 2012 21:39:51 -0800 (PST), Bill Bowden <bperryb@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.

[...]

... 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,

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]

On 11/5/2012 6:39 AM, Bill Bowden 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?

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

--
pim.

 

[Bill Bowden]

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
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

 

[Jasen Betts]

On 2012-11-12, Bill Bowden <bperryb@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
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.

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[John Fields]

On Sun, 11 Nov 2012 19:57:46 -0800 (PST), Bill Bowden
<bperryb@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
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

---
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

 

[David Eather]

On Mon, 12 Nov 2012 13:57:46 +1000, Bill Bowden
<bperryb@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
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

PICAXE is a *very* easy solution to this problem. It is a micrprocesor
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]

On 11/11/12 7:57 PM, Bill Bowden 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
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 .

 

[John Fields]

On Sun, 4 Nov 2012 21:39:51 -0800 (PST), Bill Bowden
<bperryb@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:glkpa8h2qb9qb4iublijthvnlo5bb4pu1q@4ax.com


--
JF

 

[Bill Bowden]

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


Bill,

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

news:glkpa8h2qb9qb4iublijthvnlo5bb4pu1q@4ax.com

--
JF-

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]

On Sat, 1 Dec 2012 18:54:24 -0800 (PST), Bill Bowden
<bperryb@bowdenshobbycircuits.info> wrote:

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


Bill,

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

news:glkpa8h2qb9qb4iublijthvnlo5bb4pu1q@4ax.com

--
JF-

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

---
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:

helmutsennewald@yahoo.com


--
JF

 

[John Fields]

On Sat, 01 Dec 2012 22:23:46 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Sat, 1 Dec 2012 18:54:24 -0800 (PST), Bill Bowden
bperryb@bowdenshobbycircuits.info> wrote:

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


Bill,

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

news:glkpa8h2qb9qb4iublijthvnlo5bb4pu1q@4ax.com

--
JF-

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

---
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:

helmutsennewald@yahoo.com

---
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]

On Dec 2, 4:40 am, John Fields <jfie...@austininstruments.com> wrote:

On Sat, 01 Dec 2012 22:23:46 -0600, John Fields

jfie...@austininstruments.com> wrote:
On Sat, 1 Dec 2012 18:54:24 -0800 (PST), Bill Bowden
bper...@bowdenshobbycircuits.info> wrote:

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

Bill,


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

news:glkpa8h2qb9qb4iublijthvnlo5bb4pu1q@4ax.com

--
JF-


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

---

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:

 helmutsennew...@yahoo.com

---

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-

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]

On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden
<bperryb@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]

On Dec 5, 1:01 pm, John Fields <jfie...@austininstruments.com> wrote:

On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden

bper...@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

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

 

[John Fields]

On Wed, 5 Dec 2012 19:08:53 -0800 (PST), Bill Bowden
<bperryb@bowdenshobbycircuits.info> wrote:

On Dec 5, 1:01 pm, John Fields <jfie...@austininstruments.com> wrote:
On Tue, 4 Dec 2012 20:25:42 -0800 (PST), Bill Bowden

bper...@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

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

---
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ľs 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]

On Thu, 06 Dec 2012 06:20:45 -0600, John Fields
<jfields@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ľs 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]

On Fri, 07 Dec 2012 06:50:57 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Thu, 06 Dec 2012 06:20:45 -0600, John Fields
jfields@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ľs 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.

---
My error; no error

--
JF

 

[Jim Thompson]

On Fri, 07 Dec 2012 13:06:59 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Fri, 07 Dec 2012 06:50:57 -0600, John Fields
jfields@austininstruments.com> wrote:

On Thu, 06 Dec 2012 06:20:45 -0600, John Fields
jfields@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ľs 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.

---
My error; no error

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 | |
| Voice480)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.