debounce problem

Hi,
I have a plan to install a bumper switch in the neck of the robot and just set it up on breadboard to test. I used standard hardware debouncing by using an SN74AC04 hex inverter and 10k resistor and 10mf capacitor and a microswitch.

For test program I attached the zero interrupt of pin 2 and it works, but not well enough: it sometimes makes a mistake. Seems to me not a fast enough debouncing. If I press the switch repeatedly around 2 times a second, it makes mistakes sometimes.

My question: is there any way I could guarantee its operation, or a better way of implementing such a limiting switch, as it is to sit with a dc motor and just imagine if the bot is turning the neck and limiting switch won't work!

and 10mf capacitor

I bet you haven't, I suspect you have a 10uF (micro Farad ) capacitor.

If this is not giving you long enough debounce then make it bigger. However, it would be good to see the schematic of what you think is standard.

Have you considered adding a software debounce ?

Have you considered adding a software debounce ?

It is a lot more tricky on an interrupt pin, because the delay is in the ISR which is never a good thing.

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

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

Edit:
Sorry for I forgot: the resistor is connected to +5v.

schema1.PNG

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

Well as Grumpy_Mike pointed out, you should try a larger capacitor. I don't know what you have available, but the delay of an resistor-capacitor circuit will be R*C, in seconds.

Edit: So in your present circuit you have 1010^3 * 1010^-6 = 0.1

Grumpy_Mike:

Have you considered adding a software debounce ?

It is a lot more tricky on an interrupt pin, because the delay is in the ISR which is never a good thing.

Next time I need to read more carefully, I didn't notice the OP was using an interrupt :roll_eyes:

I was wondering whether a simple state machine could be embedded inside the isr to provide a form of software debounce nonetheless...

tuxduino:
I was wondering whether a simple state machine could be embedded inside the isr to provide a form of software debounce nonetheless...

IMHO that would be more trouble than it's worth, unless it was somehow impossible to get a working RC circuit.

Thank you all, like always my mind got clear by refering to Arduino Forums!

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.