Hardware Debouncing for a Button - Capacitor required?

[xrstf]

Hi there,

I want to finally stop being a peasant and debounce my buttons in hardware once and for all. For that I bravely googled and followed the first tutorial I could find: https://hackaday.com/2015/12/09/embed-with-elliot-debounce-your-noisy-buttons-part-i/ The article features this schematic:



I got myself a single channel 74HC (TI SN74LVC1G04DBV) and breadboarded it, using my laptop's USB as the voltage source (i.e. 5V). The extra wires are for hooking up the scope later:



The circuit works as expected, but I was wondering if the capacitor is really helping me. I hooked up my oscilloscope and took 3 measurements: a) no capacitor, b) 100nF ceramic, c) 100nF electrolytic. This is what I measured (notice the significantly different times per division!):

(CH1 = 74HC output, CH2 = 74HC input)

a) No Capacitor



b) 100nF Ceramic Capacitor



c) 100nF Electrolytic Capacitor



With no cap, the rise time was sub 1 micro second, but with the caps it took significantly longer and also added some "noise". So now I am wondering if the capacitor is really only needed if the voltage source is much more noisy or if I measured it wrong.

[TrickyNekro]

Try 470Ω resistor with anything between 0.1uF and10nF capacitor for the RC filter. 10K is too much that´s why your waveform is way slow. What you see at the output of the 74HC is also normal?
You stay for too long in the "unknown" region. For slow rising signals you need gates with schmitt-trigger inputs so that you do not get this problem. And yes the capacitor is required as it is what makes the smoothing.

Edit: the 74HC14 is a gate with a schmitt-trigger input. Are you sure your single gate ( I suppose ) logic you use there has a schmitt trigger input?

Edit No.2: You use the SN74LVC1G04 which is not a schmitt-trigger input gate. It is not noise what you see, it is the IC not knowing in what state it should be. Not the best long term for its operation probably also.


PS. You are no peasant for de-bouncing in software, do not worry. I could almost say that in most situations it is actually better also. It all depends on what you want to build.

[esepecesito]

Also you don't really need an inverter in the middle. Just invert the value in the microcontroller. Try always to do everything with the microcontroller. Also the debouncing can be done in SW. Each component you save is money, and assembly time, and flexibility you save.
Sometimes you may put an inverter in the input, but then it would be a schmitt trigger, which helps with filtering noise.

[TrickyNekro]

Also you don't really need an inverter in the middle. Just invert the value in the microcontroller.

I usually also do the resistor capacitor resistor, to avoid driving a capacitor directly with a microcontroller pin in case you mess the pin direction.
At least in pre-production that´s really helpful, usually makes final cut also, you never know how your code might go on crazy land.

[Ian.M]

There are many ways to get a 'simple' RC switch debouncing circuit wrong!

Read A Guide to Debouncing, or, How to Debounce a Contact in Two Easy Pages, by Jack Ganssle.

You also need to be aware of switch (and relay) wetting current.  If a switch or relay does not have precious metal, conductive elastomer or mercury wetted contacts, you need to pass a minimum current through it, with (in some cases) a minimum voltage across it at the moment of contact closure, to guarantee it will reliably make contact.  Insufficient current or voltage in a logic level circuit + poor choice of switch contact type can result in apparent switch failure, which can be resolved by applying appropriate voltage and wetting current.

N.B. if you use a precious metal contact switch to switch a high current, high voltage, or highly capacitive or inductive load, the resulting contact arcing will ablate and oxidize the previous metal contact surface, rendering it unfit for subsequent logic switching use, even though the load was well within the switch's ratings.

[xrstf]

Try 470Ω resistor with anything between 0.1uF and10nF capacitor for the RC filter. 10K is too much that´s why your waveform is way slow. What you see at the output of the 74HC is also normal?
You stay for too long in the "unknown" region. For slow rising signals you need gates with schmitt-trigger inputs so that you do not get this problem. And yes the capacitor is required as it is what makes the smoothing.

