SPDT debounce doesn't

[Jasen Betts]

+5v
+-----------------------------+----
| ____|________
+--o_ | |
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce
a switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply
construction is on solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?

 

[IanM]

+5v
+-----------------------------+----
| ____|________
+--o_ | |
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce
a switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply
construction is on solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?

Yep. but Jack G. Ganssle does it much better.
Read <http://www.ganssle.com/debouncing.pdf>

You have been gifted with a truly crap debouncing circuit. It seems to
be designed to cause maximum 'hash' on any circuits in its neighbourhood
and violates most of the accepted rules for safely driving a CMOS input.
Even Muntz wouldn't use it . . . .

I'll just hit the highlights:

The capacitor stores 1.25 uJ of energy that is dumped in microseconds or
less when the contacts first touch. They *ARE* arcing and *WILL* fail
sooner than if you left the cap out. Worse - you are dumping large
currents into the power and ground wiring of your circuit.

Assume a total resistance in the loop cap - Switch - ground - other side
of cap of 1 ohm, not unreasonable if you have kept the wiring short and
the capacitor is a ceramic one and its a good quality switch. You are
creating current pulses that may well peak at 5 A (without knowing the
actual loop inductance and resistance, we can't predict closer than
that). It could well look like a 10 MHz pulse train to neighbouring
circuits, slower if there is more loop inductance. That is *guarenteed*
mis-clocking and other trouble.

It needs as a *MINIMUM* a resistor between the switch common and the cap
and another between the cap and the CMOS input to prevent any small ESD
event dumping all the cap's charge into the protection diodes and frying
the input. Even then it wont work as the '595 doesn't have Schmitt
trigger inputs so its input acts as a high gain amplifier as it goes
through its linear region and is either amplifying mV of noise into rail
to rail pulses or just plain oscillating as it transitions. I last got
bitten but this particular problem trying to clock a home-brew Z80 board
back in the dark ages. The clock drive had to have VERY clean edges or
it would skip apparently random instructions . . .

Lastly the classic SPDT switch debouncing circuit uses a SR flipflop.
Either pick a flipflop with active low set and reset inputs, e.g. 7474
and tie all other inputs to their inactive state so the D type function
is diabled and you are left with just SR or wire a quad 2 input NAND
gate as a flipflop. Either give you two debouncers in one 14 pin chip.
The moving contact goes to ground, the fixed contacts go to /S and /R
with 1K to 10K pullups to +5V. Guaranteed to toggle cleanly and have
good switch life.

The *preferred* debouncer for multiple individual buttons however is a
Schmitt input buffer, a SPST switch and a R.R-C-R debouncer. (The
switch grounds where the . is) which has one more resistor, (between the
capacitor and the input) than Ganssle's fig.2 circuit to provide some
ESD protection. Gansle recommends a 74xx14 and I see no reason to
question that. You get more debounced inputs per chip and can use a
wider range of cheaper switches. If you do a lot of breadboarding it
would be worth building a set of debounced buttons on veroboard to avoid
the hassle of assembling them each time.

 

[Rich Grise]

+5v
+-----------------------------+----
| ____|________ +--o_ |
|
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce a
switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply construction is on
solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?

Yep. but Jack G. Ganssle does it much better. Read
<http://www.ganssle.com/debouncing.pdf>
...
Lastly the classic SPDT switch debouncing circuit uses a SR flipflop.
Either pick a flipflop with active low set and reset inputs, e.g. 7474
and tie all other inputs to their inactive state so the D type function
is diabled and you are left with just SR or wire a quad 2 input NAND
gate as a flipflop. Either give you two debouncers in one 14 pin chip.
The moving contact goes to ground, the fixed contacts go to /S and /R
with 1K to 10K pullups to +5V. Guaranteed to toggle cleanly and have
good switch life.

