Debouncing....at About 1Mhz

[Jim Thompson]

Jim Thompson wrote:

On Mon, 05 Nov 2007 09:05:29 -0800, D from BC


On Mon, 05 Nov 2007 07:05:08 -0800, John Larkin


[snip]

You don't like it for personal reasons. That's a bad basis for
engineering.

John

JL, I'm tempted to replace that RC section with a D ff...


I've been thinking all those lines also. I had a "perfect" ratty-edge
remover around here somewhere... now I can't find it :-(


The D ff will hold the previous settled state.
It can be clocked by a delay triggered by each edge.


Yep.


That way.. the circuit works from 1Mhz all the way down to 1Hz and
less.

Ok..if I hairballize your circuit a bit
D from BC


...Jim Thompson
Yeah, thinking about this, the problem definition becomes, instead of a
four state machine, a two state machine:

Detect tranistion, change output state
WAIT

Simple, and I am sure, full of gotchas, especially in that WAIT state... ;-)

Charlie

The wait state just has to exceed the worst-case undefined input time.

But then the signal is known and you don't need a circuit ;-)

...Jim Thompson

 

[John Fields]

On Mon, 05 Nov 2007 12:47:01 -0800, Charlie Edmondson

Jim Thompson wrote:

On Mon, 05 Nov 2007 09:05:29 -0800, D from BC


On Mon, 05 Nov 2007 07:05:08 -0800, John Larkin


[snip]

You don't like it for personal reasons. That's a bad basis for
engineering.

John

JL, I'm tempted to replace that RC section with a D ff...


I've been thinking all those lines also. I had a "perfect" ratty-edge
remover around here somewhere... now I can't find it :-(


The D ff will hold the previous settled state.
It can be clocked by a delay triggered by each edge.


Yep.


That way.. the circuit works from 1Mhz all the way down to 1Hz and
less.

Ok..if I hairballize your circuit a bit
D from BC


...Jim Thompson
Yeah, thinking about this, the problem definition becomes, instead of a
four state machine, a two state machine:

Detect tranistion, change output state
WAIT

Simple, and I am sure, full of gotchas, especially in that WAIT state... ;-)

Charlie

The wait state just has to exceed the worst-case undefined input time.

But then the signal is known and you don't need a circuit ;-)

 

[D from BC]

Now, I haven't done a full analysis on this circuit, but the biggest
drawback on being this edge triggered is the vulnerability of a noise
spike, esp. on that positive edge, giving a false trigger. That was why
I always appreciated those Moto debounce chips (for slower stuff) as it
debounced both edges equally. You just had to live with the delays...

Charlie

Fortunately in my app, I'm not expecting glitches in between the fuzz
to fuzz period (The steady state period.).


D from BC

 

[John Fields]

Fortunately in my app, I'm not expecting glitches in between the fuzz
to fuzz period (The steady state period.).

---
Lucky you!

From your earlier posts I understand that while the steady-state
period may vary, the fuzzy period will always be <=100ns.

Also, you've stated (AIUI) that the transitions in the fuzzy period
will be due to a ringing inductor.

Can you elaborate on that and, perhaps, post a schematic of the
circuit that's generating the problem to abse or a web page
somewhere?

It just may be that a/the solution for your problem lies somewhere
other than where you think it does.

 

[John Fields]

---
Lucky you!

From your earlier posts I understand that while the steady-state
period may vary, the fuzzy period will always be <=100ns.

Also, you've stated (AIUI) that the transitions in the fuzzy period
are due to a ringing inductor.

Can you elaborate on that and, perhaps, post a schematic of the
circuit that's generating the problem to abse or to a web page
somewhere?

It just may be that a/the solution for your problem lies somewhere
other than where you think it does...

 

[D from BC]

---
Lucky you!

From your earlier posts I understand that while the steady-state
period may vary, the fuzzy period will always be <=100ns.

Correct.

