And where is that imaginary 3A going to?, it's yet another example of a wildly misleading simulation.
The chances of there being something on the CMOS power supply that can draw 3A is pretty remote
it would discharge the puny 0.1uF VERY rapidly
It's a common issue, not because of imaginary high current's, but because power can feed in the I/O pin, through the top protection diode, and keeping the circuit powered up.
I think your CMOS gate-equivalent circuit actually adds complexity and cannot be understood by the audience you've intended to inform. See post #2, for example.Folks seem to like building delays, debounce keys, etc, by placing large C at the
inputs to CMOS gates.
NOT A GOOD IDEA
For case where supply collapse rapid due to its design, load situation.
TI confirms this in an ap note on general CMOS usage. Here is a rough sim of the problem.
Note since spice model did not have the parasitic diodes in it I used external as substitute.
Also used 1 ohm as C ESR......roll your own value(s) for your case. Note using .1 ohms for
C ESR produced 3A thru D1......
View attachment 144963
The simple way around this is to place a series R between gate input and the large C.
Regards, Dana.
In response to your usual 'chicken little' made up post to try and inspire fear!.The supply is not being disconnected in the sim, it is being reduced to 0V.......the charged cap
providing the current.....
Load dependent .....
"puny" you say, OK, puny for you. "VERY", excellent engineering characterization of RC decay.....NOT !
Thats the whole point of the sim, except source of current is cap which does NOT keep circuit
powered up.....
Another example of a wildly misleading response....
Ya, the two diodes (parasitic in all (almost all) CMOS) probably is too much, too challenging for some.I think your CMOS gate-equivalent circuit actually adds complexity and cannot be understood by the audience you've intended to inform. See post #2, for example.
74LVC1G08GW,125 |
---|
Agreed this is a safer solution.Folks seem to like building delays, debounce keys, etc, by placing large C at the
inputs to CMOS gates.
NOT A GOOD IDEA
For case where supply collapse rapid due to its design, load situation.
TI confirms this in an ap note on general CMOS usage. Here is a rough sim of the problem.
Note since spice model did not have the parasitic diodes in it I used external as substitute.
Also used 1 ohm as C ESR......roll your own value(s) for your case. Note using .1 ohms for
C ESR produced 3A thru D1......
View attachment 144963
The simple way around this is to place a series R between gate input and the large C.
Regards, Dana.
I tend to base my answer on the fact that most humans are limited in their ability to push a switch a second time within 80mSec of the first. So, I want to debounce for 40 to 60 millisecond range which is way more than enough for a decent switch (even a really big bad toggle switch) to stop flapping.What is the minimum RC value to filter out switch bounce?
Answer= Double the bounce time
Let's say Bounce = 15 ms then if the Vih = Vdd/3 worst case, if closure to 0V bounces open the pullup threshold worst case minimum is only about half of the 63% exponential Tau = RC time constant so it must be doubled.
Thus RC must become 30 ms which could be 10 Meg pullup * 3 nF across contact to CMOS input.
Or 1 Meg || 30 nF or 100k|| 300 nF. From a point of view of noise immunity with switch on a long cable, one must consider ESD and EMF ingress crosstalk with the ratio of 100 pF human finger model for charge attenuation and add TVS for additional protect with an Rs current and ESD voltage limiting resistor.
The bottom line
Using excessively large caps for switch debounce is unnecessary and may exceed the absolute maximum diode input current rating on a dry contact power-up. The risk exists when the ESD protection limits are unclear for energy absorption in the ESD circuit. So do not always assume a pullup of 10k is needed for switch sensing and thus add 0.1 uF cap without a series Rs to the input.
Although assumed intuitive, let me say using a sensor switch to Vdd with a pull down resistor to 0V with a cap from Vdd to CMOS input is asking for SCR failures with intermittent contact power applied.
Folks seem to like building delays, debounce keys, etc, by placing large C at the
inputs to CMOS gates.
NOT A GOOD IDEA
For case where supply collapse rapid due to its design, load situation.
TI confirms this in an ap note on general CMOS usage. Here is a rough sim of the problem.
Note since spice model did not have the parasitic diodes in it I used external as substitute.
Also used 1 ohm as C ESR......roll your own value(s) for your case. Note using .1 ohms for
C ESR produced 3A thru D1......
View attachment 144963
The simple way around this is to place a series R between gate input and the large C.
Regards, Dana.
Good advice to limit the maximum toggle rate to effectively 15 to 20 pps without introducing false triggers or delays.I tend to base my answer on the fact that most humans are limited in their ability to push a switch a second time within 80mSec of the first. So, I want to debounce for 40 to 60 millisecond range which is way more than enough for a decent switch (even a really big bad toggle switch) to stop flapping.
Basically 100 mS for power up and then input to inverter starts at 102mS, and output starts displaying at 110 mS :Interesting...
1. I wonder if this is demonstrating why a buffered inverter (or non-schmitt input) shouldn't be used as an internal oscillation could occur as well (causing it to drawing more supply current)?
2. Could you sim the circuit after inverter power up with no inverter input. Then provide an input after a delay of a few milliseconds? I'd like to see the results please.
Basically 100 mS for power up and then input to inverter starts at 102mS, and output starts displaying at 110 mS :
View attachment 144989
Got a behavioural model from TI, cant seem to get it to work orThanks.
Can you try the same using an unbuffered inverter 74HCU04?
If not, Ok. Just curious about the results.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?