Thanks for giving me these hints. I have never drawn a connection between resistor values and rise times in circuits. To me the resistor value was mostly determined based on the acceptable current in my circuit (i.e. do I want to afford 10 or 20 micro amps when the button is pressed). I took your suggestions and made some more measurements, comparing different resistor values. For those interested, here are my results:

470 Ohm, no Capacitor



1 kOhm, no Capacitor



10 kOhm, no Capacitor



100 kOhm, no Capacitor



I have so much to learn... I think I'm slowly rediscovering RC circuits from first principles.

Edit: the 74HC14 is a gate with a schmitt-trigger input. Are you sure your single gate ( I suppose ) logic you use there has a schmitt trigger input?

Edit No.2: You use the SN74LVC1G04 which is not a schmitt-trigger input gate. It is not noise what you see, it is the IC not knowing in what state it should be. Not the best long term for its operation probably also.

To be absolutely honest, I was looking for "74HC" and single input and was mostly ignoring everything else, thinking that "oh yeah, that 74HC series ... I guess those chips are all the same, except for the number of inputs?" and did not bother too much with schmitt triggers, inverter, hex inverter or other terms. So it's very possible that I bought the wrong chips.

All I really cared for was a sharp edge, no matter if it's rising, sinking, is inverted or whatever. Just give me my damn warm fuzzy digital behaviour :-D

[xrstf]

Also the debouncing can be done in SW. Each component you save is money, and assembly time, and flexibility you save.

You are absolutely right, I was being kind of making a joke with the peasant remark.

For now I've been getting by mostly eyeballing stuff in my projects (I even got I²C to work without realizing I missed the pull ups ), but that needs to stop and I want to learn how to do things properly / properly in hardware. HW debouncing is one of the things I want to have done and then have in my toolbelt for the future. For a single button in a project it's probably overkill though

[wizard69]

Have you considered IC's designed for debouncing inputs?    An example would be : https://www.analog.com/en/products/ltc6994-1.html#product-overview.   Another might be: https://www.analog.com/media/en/technical-documentation/data-sheets/295112fb.pdf   And yet another approach can be found here: https://www.logiswitch.net/

AS for alternatives, this series may answer a lot of questions for you: https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1/.    The series covers 9 issues that cover much of the commonly used approaches.

Depending upon the number of inputs needed and the MCU in question you might be able to accomplish or at least help, hardware denounce on the MCU itself.   That of course depends upon what hardware exists and the amount of pins to debounce.   

One thing to realize is that debonce isn't noise in the sense of transients coupled into an i/O line.   If you are working in an extremely noisy electrical environment you may need to consider that.   This might not be what some think when talking about bounce but the difference here is that the circuit is actually being turned on and off pretty fast which can be seen in scope traces already posted here.

Another issue that may undermine your debounce solution is the use of switches in low voltage environments that are relay not designed for low voltage use.   This is one of those learned the hard way; in an industrial environment switches designed for 24 VDC circuits will often not work well in a 5VDC TTL like environment.   The contacts will not "wet" and will often be very intermittent or have random settling times.    That is if they even work at all.    In one case i had to change to push buttons using reed contacts.

Also the debouncing can be done in SW. Each component you save is money, and assembly time, and flexibility you save.

You are absolutely right, I was being kind of making a joke with the peasant remark.

For now I've been getting by mostly eyeballing stuff in my projects (I even got I²C to work without realizing I missed the pull ups ), but that needs to stop and I want to learn how to do things properly / properly in hardware. HW debouncing is one of the things I want to have done and then have in my toolbelt for the future. For a single button in a project it's probably overkill though

[Doctorandus_P]

TLDR.
I did see the Jack Ganssle article was already mentioned, which is a very good article about debouncing various switches.

From your screenshots it appears you are only looking at opening the switch, and the generally bounce a lot less (or not at all) during opening. Most of the bouncing is when the switch is being closed. Anyway, you should look at both state changes.