Also, you've stated (AIUI) that the transitions in the fuzzy period
will be due to a ringing inductor.

Correct.

Can you elaborate on that and, perhaps, post a schematic of the
circuit that's generating the problem to abse or a web page
somewhere?

Not until I have all the apostrophes correct.
But seriously..
I'd like to do a bunch of sims first and get the debounce circuit
installed.
Then I can post a schematic and demonstrate how the debounce circuit
is necessary and unavoidable.

It just may be that a/the solution for your problem lies somewhere
other than where you think it does.

Happens to me often, but hopefully not this time..


D from BC

 

[John Larkin]

On Mon, 05 Nov 2007 11:06:26 -0800, John Larkin

On Mon, 05 Nov 2007 10:17:23 -0600, John Fields

On Mon, 05 Nov 2007 07:05:08 -0800, John Larkin

On Mon, 05 Nov 2007 07:25:10 -0600, John Fields

On Sun, 04 Nov 2007 20:59:04 -0800, John Larkin


On Nov 4, 9:07 am, John Larkin
So, use a nonretriggerable monostable with rising clock

So what happens when a really fast spike fires both one-shots? What
happens when an edge comes in just about the time one or both
one-shots is timing out?

The problem, as stated, requires a circuit to operate in four
different phases:
Phase A: wait for a rising edge, go high when it does
Phase B: stay high, ignore edges for 'a while'
Phase C: wait for a falling edge, go low when it does
Phase D: stay low, ignore edges for 'a while'

So, something with two monostables or latches or whatever is required,
because the four states require two bits of state information. And
there are two time periods of some (presumably known) duration to
be part of the mix. It's required BY THE PROBLEM to have some
kind of one-shot to handle that timing, unless you can use higher-
speed

I posted a simple, fast circuit that works, is hazard-free, and has
few of the things that you say are "required by the problem."
Remember, the signal has states of its own, so the circuit doesn't
have to include all the states you enumerate.


Asynchronous logic can be scary, but this situation really calls for
it.

That's no reason to design hairballs.

---
Geez, if you want to see a hairball, take a look at your clock input
before the input signal gets stable!

It should be a roughly 10 ns positive pulse at every transition of the
input. The first such glitch clocks the r-c filtered data into the
dflop. Any additional glitches do the same thing. There's not even a
metastability hazard. This circuit is simple enough that a
humanly-possible analysis can demonstrate, with high confidence, that
it's safe.

You don't like it for personal reasons. That's a bad basis for
engineering.

---
On the contrary, I've used a similar circuit for years as a clean
transition detector:


.IN>---+----------A
. | EXOR Y-->OUT
. +--[R]-+---B
. |
. [C]
. |
. GND

The only thing I think that's wrong with your circuit is that at the
speed it's supposed to be used I think the EXOR chain is going to
generate a lot of hash as it follows the bouncing input.

I don't know what you mean by "hash." If you mean emi, well, any gate
that follows any signal generates "hash." Your circuits have lots of
logic transitions, too.

That's what this circuit was supposed to do.

There's no reason to supress them. The first clock strobes the correct
logic level into the flipflop, and the following clocks don't change
it. It does exactly what the OP requested.


You're flailing. No quad xor gate processing logic levels, in any
reasonable system, is going to break nearby components. You make it
sound like no digital system can ever work.

---


---
You need to get your hearing checked.
---


---
Of course, but what you're trying to do is dodge the issue that your
circuit will put out a lot more RFI because of the many fast
transitions it'll allow to propagate down the EXOR chain than it
would if only one, or a few, transitions were allowed.

The comparator is already making all those transitions. All I'm doing
is running them through one more ssi package. That seems to scare you
for some reason; it doesn't scare me.

Exactly in the same way (by trying to trivialize it) that you were
trying to avoid having to bite the bullet for having predicted the
output polarity of your circuit incorrectly.

The same-polarity output comes out of qbar. Big deal. The concept was
free, and works.

