Connect with us

SPDT debounce doesn't

Discussion in 'Electronic Basics' started by Jasen Betts, Dec 1, 2009.

Scroll to continue with content
  1. Jasen Betts

    Jasen Betts Guest

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

    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?
  2. IanM

    IanM Guest

    Yep. but Jack G. Ganssle does it much better.
    Read <>

    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.
  3. Rich Grise

    Rich Grise Guest

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

  4. Jon Kirwan

    Jon Kirwan Guest

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

  5. Jon Kirwan

    Jon Kirwan Guest

    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.

  6. IanM

    IanM Guest

    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 :)
    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.
  7. Jon Kirwan

    Jon Kirwan Guest

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

  8. Jon Kirwan

    Jon Kirwan Guest

    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.

  9. IanM

    IanM Guest

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

    Jon Kirwan Guest

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

  11. Jon Kirwan

    Jon Kirwan Guest

    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.

  12. Rich Grise

    Rich Grise Guest

    Or you could hack into a $5.00 or surplus (free) PC keyboard:

  13. Jon Kirwan

    Jon Kirwan Guest

    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.

  14. Jon Kirwan

    Jon Kirwan Guest

    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.

  15. Jon Kirwan

    Jon Kirwan Guest

    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.

  16. krw

    krw Guest

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

    krw Guest

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

    Jon Kirwan Guest

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

  19. Jon Kirwan

    Jon Kirwan Guest

    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

  20. Jamie

    Jamie Guest

    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
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day