The *preferred* debouncer for multiple individual buttons however is a
Schmitt input buffer, a SPST switch and a R.R-C-R debouncer. (The
switch grounds where the . is) which has one more resistor, (between the
capacitor and the input) than Ganssle's fig.2 circuit to provide some
ESD protection. Gansle recommends a 74xx14 and I see no reason to
question that. You get more debounced inputs per chip and can use a
wider range of cheaper switches. If you do a lot of breadboarding it
would be worth building a set of debounced buttons on veroboard to avoid
the hassle of assembling them each time.

Note that if you're feeding a microprocessor you may as well debounce in
software, unless you just plain like using up board space.

I've done this, and it worked like a champ. It was a raw keyboard with
about 64X spst contacts - wiring the 8X8 matrix was very tedious. I
debounced for about 10 mS, and wrote a 16-key rollover. I was very proud.
I used it on my TV typewriter.

Cheers!
Rich

 

[Jon Kirwan]

<snip>
If you sample the switch state every, say, 20 milliseconds, and act on
what you see, there's no need to debounce at all.

I am generally able to tell when, and usually am annoyed by, equipment
sampling that way.

Jon

 

[Jon Kirwan]

<snip>
Note that if you're feeding a microprocessor you may as well debounce in
software, unless you just plain like using up board space.

Just to support this comment, I do this all the time with software and
very successfully. I use 4-8ms sampling periods and a simple state
machine that takes 3 samples to settle. (For hardware, there are
things like the MC14490 hex debouncer.)

I find debounced key events that take longer than 25ms to be annoying
and increasingly so, very quickly. Snappy and consistently responsive
is what I hope and look for.

I haven't studied it, but I would suppose that there are switch
waveforms that would flummox any one specific software algorithm and
where a general, well-designed hardware solution would work more
broadly. Hardware is s-space and software is z-space. (So, if one
knows, a priori, the sampling rate and phase of the software and its
method it may be always possible to draw a seemingly realistic pattern
that will provably screw up the software.) But I've never encountered
a problem that a good software approach doesn't solve well.

Jon

 

[IanM]

Just to support this comment, I do this all the time with software and
very successfully. I use 4-8ms sampling periods and a simple state
machine that takes 3 samples to settle. (For hardware, there are
things like the MC14490 hex debouncer.)

I find debounced key events that take longer than 25ms to be annoying
and increasingly so, very quickly. Snappy and consistently responsive
is what I hope and look for.

I haven't studied it, but I would suppose that there are switch
waveforms that would flummox any one specific software algorithm and
where a general, well-designed hardware solution would work more
broadly. Hardware is s-space and software is z-space. (So, if one
knows, a priori, the sampling rate and phase of the software and its
method it may be always possible to draw a seemingly realistic pattern
that will provably screw up the software.)

If you have unwanted signals comparable to the clock rate of the
processor on your switch waveform you almost certainly have an EMI
problem not a bounce problem. Always test your circuit next to a
ringing cellphone and make sure it at least fails safe

But I've never encountered
a problem that a good software approach doesn't solve well.

Jon

There is always the SR in software approach. It takes one extra pin for
a single switch or double the number of matrix rows and of course
changeover switches. See the link I posted earlier.

 

[Jon Kirwan]

Can you push a button for less than 20 milliseconds?

That's not exactly how I tell. And I can tell.

Jon

 

[Jon Kirwan]

How can you tell that the software is sampling every 20 milliseconds
if you can't push the button for less than that? Can you visually pick
out the 50 Hz quantization of switch service, even assuming the
associated display has instantaneous update?

And how can you tell a simple 20 ms sample loop from your 3-sample 8
ms debounce algorithm?

Maybe you could tell at 100 ms. Not at 20.

Debouncing is like bypassing. All sorts of weird religions exist.

Don't accuse me of being religious about this. It's experience with
real products, doing beta testing in a lab. The programmer who'd used
your technique told me how he'd written the code and I then knew what
to do to show him. It was kind of funny to see his face, then.

Keep in mind you are talking about a single sample and acting upon it.
That's the key. Not the 20ms period, which I consider fine. So stop
focusing on that aspect and you might begin to see.

Jon

 

[IanM]

Don't accuse me of being religious about this. It's experience with
real products, doing beta testing in a lab. The programmer who'd used
your technique told me how he'd written the code and I then knew what
to do to show him. It was kind of funny to see his face, then.