Like JT said, you're a sore loser.

Couldn't say. I haven't lost.

John

 

[JosephKK]

Fred Bartoli [email protected] posted to
sci.electronics.design:

Le Sun, 04 Nov 2007 08:17:33 -0800, JosephKK a écrit:

D from BC [email protected] posted to sci.electronics.design:

[snip]

Just do it in a modern CPLD, and 10nsec should be easy. Though
there's a bit of overhead getting started in CPLDs, it's cool that
when you make a mistake in your logic or see some improvement,
it's just a re-route.

For logic (if you are willing to get away from your SN7474 and
SN7486
parts...), you could use LVC parts at 5 volts. They're fast.

Cheers,
Tom

Thanks for the headsup for the future.

Did a quick read on
http://en.wikipedia.org/wiki/CPLD

:O .ohhhh that looks scary...

Is CPLD work more complicated than programming microcontrollers
with assembly?


D from BC

No, not really, just different.

When I was a kid I did program 6800/6809 in hexa (no assembler
available). Well one of my first tasks was writing a line editor and
an assembler, all that in hexa.

I certainly would not do that for CPLDs.

OW. That is ugly and painful just to think of.

 

[John Larkin]

Fred Bartoli [email protected] posted to
sci.electronics.design:

Le Sun, 04 Nov 2007 08:17:33 -0800, JosephKK a écrit:

D from BC [email protected] posted to sci.electronics.design:

[snip]

Just do it in a modern CPLD, and 10nsec should be easy. Though
there's a bit of overhead getting started in CPLDs, it's cool that
when you make a mistake in your logic or see some improvement,
it's just a re-route.

For logic (if you are willing to get away from your SN7474 and
SN7486
parts...), you could use LVC parts at 5 volts. They're fast.

Cheers,
Tom

Thanks for the headsup for the future.

Did a quick read on
http://en.wikipedia.org/wiki/CPLD

:O .ohhhh that looks scary...

Is CPLD work more complicated than programming microcontrollers
with assembly?


D from BC

No, not really, just different.

When I was a kid I did program 6800/6809 in hexa (no assembler
available). Well one of my first tasks was writing a line editor and
an assembler, all that in hexa.

I certainly would not do that for CPLDs.

OW. That is ugly and painful just to think of.

The original Signetics PLAs were programmed by marking Xs on a form to
indicate where to blow fuses. It wasn't all that bad.

I think one could program a PAL or even a 22V10 at the fuse level
without extreme agony, although there are easier ways to do it.

John

 

[JosephKK]

John Larkin [email protected] posted to
sci.electronics.design:

The delay in the rc must exceed the bounce time. The rc tau is
pretty much the only way this circuit knows what time means.


John

Personally i would use a 9602 and a 7400 connected as a gated rs
flip-flop. R of 5K and c of 10 pf or so.

 

[John Larkin]

John Larkin [email protected] posted to
sci.electronics.design:


Personally i would use a 9602 and a 7400 connected as a gated rs
flip-flop. R of 5K and c of 10 pf or so.

Schematic?

John

 

[John Fields]

On Mon, 05 Nov 2007 13:41:07 -0600, John Fields

On Mon, 05 Nov 2007 11:06:26 -0800, John Larkin

On Mon, 05 Nov 2007 10:17:23 -0600, John Fields

On Mon, 05 Nov 2007 07:05:08 -0800, John Larkin

On Mon, 05 Nov 2007 07:25:10 -0600, John Fields

On Sun, 04 Nov 2007 20:59:04 -0800, John Larkin


On Nov 4, 9:07 am, John Larkin
So, use a nonretriggerable monostable with rising clock

So what happens when a really fast spike fires both one-shots? What
happens when an edge comes in just about the time one or both
one-shots is timing out?

