Noise problems with "Jeopardy" design... HELP!

M

Mike Deblis

Guest
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz setup for 8
people finished by thursday evening (quiz night at my kids school)... and my
EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001 "Circuit
improves on first event detection" - the CMOS (4013) version.

Just as I come to build the wretched device, which worked fine on
breadboard, I find that when built using multi-core cables that the other
button
sense lines seem to fire when one button is pressed, resulting in loads of
lights coming on even though the inhibit line drops correctly.

Using a 'scope show loads of spikes on the other button lines when another
button is pressed which is obviously causing the problem. I should also
mention that the multi-core cable also carries 300mA @12V to light some MES
bulbs in the button-pusher's box - I suspect that this maybe where the
cross-talk is coming from.

The PSU is clean, and each chip is decoupled by a 100n right underneath it.
Its built on VeroBoard, very neatly and cleanly. The veroBoard version
worked fine before I connected the long wires with the buttons and lights in
boxes (to sit in front of each contestant).

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem. WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?), or would switching to the TTL (74F74)
version of the circuit help? Would 74LS74 be any different to using the
74F74 for input rejection? Would stopping using multi-core and using
point-to-point 2 core be the answer?

I have so little time (I have a day job) that I really need solid advice
here...

My fragile credibility as a father is at stake here ;-) Sigh ;-(

Many thanks,

--
Mike
 
"Mike Deblis" <mdeblis@hotmail.com> wrote in message
news:qBbPb.17550$tQ6.749180@wards.force9.net...
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz setup for
8
people finished by thursday evening (quiz night at my kids school)... and
my
EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001
"Circuit
improves on first event detection" - the CMOS (4013) version.

Just as I come to build the wretched device, which worked fine on
breadboard, I find that when built using multi-core cables that the other
button
sense lines seem to fire when one button is pressed, resulting in loads of
lights coming on even though the inhibit line drops correctly.

Using a 'scope show loads of spikes on the other button lines when another
button is pressed which is obviously causing the problem. I should also
mention that the multi-core cable also carries 300mA @12V to light some
MES
bulbs in the button-pusher's box - I suspect that this maybe where the
cross-talk is coming from.

The PSU is clean, and each chip is decoupled by a 100n right underneath
it.
Its built on VeroBoard, very neatly and cleanly. The veroBoard version
worked fine before I connected the long wires with the buttons and lights
in
boxes (to sit in front of each contestant).

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem. WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?), or would switching to the TTL (74F74)
version of the circuit help? Would 74LS74 be any different to using the
74F74 for input rejection? Would stopping using multi-core and using
point-to-point 2 core be the answer?

I have so little time (I have a day job) that I really need solid advice
here...

My fragile credibility as a father is at stake here ;-) Sigh ;-(

Many thanks,

--
Mike
Click to expand...
Hi Mike,

Since the circuit worked with short wires, maybe the challenge is your long
wires in combination with the very high impedance inputs on the CMOS device.

A common design flaw with CMOS devices is leaving a input "open" (floating)
with a long wire lead connected to them. They will pick up any stray signal!
If that is the case, try a resistor at the 4013 CMOS end of the wire from
the input:

1) to ground if the circuit is low and pulled high by the button,
or
2) to V+ if the circuit is high and pulled low by the button.

I have found that for 5 volt supply, a few hundred ohms per input does the
trick. For 9 to 12 volts, maybe a few hundred more.

Hope that helps,

Tim
 
Tim Dicus wrote:

"Mike Deblis" <mdeblis@hotmail.com> wrote in message
news:qBbPb.17550$tQ6.749180@wards.force9.net...


Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz setup for


8


people finished by thursday evening (quiz night at my kids school)... and


my


EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001


"Circuit


improves on first event detection" - the CMOS (4013) version.

Just as I come to build the wretched device, which worked fine on
breadboard, I find that when built using multi-core cables that the other
button
sense lines seem to fire when one button is pressed, resulting in loads of
lights coming on even though the inhibit line drops correctly.

Using a 'scope show loads of spikes on the other button lines when another
button is pressed which is obviously causing the problem. I should also
mention that the multi-core cable also carries 300mA @12V to light some


MES


bulbs in the button-pusher's box - I suspect that this maybe where the
cross-talk is coming from.

The PSU is clean, and each chip is decoupled by a 100n right underneath


