0
\$\begingroup\$

I am trying to debounce a button. Here is my result so far after placing a 1uF ceramic capacitor in parallel with the button: enter image description here enter image description here

This should work as an input to my Arduino 5V since it has High: U >= Vht = 3.0 V and Low: U <= Vlt = 1.5 V.

I guess this means my Arduino has a Schmitt trigger on its input pins?

I want to send my trigger signal to another digital input (a framegrabber that starts recording images on rising edge and stops on falling edge) and I do not know if it has a Schmitt trigger on its input.

I am therefore looking for a Schmitt trigger IC that can clean up and make my signal TTL 5V digital.

Could you recommend such an IC that is DIP (not surface mounted) and can be bought in small quantities?

I think I understand how I could debounce using the Arduino by measuring time from rising edge and making sure that a falling edge is not delivered too soon after that.

However I would prefer to do this in hardware for the learning experience. Unless that is software debouncing is somehow better than hardware debouncing.

\$\endgroup\$
22
  • 9
    \$\begingroup\$ You can debounce in firmware. \$\endgroup\$
    – Eugene Sh.
    Commented Nov 26, 2020 at 19:04
  • 1
    \$\begingroup\$ Your input does not have a Schmitt trigger, it just has a band in which the input state is not considered stable. As mentioned by Eugene it's always a good idea to do debouncing in software. \$\endgroup\$
    – po.pe
    Commented Nov 26, 2020 at 19:07
  • 2
    \$\begingroup\$ Not a good idea to short out a 1 uF charged capacitor - use a 100 ohm in series. \$\endgroup\$
    – Andy aka
    Commented Nov 26, 2020 at 19:24
  • 2
    \$\begingroup\$ @Andy the HC126 does not have schmitt trigger input. Search for schmitt trigger chips instead. I have to agree that shorting a 1uF capacitor with a pushbutton is not very good idea, it could eventually wear out from the multi-ampere jolts. \$\endgroup\$
    – Justme
    Commented Nov 26, 2020 at 19:32
  • 3
    \$\begingroup\$ @Andy Properly debouncing in HW can be challenging. Also, adding components to the PCB adds cost and takes up board space. If the FW is going to be designed to tolerate bounce (which it should) then it is easier to just do it all in FW. \$\endgroup\$
    – user57037
    Commented Nov 26, 2020 at 20:25

2 Answers 2

Reset to default
1
\$\begingroup\$

The old maxim 'garbage in, garbage out' rings true. Even if it was a 'perfect' switch, you'd still want to verify that the input is what you expect. Reading the state once means transients like ESD or lightning can get interpreted as a valid key press. What we really want to do is read the input multiple times over a given time period to ensure the input is what we think it is. The more times we read it, the more we can be sure. If we read the input every 10ms and count if we get 5 of the same input each time, then the likelihood of the switch actually being in a given state is much higher that if we read it once or twice. This also has the effect of debouncing a mechanical switch. You can extend this method to ensure the switch is active for a given time to filter out effects of vibration or a false press. This is the advantage the doing debouncing in software gives you.

In general, you should filter any input from the outside world - transients are common place. One read of a GPIO is a snapshot of a few nanoseconds - a transient can easily 'photo-bomb' the value you read. This is also one reason why you should avoid using switches and external signals on external interrupts.

As for a suggestion of a schmitt trigger ic, something like a 74HC14 is fairly common.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Transients should not normally cause the state of the input to transition all the way from low to high or vice verse. I have seen it happen, but only when there was a long trace attached to an input with no external pullup or pulldown. Even then, adding a small capacitor (like 22pF) fixed the problem. \$\endgroup\$
    – user57037
    Commented Nov 27, 2020 at 3:27
  • \$\begingroup\$ Depends on the transient and how you test for it. Ever done CE testing? \$\endgroup\$
    – Kartman
    Commented Nov 27, 2020 at 7:25
  • \$\begingroup\$ yes. During ESD testing sometimes an input can transition. But generally not if it has a strong pullup or strong pulldown, or if it has a capacitor. Usually it is something driven weakly that transitions. Or something with a long wire. I still think you have kind of overstated the case when you say "a transient can easily 'photo-bomb' the value you read." But I have no major quarrel with you. I largely agree with what you wrote. \$\endgroup\$
    – user57037
    Commented Nov 27, 2020 at 9:08
2
\$\begingroup\$

Any hardware solution to debouncing involves a certain time latency, what time T between button presses is considered to be a bounce, or a second press?

Once you have that time T, the simplest way to debounce is to poll the button once every T in software.

There are plenty of more complicated schemes you can find being pushed on the web, sampling more often and implementing up and down counters, but they don't really offer you much advantage over the simplest poll every T.

\$\endgroup\$
7
  • 2
    \$\begingroup\$ Actually polling every time T isn't a great idea, as this can lead to missing events entirely. Typically what you want to do is detect the leading event immediately and then ignore any subsequent input for time T. A variation is to detect closure, but wait to act until the button has been released for an entire time T. \$\endgroup\$
    – Chris Stratton
    Commented Nov 27, 2020 at 4:57
  • 1
    \$\begingroup\$ If you poll every 10ms are you concerned about missing a sub 10ms pushbutton event? If it is sub 10ms, then it is unlikely it is a valid pushbutton press. \$\endgroup\$
    – Kartman
    Commented Nov 27, 2020 at 7:29
  • \$\begingroup\$ @Kartman if you poll every 10 ms, possibility of misreading the same event for multiple times is there. Imagining the switch is poor in debouncing and is triggering an interrupt in the code. If you increase the polling time, possibility of missing an event increases. Gotta find a trade off between two. But still this is a crude method. \$\endgroup\$
    – Mitu Raj
    Commented Nov 27, 2020 at 11:03
  • \$\begingroup\$ @mituraj. If polling is crude, what would you suggest is a more suitable technique? Suggesting an interrupt would be worse - you want sub microsecond response for an input that is derived from slow human input? What about EMC effects? \$\endgroup\$
    – Kartman
    Commented Nov 29, 2020 at 20:06
  • 1
    \$\begingroup\$ For buttons, polling every 10 or 50 ms works well in practice. Missing button presses that last less than 50ms is not a problem, as these are very fleeting button presses that were probably done by accident. Maye for a game controller it might be important to reduce latency. But for many normal buttons it is fine. \$\endgroup\$
    – user57037
    Commented Dec 1, 2020 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.