The problem, as stated, requires a circuit to operate in four
different phases:
Phase A: wait for a rising edge, go high when it does
Phase B: stay high, ignore edges for 'a while'
Phase C: wait for a falling edge, go low when it does
Phase D: stay low, ignore edges for 'a while'

So, something with two monostables or latches or whatever is required,
because the four states require two bits of state information. And
there are two time periods of some (presumably known) duration to
be part of the mix. It's required BY THE PROBLEM to have some
kind of one-shot to handle that timing, unless you can use higher-
speed

I posted a simple, fast circuit that works, is hazard-free, and has
few of the things that you say are "required by the problem."
Remember, the signal has states of its own, so the circuit doesn't
have to include all the states you enumerate.


Asynchronous logic can be scary, but this situation really calls for
it.

That's no reason to design hairballs.

---
Geez, if you want to see a hairball, take a look at your clock input
before the input signal gets stable!

It should be a roughly 10 ns positive pulse at every transition of the
input. The first such glitch clocks the r-c filtered data into the
dflop. Any additional glitches do the same thing. There's not even a
metastability hazard. This circuit is simple enough that a
humanly-possible analysis can demonstrate, with high confidence, that
it's safe.

You don't like it for personal reasons. That's a bad basis for
engineering.

---
On the contrary, I've used a similar circuit for years as a clean
transition detector:


.IN>---+----------A
. | EXOR Y-->OUT
. +--[R]-+---B
. |
. [C]
. |
. GND

The only thing I think that's wrong with your circuit is that at the
speed it's supposed to be used I think the EXOR chain is going to
generate a lot of hash as it follows the bouncing input.

I don't know what you mean by "hash." If you mean emi, well, any gate
that follows any signal generates "hash." Your circuits have lots of
logic transitions, too.

---
Not a lot, just what's required to set in motion the chain of events
which accepts the first edge and suppresses the rest.

That's what this circuit was supposed to do.

There's no reason to supress them. The first clock strobes the correct
logic level into the flipflop, and the following clocks don't change
it. It does exactly what the OP requested.


You're flailing. No quad xor gate processing logic levels, in any
reasonable system, is going to break nearby components. You make it
sound like no digital system can ever work.

---


---
You need to get your hearing checked.
---


---
Of course, but what you're trying to do is dodge the issue that your
circuit will put out a lot more RFI because of the many fast
transitions it'll allow to propagate down the EXOR chain than it
would if only one, or a few, transitions were allowed.

The comparator is already making all those transitions. All I'm doing
is running them through one more ssi package. That seems to scare you
for some reason; it doesn't scare me.

---
Fools rush in where angels fear to tread?

You do know that if, in a peculiar window in time you have a single
10ns edge which generates a certain spectral output, then generating
ten 10ns edges in that same window will result in that spectrum
being generated ten times, yes?

Point being that one hit might not be enough to disrupt something
that ten would. It's always best to minimize noise, wouldn't you
agree?
---

The same-polarity output comes out of qbar. Big deal. The concept was
free, and works.

---
Sure, but that's not the point.

The point is that you stated that the output should be taken from Q,
which was wrong.

 

[John Larkin]

Fools invent objections that are not real, and that they cannot
estimate realistically, for reasons that are not rational.

You do know that if, in a peculiar window in time you have a single
10ns edge which generates a certain spectral output, then generating
ten 10ns edges in that same window will result in that spectrum
being generated ten times, yes?

Point being that one hit might not be enough to disrupt something
that ten would. It's always best to minimize noise, wouldn't you
agree?

No. That's stupid. I design 100+ MHz logic all the time, with tens of
thousands of gates, and it always works. And I don't work at
minimizing the number of transitions in each gate. My logic doesn't
"disrupt" anything.

---


---
Sure, but that's not the point.

The point is that you stated that the output should be taken from Q,
which was wrong.

It's not wrong; it inverts. I never said it didn't. Somebody pointed
out that it does, and I instantly agreed. So use Qbar already if you
don't want inversion.