it.


Its built on VeroBoard, very neatly and cleanly. The veroBoard version
worked fine before I connected the long wires with the buttons and lights


in


boxes (to sit in front of each contestant).

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem. WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?), or would switching to the TTL (74F74)
version of the circuit help? Would 74LS74 be any different to using the
74F74 for input rejection? Would stopping using multi-core and using
point-to-point 2 core be the answer?

I have so little time (I have a day job) that I really need solid advice
here...

My fragile credibility as a father is at stake here ;-) Sigh ;-(

Many thanks,

--
Mike





Hi Mike,

Since the circuit worked with short wires, maybe the challenge is your long
wires in combination with the very high impedance inputs on the CMOS device.

A common design flaw with CMOS devices is leaving a input "open" (floating)
with a long wire lead connected to them. They will pick up any stray signal!
If that is the case, try a resistor at the 4013 CMOS end of the wire from
the input:

1) to ground if the circuit is low and pulled high by the button,
or
2) to V+ if the circuit is high and pulled low by the button.

I have found that for 5 volt supply, a few hundred ohms per input does the
trick. For 9 to 12 volts, maybe a few hundred more.

Hope that helps,

Tim



Mike,
Click to expand...
Is your cable composed of twisted pairs? Or just multiple wires? If it
just multiple wires, then you can think of each of the wires as an
antenna waiting to pick up any noise around them. Tim's idea of
terminating the wires will help a lot to keep the inputs to a known
state. If you are going to be using these buttons in a studio or
auditorium, you might want to invest in using wire with twisted pairs so
that you can at least ground the other wire in each pair going to your
switch boxes. This will cut down noise.

