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]

Jasen Betts wrote:

+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.

--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:

 

[Tim Wescott]

On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+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.

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

--
www.wescottdesign.com

 

[Rich Grise]

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott wrote:

On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+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

 

[John Larkin]

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+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.

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

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

John

 

On Dec 1, 1:36 pm, Rich Grise <richgr...@example.net> wrote:

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott wrote:
On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
  +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

Used dual 8x8 matrices on my MIDI pipe organ many years ago with NC /
NO contacts to measure the 'fly time' and derive velocity. It was true
N key rollover. Can't be missing notes in a performance. Contact
debounce was looking for 3 consecutive scans (at 3kHz) of the new
value. Worked very well.

G˛

 

[JeffM]

IanM wrote:

You have been gifted with a truly crap debouncing circuit.
[...]Even Muntz wouldn't use it

I haven't heard that one before in exactly that context.
For those who missed the reference:
http://google.com/search?q=cache:-Wq7d5yS0VQJ:en.wikipedia.org/wiki/Madman_Muntz+*-*-*.*-*-*-*-*-minimum-*-number+47+47+47+47+*-*-*-*-*-*-wire.clippers#Muntz_TV
http://en.wikipedia.org/wiki/Madman_Muntz#Muntz_TV

 

[Jon Kirwan]

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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]

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

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]

Jon Kirwan wrote:

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

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.)
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.

--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:

 

[John Larkin]

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

John

 

[Jon Kirwan]

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

 

[John Larkin]

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

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.

John

 

[Jon Kirwan]

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

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

 

[John Larkin]

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

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.

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

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

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.

John

 

[IanM]

Jon Kirwan wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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
Can you push a button for less than 20 milliseconds?
That's not exactly how I tell. And I can tell.

Jon
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
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.


--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:

 

[Jon Kirwan]

On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

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.

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.

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.

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]

On Thu, 03 Dec 2009 20:46:16 +0000, IanM
<look.in.my.sig@totally.invalid> wrote:

Jon Kirwan wrote:
On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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
Can you push a button for less than 20 milliseconds?
That's not exactly how I tell. And I can tell.

Jon
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

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]

On Thu, 03 Dec 2009 20:46:16 +0000, IanM wrote:

Jon Kirwan wrote:
On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin

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.

Can you push a button for less than 20 milliseconds?
That's not exactly how I tell. And I can tell.

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.

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

 

[John Larkin]

On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

Can you push a button for less than 20 milliseconds?

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

Jon

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.

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.

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.

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

So what did you do to flummox it?

John