Keep in mind you are talking about a single sample and acting upon it.
That's the key. Not the 20ms period, which I consider fine. So stop
focusing on that aspect and you might begin to see.

Jon

Its fairly easy to hit a key fast enough so the uP doesn't respond if
the debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I
can hit a key too fast for it to register. Not consistently, and it
does require an aggressive wrist flick with a carefully aimed relaxed
but extended finger so scarcely normal operation but it can be done
about 20% of the time. The key is bottoming out fully so I'm not
failing to make contact.

 

[Jon Kirwan]

I don't know that his code "used my technique." Maybe he wrote a messy
switch service routine. Lots of people do.

Actually, you bring up a good point. Not exactly the "messy" one, but
another. I really don't have a full view of your method (you wrote
simply, not fully) nor do I know the application space, switches used,
etc. So I'm going on fumes, to be honest. The main thing, though, is
the focus on using a single sample and acting on it. Not for every
situation, but quite frequently in my experience this is a problem
waiting to happen.

So what do you do to a pushbutton that can differentiate between a 20
ms single sample loop and a 3x8 ms debounce loop?

The only advantage of the multi-sample thing is some added EMI/ESD
rejection. But ESD is a physical hazard to the uP, so if there's an
ESD path it should be taken care of electrically.

In the case I was referring to, the programmer used a timer to set the
sampling event and I didn't even need to look at the code. I assumed
he was right about what he told me and didn't assume he wrote crappy
code (he was experienced with both c and assembly and had been working
in instrumentation for years.) The hardware was designed by a very
thorough-going guy (who is now working in the medical products field)
who I would watch use a 20kV zap-gun and would run around the aluminum
casing zapping everywhere to make sure it was pretty solid. It was.
So I'm probably not confusing ESD sensitivity here. I had instantly
imagined how to flummox the software and it took only a minute or two
to get him to see problems happen. His situation was a simple,
scanned 4x4 matrix using the method you talked about.

By the way, he'd tested his system and had encountered no problems in
his own testing. He felt it was really pretty good. Until....

I don't consider acting on every 20ms observation 'solid.' And often,
instrumentation developers "assume" a lot about how others might use
their equipment and come away from their own testing feeling they have
tested it well and the result is 'bullet proof.' In this guy's case,
he felt really good about it. And when he saw me flummox it, he
didn't argue with me about "well, no customer would do that!" He
recognized immediately that some might do exactly "that." It had
simply slipped by him to imagine the kinds of accidental things that
actually happen in real situations.

Long, long ago I learned that the very small effort involved (and
almost zero overhead in execution time) goes a long way mitigating
such things. All from real experience and actual practice. Most of
the time, no one notices the difference. But when it matters, it
matters. Best to go the extra mile. It's really not hard and does
mitigate a few after-sale calls that can cost some money to handle.

Not telling you what to do, though. Have at it. YMMV applies.

Jon

 

[Jon Kirwan]

Its fairly easy to hit a key fast enough so the uP doesn't respond if
the debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I
can hit a key too fast for it to register. Not consistently, and it
does require an aggressive wrist flick with a carefully aimed relaxed
but extended finger so scarcely normal operation but it can be done
about 20% of the time. The key is bottoming out fully so I'm not
failing to make contact.

Interesting points.

Speaking of Cherry, I still have one of their really nice keyboards
that uses reed relays under each and every switch and donut magnets in
the key plungers. Absolutely rock solid. Damned if I can find
anything like that being build, today.

Jon

 

[Rich Grise]

Its fairly easy to hit a key fast enough so the uP doesn't respond if the
debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I can
hit a key too fast for it to register. Not consistently, and it does
require an aggressive wrist flick with a carefully aimed relaxed but
extended finger so scarcely normal operation but it can be done about 20%
of the time. The key is bottoming out fully so I'm not failing to make
contact.

Or you could hack into a $5.00 or surplus (free) PC keyboard:
http://mysite.verizon.net/richgrise/KeyZilla/

Cheers!
Rich

 

[Jon Kirwan]

So what did you do to flummox it?