I once had a PFH (Project From Hell) that had a problem with wiring. It
was a control system for a large auditorium. I was the third and fifth
engineer assigned to the project (it kept being moved around as no one
really wanted to do it!) When I finally tried to implement it, I found
that the wiring that had been used was all single conductor, and had
about 200' runs of it all around a VERY EM noisy auditorium. Due to a
design constraint, the signalling was down with DTMF (Don't Ask!) but
there was so much noise on the cable in one of the four rooms, you could
not get reliable signalling, even filtering the heck out of the signal!
If it had been twisted pair, it would have been no problem.

Charlie
Edmondson Engineering
Unique Solutions to Unusual Problems
 
"Charles Edmondson" <cedmonds@cadence.com> wrote in message
news:400d6593$1@news.cadence.com...
Is your cable composed of twisted pairs? Or just multiple wires? If it
just multiple wires, then you can think of each of the wires as an
antenna waiting to pick up any noise around them. Tim's idea of
terminating the wires will help a lot to keep the inputs to a known
state. If you are going to be using these buttons in a studio or
auditorium, you might want to invest in using wire with twisted pairs so
that you can at least ground the other wire in each pair going to your
switch boxes. This will cut down noise.
Click to expand...
Hi - Thanks for the replies...

The CMOS inputs (S input of a 4013) are all tied to ground with 10K at the
chip - they are pulled high by pressing a button.

I agree that having the power to the indicator lights in the same bundle is
a BAD PLAN as there is a 300mA pulse going up to the light in the selected
box, and a corresponding 300mA whack down the ground wire in the same
bundle - this means that all the boxes in the chain will see the pulse.

I suspect that I'll either have to star-wire or use a seperate bundle for
the light power, and try to keep the two cables apart (else I'll just have
the same problem).

It may be that daisy-chaining the boxes, whilst neat, is not such a good
idea...

Thanks

Mike
 
Mike Deblis wrote:
"Charles Edmondson" <cedmonds@cadence.com> wrote in message
news:400d6593$1@news.cadence.com...

Is your cable composed of twisted pairs? Or just multiple wires? If it
just multiple wires, then you can think of each of the wires as an
antenna waiting to pick up any noise around them. Tim's idea of
terminating the wires will help a lot to keep the inputs to a known
state. If you are going to be using these buttons in a studio or
auditorium, you might want to invest in using wire with twisted pairs so
that you can at least ground the other wire in each pair going to your
switch boxes. This will cut down noise.


Hi - Thanks for the replies...

The CMOS inputs (S input of a 4013) are all tied to ground with 10K at the
chip - they are pulled high by pressing a button.

I agree that having the power to the indicator lights in the same bundle is
a BAD PLAN as there is a 300mA pulse going up to the light in the selected
box, and a corresponding 300mA whack down the ground wire in the same
bundle - this means that all the boxes in the chain will see the pulse.

I suspect that I'll either have to star-wire or use a seperate bundle for
the light power, and try to keep the two cables apart (else I'll just have
the same problem).

It may be that daisy-chaining the boxes, whilst neat, is not such a good
idea...
Click to expand...
A 'star' configuration would probably be better.

Leon
--
Leon Heller, G1HSM
Email: aqzf13@dsl.pipex.com
My low-cost Philips LPC210x ARM development system:
http://www.geocities.com/leon_heller/lpc2104.html
 
"Mike Deblis" <mdeblis@hotmail.com> wrote in message
news:RQdPb.17650$tQ6.753254@wards.force9.net...
"Charles Edmondson" <cedmonds@cadence.com> wrote in message
news:400d6593$1@news.cadence.com...
Is your cable composed of twisted pairs? Or just multiple wires? If it
just multiple wires, then you can think of each of the wires as an
antenna waiting to pick up any noise around them. Tim's idea of
terminating the wires will help a lot to keep the inputs to a known
state. If you are going to be using these buttons in a studio or
auditorium, you might want to invest in using wire with twisted pairs so
that you can at least ground the other wire in each pair going to your
switch boxes. This will cut down noise.

Hi - Thanks for the replies...

The CMOS inputs (S input of a 4013) are all tied to ground with 10K at the
chip - they are pulled high by pressing a button.
(snip)
Click to expand...
Hi Mike,

I would recommend changing those pull-down resistors to 2K, maybe even to
1K, especially if the wires are long, unshielded, and unbalanced. You may
need to play with the resistance value a bit.

I will guess that switch bounce is not causing the trouble, or you would
have had that problem with short wires also. You are using the same
switches, correct?

Tim
 
I read in sci.electronics.design that Mike Deblis <mdeblis@hotmail.com>
wrote (in <qBbPb.17550$tQ6.749180@wards.force9.net>) about 'Noise
problems with "Jeopardy" design... HELP!', on Tue, 20 Jan 2004:

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem.
Click to expand...
Very likely.

WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?)
Click to expand...
Put capacitors from input to ground; experiment to find the minimum
value that works. If this causes driving problems, maybe you need to put
resistors in series before the capacitors.
--
Regards, John Woodgate, OOO - Own Opinions Only. http://www.jmwa.demon.co.uk
Interested in professional sound reinforcement and distribution? Then go to
http://www.isce.org.uk
PLEASE do NOT copy news posts to me by E-MAIL!
 
"Mike Deblis" <mdeblis@hotmail.com> wrote in message news:<qBbPb.17550$tQ6.749180@wards.force9.net>...
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz setup for 8
people finished by thursday evening (quiz night at my kids school)... and my
EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001 "Circuit
improves on first event detection" - the CMOS (4013) version.

Just as I come to build the wretched device, which worked fine on
breadboard, I find that when built using multi-core cables that the other
button
sense lines seem to fire when one button is pressed, resulting in loads of
lights coming on even though the inhibit line drops correctly.

Using a 'scope show loads of spikes on the other button lines when another
button is pressed which is obviously causing the problem. I should also
mention that the multi-core cable also carries 300mA @12V to light some MES
bulbs in the button-pusher's box - I suspect that this maybe where the
cross-talk is coming from.

The PSU is clean, and each chip is decoupled by a 100n right underneath it.
Its built on VeroBoard, very neatly and cleanly. The veroBoard version
worked fine before I connected the long wires with the buttons and lights in
boxes (to sit in front of each contestant).

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem. WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?), or would switching to the TTL (74F74)
version of the circuit help? Would 74LS74 be any different to using the
74F74 for input rejection? Would stopping using multi-core and using
point-to-point 2 core be the answer?

I have so little time (I have a day job) that I really need solid advice
here...

