Maker Pro
Maker Pro

Debouncing....at About 1Mhz

J

John Larkin

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

John
 
J

John Fields

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

D from BC

Jan 1, 1970
0
Le Sun, 04 Nov 2007 10:44:20 -0800, D from BC a écrit:
D from BC wrote:



This has got to be a classic signal clean up problem....

I need a circuit that triggers on edge A, then ignores about 0.1uS of
jitter then triggers on edge B and then ignores a following 0.1uS of
jitter.
I need a circuit that triggers on edge A, then ignores about 0.1uS of
jitter then triggers on edge B and then ignores a following 0.1uS of
jitter.

[where edge A is low-to-high and B is high-to-low]

So, use a nonretriggerable monostable with rising clock to make a
pulse at A, another with falling clock to make a pulse at B, and
Set/Reset a flop flop with those. Use the monostable A output to gate
(inhibit) the B trigger, and the B output to gate the A trigger. As
long as the monostable time is set longer than the jitter window,
you're golden. Well, the trigger/output propogation delay has to be
shorter than the delay to first false transition...

For retriggerable monostables, the extra edges will stretch the output
pulse; if the stable time is guaranteed longer than the monostable
period, that's OK too.

The nonclassic solution is filtering followed by a Schmitt trigger.
That introduces phase delay, of course, and senses some average over
time rather than the initial edges.


It seems to be the trend.
I realized some of those monostable requirements when I tried to solve
the circuit.
Also, I suspect John Fields ascii circuit and posted LTspice file use
similar approaches.
One channel for the positive edge processing. A timing action. One
channel for the negative edge processing. A timing action. Some cross
resetting and final decoding..

The sequence is something like this.

Trigger on positive edge.
Let fuzz pass by.
Clear negative edge in preparation for 1st incoming negative edge.
Trigger on negative edge.
Let fuzz pass by.
Clear positive edge in preparation for incoming positive edge.

The pita part is attempting low prop delay for 1st pos edge and 1st
neg edge.
The SN74LV123A retrig MM has a tpd of 11nS@5V at the top of the
datasheet.
D from BC

It would be simpler to learn how to terminate your signals properly...

It's not that.
It's to clean up the output of a comparator in my app. The comparator is
getting a damped ring signal due to some unavoidable inductor resonance.

Oh, I thought you wanted some debouncing.
You don't want debouncing. You want damping.
Damping "inductor resonance" is the same as properly terminating a TL.
It'll cost you one resistance and maybe an additional cap. Nothing more.
And damping the resonant circuit will give you the fastest clean response.

I've maxed out the amount of hysteresis I can put on the comparator. All
this is in a main feedback loop and the debounce cct has to be low delay
to enable the highest system frequency. The higher the frequency in my
app... the better. (Well..EMI aside..)

I really believe I'm not doing a bandaid solution..it's essential.

Yes, why make it simple when you can make it difficult.

I think I tried that.
The R in the dampening cct gets fkn hot!
It's not a low energy situation.
The ring is from a few unavoidable parasitics..

However, this is uncharted waters for me..
I'll check for goofs..

I really don't believe there's anything I can do in the way of
preventive measures.
It'll bounce.


D from BC
 
D

D from BC

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

John

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

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

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
 
J

Jim Thompson

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

Fred Bartoli

Jan 1, 1970
0
Le Mon, 05 Nov 2007 08:29:55 -0800, D from BC a écrit:
Le Sun, 04 Nov 2007 10:44:20 -0800, D from BC a écrit:
D from BC wrote:
This has got to be a classic signal clean up problem....

I need a circuit that triggers on edge A, then ignores about 0.1uS
of jitter then triggers on edge B and then ignores a following
0.1uS of jitter.
I need a circuit that triggers on edge A, then ignores about 0.1uS
of jitter then triggers on edge B and then ignores a following
0.1uS of jitter.

[where edge A is low-to-high and B is high-to-low]

So, use a nonretriggerable monostable with rising clock to make a
pulse at A, another with falling clock to make a pulse at B, and
Set/Reset a flop flop with those. Use the monostable A output to
gate (inhibit) the B trigger, and the B output to gate the A
trigger. As long as the monostable time is set longer than the
jitter window, you're golden. Well, the trigger/output propogation
delay has to be shorter than the delay to first false transition...

