debounce problem

Has anyone ever used a hardware debounce solution like the Motorola MC14490? Are those effective?

No, the problem is the inverter! It must be a schmitt-trigger input. a 7414 not a 7404 for instance.

If you were using CMOS you could add hysteresis with a resistor feedback network, but that's tricky with TTL, I think that 74AC04 must go. Try a 74HC14 then you can use a much smaller capacitor (0.1uF and a 100k pull-up for instance gives 10ms time-constant)

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. Adding 100 ohm or so in series with the switch will prevent such damage. With a 0.1uF cap this damage is negligible.

ironbot:
I drew what I call 'standard', sorry if not very clean drawing, and yes, I made a mistake, 10uF for sure!

It is probably worth reading a bit more about debounce circuits. In particular your trigger is the wrong part, and a second resistor is advisable.

Is there a reason you are using an interrupt? I normally poll pushbuttons either in a tick interrupt or from a task that is scheduled to run every few ticks. This makes it very easy to debounce the switch in software. I only use an interrupt when I want the button to wake up the mcu from sleep mode, and once it has woken up I disable the interrupt and revert to polling.

I drew what I call 'standard',

There is a missing resistor there.

Seriously, I have had this exact type of circuit resetting the mcu every time the button was pushed. And that mcu in question here was known to deal with interference.

I suggest that 1) you put back that missing resistor; and 2) if you have to go down with it, use a LOW-Quality (and I am not kidding here) button with high on-contact resistance. With a high-quality button, you run a substantially higher risk of resetting the mcu.

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.