There's no magic involved. Touch and bump and drop (like a user
might, placing the equipment quickly onto a table or brushing by
someone and the equipment or....) Observation does depend on what
action software takes, obviously. If it takes no action, there's no
problem to observe. Bear in mind that your sample event might be
..1 or 1 or 10 or 100 or almost any number of microseconds after a bump
event... the sampling is entirely asynchronous to the real world and
the switch contact physics, as you know. And you are saying the
software should take action, regardless. As I understand you.

Jon

 

[Jon Kirwan]

Sounds like a combination of bad switches, bad electronics (esd
sensitivity) and bad code. So don't do that. A reasonable physical
shock shouldn't cause a switch closure on a human interface panel.

If you sample every 20 milliseconds, and the switch bounce is less
than, say, 10 milliseconds, it just works. If you catch it in the
middle of a bounce, the state is exactly as ambiguous as if you did
all the debouncing in the world. I've done this on all sorts of hard
and membrane switches and it works as it should.

That looks like changing goal posts, to me. As I said, this comes
from real experience with real equipment. I didn't design it.
Switches vary a lot. And no, your argument that everything is exactly
the same (ambiguous wise) no matter what you do in software doesn't
make sense on its face. Software matters. And experience confirms.

Jon

 

[Jon Kirwan]

<snip>
Sounds like a combination of bad switches, bad electronics (esd
sensitivity) and bad code. So don't do that. A reasonable physical
shock shouldn't cause a switch closure on a human interface panel.
<snip>

What's kind of funny about this discussion (brings a smile to my face)
is that I've never once had to discuss any of this with an electronics
designer for longer than a few moments. Usually, they want to be sure
_I_ am aware and will deal with it. So I'm actually enjoying the new
experience you are affording me.

Did you read Ganssle's paper cited here in this thread by IanM? There
are some modest scope diagrams there.

Jon

 

[krw]

What's kind of funny about this discussion (brings a smile to my face)
is that I've never once had to discuss any of this with an electronics
designer for longer than a few moments. Usually, they want to be sure
_I_ am aware and will deal with it. So I'm actually enjoying the new
experience you are affording me.

Did you read Ganssle's paper cited here in this thread by IanM? There
are some modest scope diagrams there.

With a SPDT (see: subject) switch one can make the "perfect"
debouncer. Don't need no steenkin' software. ;-)

 

[krw]

A lot of pushbuttons, especially membranes, are SPST. Non-click-dome
membranes often have absurd sliding/bouncing behavior.

Sure, but that wasn't the OP's question. For membranes I usually just
double sample, pretty much like any other asynchronous interface.

 

[Jon Kirwan]

With a SPDT (see: subject) switch one can make the "perfect"
debouncer. Don't need no steenkin' software. ;-)

Good response! But I had been discussing a reply that brought in the
subject of _software_.

Jon

 

[Jon Kirwan]

I'm an EE who mostly does my own programming, so I usually don't have
to collaborate with anybody to get things to work.

EE's almost cannot get along without developing such skills, anymore,
it seems. Too often a damned lot better than many embedded
programmers without electronics knowledge. I think it's a mark of
excellence that you do the hands-on whether often or from time to
time.

Jon

 

[Jamie]

I have built systems for over 30 years. We have never bothered doing
hardware
debouncing. Switches are sampled in a regular timer interrupt service
routine.
With this scheme, you can do whatever debouncing scheme that you want.
You can
also latch contact closures so that they can be processed whenever
desired. We
built systems using 8080s with a few Mhz clock rates with no problems.

Only an extremely poorly designed piece of equipment would miss contact
closures
if you are sampling them with a timer interrupt. (You would have to be
missing
entire interrupt service requests and this would mean that you have
major problems.)

All I ever did was disable the INT after each trigger for a short period
via a timer..
On each INT trigger, I just disabled it, and then at the end of the
ISR, initiate a timer for that ISR, I simply tested to see how it
was configed each time it entered the ISR handler and alternated its state.

This all was done in a single ISR handler instead of making two
different ISRs. The uC wouldn't get flooded this way with deboucing
issues.