My fragile credibility as a father is at stake here ;-) Sigh ;-(

Many thanks,
Click to expand...
Mike, maybe it's time to dig into the capacitor junkbox and
capacitively slug down the inputs to the chips. Another solution may
be to condition the risetimes from your hard-contact switch closures
by inserting a series resistance driving a shunt capacitor at each
switch.

Nearly 40 years ago I learned the importance of not mixing hard
contact closures with fast logic the hard way, just as you evidently
are now doing. Since you're an EE, you should be able to appreciate
the fact that an unconditioned hard contact closure results in
nanosecond risetimes that freely couple inside your circuitry,
particularly when cables are involved.

This leaves you with two obvious solutions. Slow down the extreme
risetime created by the hard contact closure using a simple RC filter
very close to the switch, or de-sensitize the chip to the reception of
nanosecond impulses by slugging down the circuit at the chip end. Both
methods work, and sometimes both are needed! :)

A more elegant solution is to employ only SPDT switches that direct
set or reset a flop that provides a clean transition. Still, this is
what you do in design 2, but a few resistors and capacitors should be
sufficient to kludge design 1 into proper operation.

Enjoy. Isn't doing stuff with your kids fun! :)

Harry C.
 
Mike Deblis wrote:

I agree that having the power to the indicator lights in the same bundle is
a BAD PLAN as there is a 300mA pulse going up to the light in the selected
box, and a corresponding 300mA whack down the ground wire in the same
bundle - this means that all the boxes in the chain will see the pulse.
Click to expand...
You could use lower pullups/pulldowns to lower crosstalk. Maybe add an
RC filter to the IC input. And separate the signal ground and supply
from the power ground. You can then properly decouple the ICs, and the
ground bounces will be in the other ground line and at most cause a LED
flicker.

The good thing about the circuit is that the system is idle until the
first button is pressed. The others should be blocked at that instant. A
slicht RC delay will not make a difference here.

Thomas

I suspect that I'll either have to star-wire or use a seperate bundle for
the light power, and try to keep the two cables apart (else I'll just have
the same problem).
Click to expand...
A separate bundle may not be needed. Also take a look at cat5 data
cable; it has very little crosstalk between pairs.

It may be that daisy-chaining the boxes, whilst neat, is not such a good
idea...
Click to expand...
I think you have a bus that is idle until action, and at action
everything should block and only prevent false triggers.

Maybe even reversing the switches (normally closed) would work... much
lower impedance when it is not pressed yet...


Thomas
 
In news:qBbPb.17550$tQ6.749180@wards.force9.net,
Mike Deblis typed:
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz
setup for 8 people finished by thursday evening (quiz night at my
kids school)... and my EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001
"Circuit improves on first event detection" - the CMOS (4013) version.
Click to expand...
I don't know what that circuit looks like. Here's another, by Daniel
Simon in this group, for 8 inputs.

http://home.att.net/~mysub01/jeopardy_8-way_by_Daniel_Simon.gif


--
-Reply in group, but if emailing add 2 more zeros-
-and remove the obvious-
 
"Tom Del Rosso" <tdnews01@att.net.invalid> wrote:

In news:qBbPb.17550$tQ6.749180@wards.force9.net,
Mike Deblis typed:
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz
setup for 8 people finished by thursday evening (quiz night at my
kids school)... and my EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001
"Circuit improves on first event detection" - the CMOS (4013) version.

I don't know what that circuit looks like. Here's another, by Daniel
Simon in this group, for 8 inputs.

http://home.att.net/~mysub01/jeopardy_8-way_by_Daniel_Simon.gif
Click to expand...
It's already Wednesday so this may be too late, but here's a simple
design using cheap, low-power SCRs that I found in my files,
originally I believe from a Dave Thomas:

=========================
Here's a simple, cheap circuit that will let you conduct your very own
quiz shows. It has a lamp and a button for each player. When a button
is pressed, it lights that player's lamp and locks out the other
button until the circuit is reset.
SW3
+6V -o_|_o----+----------+----------->>--------+----------+----->>
| | | |
LAMP1 | | LAMP2
| | SW1 | SW2 |
+--A> |o <A-- o| |
| ==| --B> | |== <B--+
----- |o | | o| -----
SCR1 \ / | | | | \ / SCR2
\ / R3 ^ ^ R4 \ /
----- | CR1 CR2 | -----
| \ | | | | / |
| +--R2--+---+ +---+--R5--+ |
| | | |
| R1 R6 |
| | | |
GND ----------+---+----------------->>----------------+---+--->>