For retriggerable monostables, the extra edges will stretch the
output pulse; if the stable time is guaranteed longer than the
monostable period, that's OK too.

The nonclassic solution is filtering followed by a Schmitt trigger.
That introduces phase delay, of course, and senses some average
over time rather than the initial edges.


It seems to be the trend.
I realized some of those monostable requirements when I tried to
solve the circuit.
Also, I suspect John Fields ascii circuit and posted LTspice file
use similar approaches.
One channel for the positive edge processing. A timing action. One
channel for the negative edge processing. A timing action. Some
cross resetting and final decoding..

The sequence is something like this.

Trigger on positive edge.
Let fuzz pass by.
Clear negative edge in preparation for 1st incoming negative edge.
Trigger on negative edge.
Let fuzz pass by.
Clear positive edge in preparation for incoming positive edge.

The pita part is attempting low prop delay for 1st pos edge and 1st
neg edge.
The SN74LV123A retrig MM has a tpd of 11nS@5V at the top of the
datasheet.
D from BC

It would be simpler to learn how to terminate your signals properly...

It's not that.
It's to clean up the output of a comparator in my app. The comparator
is getting a damped ring signal due to some unavoidable inductor
resonance.

Oh, I thought you wanted some debouncing. You don't want debouncing. You
want damping. Damping "inductor resonance" is the same as properly
terminating a TL. It'll cost you one resistance and maybe an additional
cap. Nothing more. And damping the resonant circuit will give you the
fastest clean response.

I've maxed out the amount of hysteresis I can put on the comparator.
All this is in a main feedback loop and the debounce cct has to be low
delay to enable the highest system frequency. The higher the frequency
in my app... the better. (Well..EMI aside..)

I really believe I'm not doing a bandaid solution..it's essential.

Yes, why make it simple when you can make it difficult.

I think I tried that.
The R in the dampening cct gets fkn hot! It's not a low energy
situation.
The ring is from a few unavoidable parasitics..

However, this is uncharted waters for me.. I'll check for goofs..

I really don't believe there's anything I can do in the way of
preventive measures.
It'll bounce.

Why is it getting hot?
What are the voltage and parasitics estimated values?
What is the source?

If the average DC is high enough and the L/C impedance low enough so as
to pose pb, then use an AC termination (series RC, where C is a feew
times your C parasitics).
Depending on the configuration you can also use source series termination.

Google about TL termination.
 
D

D from BC

Jan 1, 1970
0
[snip]
You're wasting everyone's time with your partial description of the
circuit and signal source. All those FF and OS circuits are unnecessary.
At the least , it is a simple matter to employ ac positive feedback to
the comparator to coast the output through a 100ns ring down time, and
then only if for some reason the "inductor resonance" itself cannot be
over damped using any one of the numerous techniques to do so. Is this
"resonance" due to a length of uncontrolled impedance *wire* running
from the nebulous 'power section' to your add-on board? If so, a simple
series small resistor goes a long way towards damping a high frequency
resonance ( ~100MHz in your case ) while preserving more than sufficient
BW for the processing. SHEESH!

It's possible.. but I don't think so..

It's part of an smps controller.

I'll post the source of this problem as another topic..
It involves parasitics (inductance and capacitance), hysteresis
limitations, current sensing and control loops.

I posted what I thought was an interesting and challenging problem.
It also looked like a classic problem..so I thought there might be an
already known solution.

The debounce problem was simple to describe...
but surprisingly tricky for me to solve .

D from BC
 
K

Ken S. Tucker

Jan 1, 1970
0
[snip]


You're wasting everyone's time with your partial description of the
circuit and signal source. All those FF and OS circuits are unnecessary.
At the least , it is a simple matter to employ ac positive feedback to
the comparator to coast the output through a 100ns ring down time, and
then only if for some reason the "inductor resonance" itself cannot be
over damped using any one of the numerous techniques to do so. Is this
"resonance" due to a length of uncontrolled impedance *wire* running
from the nebulous 'power section' to your add-on board? If so, a simple
series small resistor goes a long way towards damping a high frequency
resonance ( ~100MHz in your case ) while preserving more than sufficient
BW for the processing. SHEESH!

