debounce problem

The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.

The most insightful comment in this whole thread.

MarkT is absolutely right here.

Well as Grumpy_Mike pointed out, you should try a larger capacitor.

Do the opposite: use as small of a capacitor as you can.

For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.

1 Like

dhenry:
For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.

Well the original post was about signal bouncing, and apparently the problem was solved to ironbot's liking. :slight_smile: Given that for all we know ironbot is using something like this, I doubt worrying about contact degradation is worthwhile at this point.

I doubt worrying about contact degradation is worthwhile at this point.

If you think this discussion is about contact degradation, you haven't understood this discussion.

dhenry:

I doubt worrying about contact degradation is worthwhile at this point.

If you think this discussion is about contact degradation, you haven't understood this discussion.

Well, you are the one that quoted MarkT's comment about possible contact degradation and stated it was the most insightful comment in the thread (see below).

dhenry:

The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.

The most insightful comment in this whole thread.

MarkT is absolutely right here.

If you expect people that can't/won't do your experiment to know, rather than guess, about what you are refering to maybe you should tell them. Cryptic advice is of little use to anyone.

ironbot:
True, can't do software debounce for I'm on ISR, no delay() !

Not true at all.

Two common ways as follows:

  1. Disable interrupt in the ISR on first contact and record time to a global variable. Reenable interrupts in the loop after a bounce guard time.
  • or -
  1. Record time to a static variable in the ISR on first interrupt. Ignore successive interrupts until guard time has elapsed.
  1. Disable interrupt in the ISR on first contact and record time to a global variable. Re-enable interrupts in the loop after a bounce guard time.

When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?
(Self-answer: probably keeping only that particular interrupt disabled while globally enabling interrupts.)

Too tricky IMHO, if at all feasible.

Point 2 looks doable, instead.

Hi
Firstly MarkT is correct in saying that a schmitt trigger such as 74HC14 should be used for this type of switch debounce circuit. You are inputting a relatively slowly changing voltage level to the invertor which may result in false switching signals as the input slowly crosses the switching levels of the device.

Secondly, I am new here and know little of the Arduino microproc boards, so my next suggestion is a question. Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.

See for example Set-Reset Flip-Flop Operations

Apologies for not attaching an image but I am still learning how to operate this site.

Cheers

switch debounce.gif

Although TCSC47's suggestions are valid and workable, the whole point of microcontrollers is that by using software they can do in a single device many functions that previously we had to build separate hardware to do. Use software debounce.

Use software debounce.

I have found the old fashioned r/c debouncer to be quite effective and reliable.

dhenry:

Use software debounce.

I have found the old fashioned r/c debouncer to be quite effective and reliable.

Yes, I'm sure it is; the atmega mcus have input hysteresis, so they can cope with the slowly-varying signal that this provides. But I prefer writing code to soldering components. [Actually, I don't even have to write any code, because I re-use the PushButton class that I developed a while ago.]

Hi dc42
Your answer for using software debounce is one that I certainly would accept for large production professional designs requiring small space and small component count.

Also, as you have informed us, the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.

However, and admitting that I do not have full details of what ironbot is doing, his project seems to me to be a learning exercise. Thus I would always advise a gate of some sort between the microproc and an outside input, to protect the microproc and allow alot of messing about with soldering, flying leads, and mistakenly connected inputs etc.

Also, as such, I would try and separate as many of the component parts of the design as possible. By using the two NAND gate debounce which is virtually infallible, we can get into the more intersting aspects of programming the functioning of the project, knowing that switch bounce is not a problem. Later on when all the fun bits have been done, then we could return to the finer points of professional design.

Incidently, as has been pointed out here already, an oscilloscope would be a very useful bit of kit to see exactly what is going on with problems like switch bounce. I've just bought a second hand scope with a terrific spec. for £100 on line.
Cheers

the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.

I don't know how the hysterisis (either on the atmega or hc14) would have eliminated the need for debouncing. Your circuit would have worked with a non-ST gate and the atmega, with hysterisis, would malfunction without a debouncing approach.

tuxduino:
When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.

BenF:

tuxduino:
When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.

I thought about that. But then you'd have nested interrupts. Scary :stuck_out_tongue: Much better IMHO to have the ISR fire at regular intervals and debounce using volatile global variables, or by using static locals and using a volatile global to communicate with the main code.

Scary

Agreed. With that kind of risks, I would take the 2R/C debouncer any time of the day.

Being a (very) lazy software guy, I'd rather write an entire library just to debounce a pin than to figure the resistor or capacitor values to use :stuck_out_tongue: but I try to keep the code at least debuggable. Interrupts are somewhat fascinating, but they're the gate to the hell of heisenbugs. So I try to avoid them as much as possible. Netsted ISRs ? Maybe when I'll start my own aRTOSuino :smiley:

dc42:
Although TCSC47's suggestions are valid and workable, the whole point of microcontrollers is that by using software they can do in a single device many functions that previously we had to build separate hardware to do.

I think your sentence is missing "if it's better, or faster, or cheaper without compromising functionality" between "do" and "."

On the other hand, if timing is critical, then misguided attempts to guess when a switch has settled into a stable position, that involve timing loops, are exactly the sort of thing that a couple of resistors and a capacitor will fix for you easily and cheaply.

Yes, I used an italic full stop. I hope anyone who remembers Algol-60 smiled.

TCSC47:
Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.

That type of circuit was discussed in the page I linked to earlier in the thread, which also mentioned the drawback that a double-throw switch is needed. But that aside, it works fine of course.