SW1,SW2 normally open momentary pushbuttons
SW3 normally closed momentary pushbutton
LAMP1, LAMP2 6V incandescent lamps
R1, R6 470 ohm
R2,R3,R4,R5 1 K
SCR1, SCR2 Small SCRs, not power type
CR1, CR2 1N914 diodes
+ connection
^ cathode of a diode
--A> <A-- are connected (jump)
--B> <B-- same deal

Circuit Description
When the circuit is first powered up (or after a reset -- same thing),
both SCR gates are held at ground potential by R1 and R6. Therefore,
neither SCR will latch up, and both lamps will be off. When one of
SW1 or SW2 is pressed, the corresponding SCR's gate is pulled high,
so the SCR latches on. Even if the switch is released, the SCR remains
latched, keeping the lamp illuminated. Diodes CR1 and CR2 ensure that
only one lamp may be on at a time. Once an SCR turns on, it forces
the other SCR's gate to remain at a low voltage, even if its switch
is pressed. It is probably possible to change the bulbs and the power
supply to 12V with no other circuit changes, but I have only built a
6V system. The circuit does not draw current when the lamps are off,
so it may be battery powered with no additional cutoff switch. I
built the whole thing in a plastic shoebox. Serving Suggestion: These
are great fun in elementary school classes, and as the whole thing
can be built for about $5, it's well worth letting the kids have fun
while they destroy it!
=========================


--
Terry Pinnell
Hobbyist, West Sussex, UK
 
Mike Deblis wrote:
Hi,

Bit of a problem - I've got to get a "fastest finger first" quiz setup for 8
people finished by thursday evening (quiz night at my kids school)... and my
EE background ended 20 years ago...

I've been using the circuit from EDN design Ideas, August 16th 2001 "Circuit
improves on first event detection" - the CMOS (4013) version.

Just as I come to build the wretched device, which worked fine on
breadboard, I find that when built using multi-core cables that the other
button
sense lines seem to fire when one button is pressed, resulting in loads of
lights coming on even though the inhibit line drops correctly.

Using a 'scope show loads of spikes on the other button lines when another
button is pressed which is obviously causing the problem. I should also
mention that the multi-core cable also carries 300mA @12V to light some MES
bulbs in the button-pusher's box - I suspect that this maybe where the
cross-talk is coming from.

The PSU is clean, and each chip is decoupled by a 100n right underneath it.
Its built on VeroBoard, very neatly and cleanly. The veroBoard version
worked fine before I connected the long wires with the buttons and lights in
boxes (to sit in front of each contestant).

Now, I suspect the multi-core cable is capacitively coupling the button or
light lines, causing mayhem. WHAT CAN I DO? I need to either improve the
noise immunity of the inputs (how?), or would switching to the TTL (74F74)
version of the circuit help? Would 74LS74 be any different to using the
74F74 for input rejection? Would stopping using multi-core and using
point-to-point 2 core be the answer?

I have so little time (I have a day job) that I really need solid advice
here...