I designed, sketched, photographed, and posted a simple, fast,
reliable circuit that does exactly what the OP specified, all in about
90 seconds. And as someone else pointed out, it inverts, which I agree
with, and that the non-inverted signal is available at Qbar.

You designed and posted, and apparently spent hours simulating and
tuning, a slow, complex, likely unreliable hairball that does not meet
his specs.

I rest my case; let the jury decide.

John

 

[Robert Latest]

I rest my case; let the jury decide.

I like your XOR circuit. However from the OP's remarks I can't make out how
he wants the circuit to react on a single, very short pulse. Yours won't
react at all. The OP wants short propagation, which means that the circuit
must trigger on the first transition no matter what and then mask out
trailing glitches. A circuit that does that will of course make broad pulses
from narrow ones, or flip once and then get stuck in the wrong state. If
glitches can only occur following a transition (like in a mechanical
switch), there are better circuits than yours. If spurious glitches can
occur anytime, your circuit is best because it filters those out. The price
decide whether a pulse was spurious or not.

robert

 

[D from BC]

Fools invent objections that are not real, and that they cannot
estimate realistically, for reasons that are not rational.


No. That's stupid. I design 100+ MHz logic all the time, with tens of
thousands of gates, and it always works. And I don't work at
minimizing the number of transitions in each gate. My logic doesn't
"disrupt" anything.



It's not wrong; it inverts. I never said it didn't. Somebody pointed
out that it does, and I instantly agreed. So use Qbar already if you
don't want inversion.



I designed, sketched, photographed, and posted a simple, fast,
reliable circuit that does exactly what the OP specified, all in about
90 seconds. And as someone else pointed out, it inverts, which I agree
with, and that the non-inverted signal is available at Qbar.

You designed and posted, and apparently spent hours simulating and
tuning, a slow, complex, likely unreliable hairball that does not meet
his specs.

I rest my case; let the jury decide.

John

It's a neat circuit (JL circuit)
....and works great.....once it gets going.

If tau is large and the cct gets 1Mhz, there is a start up delay.
If tau is made small to reduce the start up delay, the cct
malfunctions at some lower frequency.

(In my OP, I didn't mentioned anything about quick startup operation.
Oops...)

Heck! I'm just happy to see the circuit and it's been an inspiration
for other circuits.

For example..
I replaced the RC with a Dff to hold the previous 'sampled' steady
state.
It now works at any transition at any period (varying duty)*.
*Within cct limitations.

When I post problems on SED, I'm really just looking for sparks to
start the fire..
When the fire gets going it's usually like a smokey pile of damp
leaves...
D from BC

 

[John Larkin]

It's a neat circuit (JL circuit)
...and works great.....once it gets going.

If tau is large and the cct gets 1Mhz, there is a start up delay.
If tau is made small to reduce the start up delay, the cct
malfunctions at some lower frequency.

The RC delay should be somewhat more than the expected bounce time. It
has better dynamics if the RC is replaced by a critically-damped rlc,
which has a better delay:recovery ratio. It should work at arbitrarily
low rep rates, as long as the bounce time doesn't extend.

(In my OP, I didn't mentioned anything about quick startup operation.
Oops...)

Heck! I'm just happy to see the circuit and it's been an inspiration
for other circuits.

Exactly. Circuits are ideas to be played with. You never know where
they'll lead.

For example..
I replaced the RC with a Dff to hold the previous 'sampled' steady
state.
It now works at any transition at any period (varying duty)*.
*Within cct limitations.

When I post problems on SED, I'm really just looking for sparks to
start the fire..
When the fire gets going it's usually like a smokey pile of damp
leaves...

There are always a few guys standing around with buckets of dirty
water, ready to throw them on anything that looks like a spark.

John

 

[John Larkin]