It's possible.. but I don't think so..

It's part of an smps controller.

I'll post the source of this problem as another topic..
It involves parasitics (inductance and capacitance), hysteresis
limitations, current sensing and control loops.

I posted what I thought was an interesting and challenging problem.
It also looked like a classic problem..so I thought there might be an
already known solution.

The debounce problem was simple to describe...
but surprisingly tricky for me to solve .
D from BC

Last time I studied key-debounce was for my old
TRS-80 back in 1980, and they had a nice little
solution.

Maybe this might work, I'll use 1 OR gate.

A ------------
OR ---------------- O/P
B--- |
|-- -------C-----|
R
gnd

Start with everything at 0.

Input A get's a "1", the O/P goes Hi to "1" and
feeds to "B", doesn't matter now that "A" is
bouncing about, the O/P stays Hi for the RC
time, by the O/P feeding "B" via "cap C".
(R can be the gate input resistance).

The gate resets when the RC times out ready
for the next "1" delivered to "A".
Regards
Ken S. Tucker
 
J

John Larkin

Jan 1, 1970
0
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 logic is for, to process signals.

So you're saying that this signal is so bad it shouldn't be allowed to
go through gates.

John
 
J

John Larkin

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

Hey, Jim, how's the bod?

John
 
J

John Larkin

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

That will break it of course, but that's your option.
The D ff will hold the previous settled state.
It can be clocked by a delay triggered by each edge.

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

It does already.
Ok..if I hairballize your circuit a bit :)

Sure. It's not my job on the line.

John
 
J

Jim Thompson

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

Hey, Jim, how's the bod?

John

Walking, mild pain, cleaning up the bed rash from 72+ hours lying on
my back :-(

...Jim Thompson
 
J

John Fields

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

Your circuit sits there generating very high-speed, probably
high-current edges every time the input signal changes state.
---
That's what logic is for, to process signals.

---
Is that a fact???

Geez, thanks for the leg up, John, that's something that's escaped
me all these years... ;)
---
So you're saying that this signal is so bad it shouldn't be allowed to
go through gates.

---
No, but you're trying to put words in my mouth. Don't.

What I was leading up to was that your circuit may be unsuitable if
the amount of RFI it puts out will be enough to adversely affect the
circuitry around it.
 
C

Charlie Edmondson

Jan 1, 1970
0
John said:
---
Yes, but the timer is to keep the fuzz from firing the _other_
circuit once the first edge fires its own circuit.

Don't mind Larkin, he generally pooh-poohs everything that doesn't
come out of his shop. NIH, it's called. ;)

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
 
J

John Larkin

Jan 1, 1970
0
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.
Your circuit sits there generating very high-speed, probably
high-current edges every time the input signal changes state.

"Probably high current?" Logic does tend to use power when it
switches, I suppose.

---


---
Is that a fact???

Geez, thanks for the leg up, John, that's something that's escaped
me all these years... ;)

Yup, sounds like.
---


---
No, but you're trying to put words in my mouth. Don't.

What I was leading up to was that your circuit may be unsuitable if
the amount of RFI it puts out will be enough to adversely affect the
circuitry around it.

Oh please. You can say that about any digital logic.

Joh
 
C

Charlie Edmondson

Jan 1, 1970
0
Jim said:
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
 
J

John Larkin

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


It's problematic to say that any asynchronous machine has states. My
circuit has only one flipflop, so I think it has two states: flipflop
set, and flipflop clear.

John
 
J

Jim Thompson

Jan 1, 1970
0
Jim said:
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.

...Jim Thompson
 
J

John Fields

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

---
Then, unfortunately, since it didn't suppress the multiple edges
propagating through your EXOR chain, it's not working like it
should.
---
"Probably high current?" Logic does tend to use power when it
switches, I suppose.

---
Yes, it does, and some families use more than others and switch
faster, generating more hash.
---
Yup, sounds like.

---
You need to get your hearing checked.
---
Oh please. You can say that about any digital logic.

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

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.

Like JT said, you're a sore loser.
 
J

John Fields

Jan 1, 1970
0
Jim said:
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.
 
Top