My fragile credibility as a father is at stake here ;-) Sigh ;-(

Many thanks,

--
Mike
Click to expand...
Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch. This is why the EDN design idea requires separate cables
from each input to the corresponding player switch- a star configuration.
The basic circuit can be re-arranged to support a daisy-chain with
multi-core cable that allows for cross-coupling between wires. The
player switch inputs are routed to the FF D-inputs, the D-inputs are
OR'ed to trigger a one-shot, FFOS, and at the end of the one-shot
timeout, set for 100us, the FF CK inputs are strobed to capture the
valid input. The one-shot is then latched RST so that it will no longer
respond to additional player switch presses until the circuit is RST by
the momentary. Also, the circuit will not be glitched by your large
300mA lamp current going to the player lamps. The resulting circuit
consists mostly of what you already have in place with a single FF added.

Please view in a fixed-width font such as Courier.



+---------|>|---------+ '1'
| | |
+--- | '0' | |
| | | | o|
| | +---S--+ | |-RST
PSW0 -+ | | | | o|
+---o/o---cable-----+---+------D FF0 Q | |
| | | | 4013 | | |
| | \ | | | |
| === / +--CK /Q | |
| 10n 1k | | | | |
| | / | +---R--+ | |
| | | | | | |
| +---+ | +-------+---------+---------+
| | | | | | |
| --- | | | / |
| | O | | 10K |
| | | | / |
| | O | | \ |
| | | | | |
| | O | | | |
| | | | --- |
| | | | |
| +---------|>|---------+----------+ |
| | | | | |
| | | '0' | | |
| |\ | | | | | |
| | \ | | +---S--+ | | |
| PSWN _| \ | | | | | | |
+---o/o---cable-----+---+------D FFN Q | | |
| | | | | 4013 | | | |
| | \ | | | | | |
| === / +--CK /Q | | |
| 10n 1k | | | | | |
| | / | +---R--+ | | |
| | | | | | | |
| +---+ | +-------+ | |
| | | | |
| --- | '0' | |
| | | | |
| | +---S--+ | |
| | 47k | | | |
| --+ +--| +-/\/\----Q FFOS D-'1' | |
| | | | | | 4013 | | |
| | | | | 470p | | | |
| +--+ | +--||-+---/Q CK-+---+ |
| | | | | | | | |
| +-----|-----+ +---R--+ | \ |
| | | | === / |
+--cable--< VDD | | 100k | 470p 10k |
| +----/\/\-----+ | / |
| | | | |
| | +---+ |
| D1 | | |
| +-----|>|-----+ --- |
| | |
| | '0' |
| | | |
| | +---S--+ |
| | | | |
| +--Q FFMR D-'1 |
| | 4013 | |
| | | |
| /Q CK---+ |
| | | | |
| +---R--+ | |
| | | |
| +---------------------+
| |
+-------------------+
 
"Fred Bloggs" <nospam@nospam.com> wrote in message
news:400E8B0D.1030009@nospam.com...
Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch. This is why the EDN design idea requires separate cables
from each input to the corresponding player switch- a star configuration.
The basic circuit can be re-arranged to support a daisy-chain with
multi-core cable that allows for cross-coupling between wires. The
player switch inputs are routed to the FF D-inputs, the D-inputs are
OR'ed to trigger a one-shot, FFOS, and at the end of the one-shot
timeout, set for 100us, the FF CK inputs are strobed to capture the
valid input. The one-shot is then latched RST so that it will no longer
respond to additional player switch presses until the circuit is RST by
the momentary. Also, the circuit will not be glitched by your large
300mA lamp current going to the player lamps. The resulting circuit
consists mostly of what you already have in place with a single FF added.

Please view in a fixed-width font such as Courier.
....snip
Click to expand...

Many thanks - I've decided that the EPN circuit is far too unreliable to be
used, and decided to go with yours...

I was looking for a reference to the use of the 4013 as a monostable -
couldn't find one on the web and coundn't make it trigger - is the circuit
as posted correct?

I know I should experiment, but no time now (I've got only a couple of hours
of time left to getr this working...)

Thanks again

Mike
 
Mike Deblis wrote:
"Fred Bloggs" <nospam@nospam.com> wrote in message
news:400E8B0D.1030009@nospam.com...

Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch. This is why the EDN design idea requires separate cables
from each input to the corresponding player switch- a star configuration.
The basic circuit can be re-arranged to support a daisy-chain with
multi-core cable that allows for cross-coupling between wires. The
player switch inputs are routed to the FF D-inputs, the D-inputs are
OR'ed to trigger a one-shot, FFOS, and at the end of the one-shot
timeout, set for 100us, the FF CK inputs are strobed to capture the
valid input. The one-shot is then latched RST so that it will no longer
respond to additional player switch presses until the circuit is RST by
the momentary. Also, the circuit will not be glitched by your large
300mA lamp current going to the player lamps. The resulting circuit
consists mostly of what you already have in place with a single FF added.

Please view in a fixed-width font such as Courier.

...snip

Many thanks - I've decided that the EPN circuit is far too unreliable to be
used, and decided to go with yours...

I was looking for a reference to the use of the 4013 as a monostable -
couldn't find one on the web and coundn't make it trigger - is the circuit
as posted correct?

I know I should experiment, but no time now (I've got only a couple of hours
of time left to getr this working...)

Thanks again

Mike
Click to expand...
This type of one-shot is well known. Double check that S='0' and D='1'.
The timing waveforms look like this- Vn node is essentially same as R
input- your circuit uses the /Q output:

Please view in a fixed-width font such as Courier.

'0'
|
+---S--+
R | |
+----/\/\-------Q FFOS D-'1'
| | 4013 | +----
| Vc | | |
Vn +------||----+--/Q CK-+---+-----< |
| + - | | | | | |
OUT <-----|------------+ +---R--+ | \ ---+
| | === /
| 100k | 470p 10k
+----/\/\-----------+ | /
| |
+---+
|
---


FF is in '0' state with Q=Vdd and /Q=1 then Vc=-Vdd and Vn=0

CK trig puts D="1" onto Q=Vdd and /Q=0,Vn jumps from 0->-Vdd

Q output charges C thru R, so C charges from -Vdd to ~0.5*Vdd

at which point RST starts to activate to clear FF back to 0.

Vdd-(-Vdd)
Timing is then RxCx Ln (--------- )= RxCxLn(4)=1.4 x R x C
Vdd-0.5*Vdd



The waveforms look like so:


+----------------------------------
|
CLK |
|
-------+


+----------+
| |
Q | |
| |
--------+ +-------------------


--------+ +--------------------
| |
| |
/Q | |
+----------+


3Vdd | \
---- | \
2 | \
| \
| \
| \
| \
Vdd | \
--- | \
2 / \
Vn / \
/ \
0V--------+ / ---------
| / | |
| / |<-- ~5RC--> |
| / |
| / |
| / |
| / |
-Vdd|/ |
|<--1.4RC--->|
 
Fred Bloggs wrote:

FF is in '0' state with Q=Vdd and /Q=1 then Vc=-Vdd and Vn=0
Click to expand...
Should read Q=0 /Q=1 and Vn=0, the FF will not trigger unless S=R='0'
and D=1, so double check this before you test- it is a very reliable
circuit-especially for the very short timeout shown.
 
Fred Bloggs wrote:
Fred Bloggs wrote:


FF is in '0' state with Q=Vdd and /Q=1 then Vc=-Vdd and Vn=0


Should read Q=0 /Q=1 and Vn=0, the FF will not trigger unless S=R='0'
and D=1, so double check this before you test- it is a very reliable
circuit-especially for the very short timeout shown.
Click to expand...
Also, if you are testing with a square wave generator- use 50x the
timeout or frequency of less than 200Hz for trigger.
 
"Fred Bloggs" <nospam@nospam.com> wrote in message
news:400E8B0D.1030009@nospam.com...
....
Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch. This is why the EDN design idea requires separate cables
from each input to the corresponding player switch- a star configuration.
The basic circuit can be re-arranged to support a daisy-chain with
multi-core cable that allows for cross-coupling between wires. The
player switch inputs are routed to the FF D-inputs, the D-inputs are
OR'ed to trigger a one-shot, FFOS, and at the end of the one-shot
timeout, set for 100us, the FF CK inputs are strobed to capture the
valid input. The one-shot is then latched RST so that it will no longer
respond to additional player switch presses until the circuit is RST by
the momentary. Also, the circuit will not be glitched by your large
300mA lamp current going to the player lamps. The resulting circuit
consists mostly of what you already have in place with a single FF added.

Please view in a fixed-width font such as Courier.

[... snip ...]
Click to expand...

Fred,

Thanks for your help - The evening, last Thursday, was a great success - the
boxes worked
fine 95% of the time (one or two mis-fires! I'll sort those later), but the
whole system was very impressive. I added
a small piezo sounder and a 555 timer to give a different beep for each team
for about 0.5 secs.
The boxes, about 25cm x 10cm x 10cm from MDF with inset acrylic fronts and
the buttons on top looked the
part, and were much appreciated.

We raised about USD 750 for the school in Sri Lanka, so a good result all
round...

PS. fred, could you drop me a line at mdeblis at hotmail dotty com as I
would like to
ask you one question off line if possible...

Mike
 
"Fred Bloggs" <nospam@nospam.com> wrote in message
news:400E8B0D.1030009@nospam.com...
Mike Deblis wrote:
Bit of a problem - I've got to get a "fastest finger first" quiz setup
for 8
people finished by thursday evening (quiz night at my kids school)...
and my
EE background ended 20 years ago...
....
Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch.
....
Click to expand...

Fred,

I built this and it worked fine... except that if there is a switch bounce
as the monostable times out, i.e. a zero on the line that triggered to
monostable , no light comes on (the "0" is latched through) and what's more,
all buttons are now locked out. This happened a couple of times during the
evening we were using the boxes.

What's required is for the monostable to reset if no capture line is active
when it times out, i.e. to allow a subsquent "bounce" to re-fire the mono
and latch the button.

I've tried to find a simple solution for this, with not much luck.

Ideas welcome!

Thanks again,

Mike
 
Mike Deblis wrote:
"Fred Bloggs" <nospam@nospam.com> wrote in message
news:400E8B0D.1030009@nospam.com...

Mike Deblis wrote:

Bit of a problem - I've got to get a "fastest finger first" quiz setup

for 8

people finished by thursday evening (quiz night at my kids school)...

and my

EE background ended 20 years ago...

...

Your problem comes from the fact that the multicore cable in addition to
providing interconnections for all the signals is also a series of
capacitors coupling each wire to its adjacent wires. This is responsible
for the spikes you are seeing- press a single player switch, and a
voltage is transiently coupled into some other FF SET input causing a
false latch.

...

Fred,

I built this and it worked fine... except that if there is a switch bounce
as the monostable times out, i.e. a zero on the line that triggered to
monostable , no light comes on (the "0" is latched through) and what's more,
all buttons are now locked out. This happened a couple of times during the
evening we were using the boxes.

What's required is for the monostable to reset if no capture line is active
when it times out, i.e. to allow a subsquent "bounce" to re-fire the mono
and latch the button.

I've tried to find a simple solution for this, with not much luck.

Ideas welcome!

Thanks again,

Mike
Click to expand...
I find it difficult to believe this is happening- but a simple and
expedient fix is to condition the lockout on a D input being '1' like so:
Please view in a fixed-width font such as Courier.


CHANGE THIS:





----|>|-------+
from D |
inputs |
- |
---|>|-------+
|
|
|
to CK's |
|
/|\ '0' |
| | |
| +---S--+ |
| 47k | | |
--+ +--| +-/\/\----Q FFOS D-'1' |
| | | | | 4013 | |
| | | | 470p | | |
+--+ | +--||-+---/Q CK-+---+
| | | | | | |
+-----|-----+ +---R--+ | \
| | | === /
| | 100k | 470p 10k
| +----/\/\-----+ | /
| | | |
| | +---+
| D1 | |
| +-----|>|-----+ ---
| |
| | '0'
| | |
| | +---S--+
| | | |
| +--Q FFMR D-'1
| | 4013 |
| | |
| /Q CK---+
| | | |
| +---R--+ |
| | |
| +-------------< reset sw
| |
+-------------------+



TO THIS:


----|>|-------+
from D |
inputs |
- |
---|>|-------+
|
|
|
to CK's |
|
/|\ '0' |
| | |
| +---S--+ |
| 47k | | |
--+ +--| +-/\/\----Q FFOS D-'1' |
| | | | | 4013 | |
| | | | 470p | | |
+--+ | +--||-+---/Q CK-+---+
| | | | | | |
+-----|-----+ +---R--+ \ |
| | | / |
| | 100k | 1k |
| +----/\/\-----+ / |
| | | |
| | | |
| D1 | | |
| +-----|>|-----+ --- |
| | |
| | '0' |
| | | |
| | +---S--+ |
| | | | |
| +--Q FFMR D------------+
| | 4013 |
| | |
| /Q CK---+
| | | |
| +---R--+ |
| | |
| +-------------< reset sw
| |
+-------------------+
 
Try this. Not built or tested.

o V+ o V+
| |
.-. .-.
| | 1k | | 1k
| | | |
'-' '-'
| |
master | |
reset | Pos 1 |
_/ | .-----------. |
.-o/ o-| | | |
| S2 | GND ---+1 8+----V+ |
| | ___ | | |
| +|_R_|----+-----+2 7+--------------------o
GND | +-----| | 555 | _/ |
| | o--------+3 6+--------o-o/ o-----o
| --- | | | | S1 |
| C--- | V+ ---+4 5+----+ .|. |
| | | | | | | | |
| GND | | | --- | |100k |
| - '-----------' --- '-' |
| ^ LED | | |
| | |---+ |
| | GND |
| .-. |
| | | |
| | | |
| '-' |
| | |
| V+ |
| |
| |
'
To pos 2...N To pos 2...N
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top