I like your XOR circuit. However from the OP's remarks I can't make out how
he wants the circuit to react on a single, very short pulse. Yours won't
react at all. The OP wants short propagation, which means that the circuit
must trigger on the first transition no matter what and then mask out
trailing glitches. A circuit that does that will of course make broad pulses
from narrow ones, or flip once and then get stuck in the wrong state. If
glitches can only occur following a transition (like in a mechanical
switch), there are better circuits than yours. If spurious glitches can
occur anytime, your circuit is best because it filters those out. The price
decide whether a pulse was spurious or not.

robert

My understanding was that this was to clean up comparator chatter,
with minimal prop delay from the first transition of an erratic but
time-limited burst. I think it does that.

John

 

[John Fields]

Fools invent objections that are not real, and that they cannot
estimate realistically, for reasons that are not rational.


No. That's stupid.

---
So you think that a quiet system isn't better than a noisy one?

I think the FCC would disagree with you.
---

I design 100+ MHz logic all the time, with tens of
thousands of gates, and it always works. And I don't work at
minimizing the number of transitions in each gate. My logic doesn't
"disrupt" anything.

---
Ostensibly because you're aware of what's in your system and go to
great pains to make sure it works like you want it to. (Short trace
lengths, adequate bypassing, etc., etc...

OTOH, you know nothing about the OP's system other than that it has
an output with lots of fast transitions when it switches, so you
have no way of knowing whether the RFI your circuit generates will
disrupt his system or not.
---

It's not wrong; it inverts. I never said it didn't. Somebody pointed
out that it does, and I instantly agreed. So use Qbar already if you
don't want inversion.

---
Agreeing with someone isn't the same as admitting you were wrong, is
it?
---

I designed, sketched, photographed, and posted a simple, fast,
reliable circuit that does exactly what the OP specified, all in about
90 seconds.

---
Hmm...

ISTR that, early on, you said it _wasn't_ a design, it was a
"suggestion", LOL!
---

And as someone else pointed out, it inverts, which I agree
with, and that the non-inverted signal is available at Qbar.

You designed and posted, and apparently spent hours simulating and
tuning, a slow, complex, likely unreliable hairball that does not meet
his specs.

---
So what's wrong with being conscientious? I do tend to take _some_
modicum of care when I design, and try to weed out all the errors I
can before I post it even though, as you're so fond of saying, "It's
only a newsgroup."

Slow? Worst case = 5 gate delays, so 2ns gates would meet his 10ns
spec, no problem. And, that's without even trying to optimize it
since (you might recall) I posted it as a proof of principle.

 

[John Fields]

There are always a few guys standing around with buckets of dirty

 

[Ken S. Tucker]

---
So you think that a quiet system isn't better than a noisy one?

I think the FCC would disagree with you.
---


---
Ostensibly because you're aware of what's in your system and go to
great pains to make sure it works like you want it to. (Short trace
lengths, adequate bypassing, etc., etc...

OTOH, you know nothing about the OP's system other than that it has
an output with lots of fast transitions when it switches, so you
have no way of knowing whether the RFI your circuit generates will
disrupt his system or not.
---





---
Agreeing with someone isn't the same as admitting you were wrong, is
it?
---





---
Hmm...

ISTR that, early on, you said it _wasn't_ a design, it was a
"suggestion", LOL!
---



---
So what's wrong with being conscientious? I do tend to take _some_
modicum of care when I design, and try to weed out all the errors I
can before I post it even though, as you're so fond of saying, "It's
only a newsgroup."

Slow? Worst case = 5 gate delays, so 2ns gates would meet his 10ns
spec, no problem. And, that's without even trying to optimize it
since (you might recall) I posted it as a proof of principle.

I think you guys (JF and JL) are making things to
complicated. At first I though a Flip-Flop was needed
but now I think a single OR gate with a Cap will do
it, as I posted.
Cheap, simple, and fail proof. It "triggers" on the
1st detection of a Hi, so it's fast, then latchs up
for a period decided by the Cap value, and ignores
the rest and then automatically resets.
Regards
Ken