Is there a breadboard compatible version of MAX6818 switch debouncer?

[eeguy]

It seems that they are in SMD form. I am looking for one that is compatible with breadboard.

[K5_489]

SMD Breakout boards - https://www.adafruit.com/category/198  Use just about any type of SMD component in a breadboard. 

[jpanhalt]

Do you need octal and/or 3 state? If so, then as suggested, an adapter may be your only choice.  Hex  MC14490 may be available in the "marketplace" from DigiKey for the incredible price of $11.66 each.  I'd still go the adapter route.

Edit:   Amazon claims to have lots of 5 cheaper (also marketplace): https://www.amazon.com/MC14490P-MC14490-DIP16-Logic-Original/dp/B07P69YG4V

[eeguy]

At present, I only need to use two switches. Later I may end up four. So MX6818 is better? In that case, I should look for an SSOP adapter. Is this the one to get? https://www.adafruit.com/product/1206

[wraper]

I would not ever use them. Not only because I consider devices like these mostly a substitute of proper programming but because MAX681x are an absolute garbage as they implement the worst debounce algorithm possible.

These switch debouncers remove bounce when
a switch opens or closes by requiring that sequentially
clocked inputs remain in the same state for a number of
sampling periods. The output does not change until the
input is stable for a duration of 40ms

A sure recipe for missed button presses, especially with somewhat worn switches. Whoever designed these had no clue about switch bounce and human behavior of pressing buttons. A dumb RC debounce with Schmitt trigger inputs will work way better than this.

[jpanhalt]

I have used both the MAX681x and MC14490 (both PDIP and SDM versions) and have never had a problem with the 40 ms delay.  Why would a worn switch create problems there and not with software that checks for change of state?  Don't both involve timing?

 

[wraper]

I have used both the MAX681x and MC14490 (both PDIP and SDM versions) and have never had a problem with the 40 ms delay.  Why would a worn switch create problems there and not with software that checks for change of state?  Don't both involve timing?

Ask yourself a question if you want to know either: 1. if a button is pressed, or 2. if switch is in absolutely stable state? I just checked, and button presses on a keyboard I do are mostly 40-70ms long and about 30ms if I press intentionally fast (could be even faster, that's considering keyboard's own debounce). Add some switch bounce and half of those won't be registered by this chip. A good working switch by itself can easily bounce for 10ms and sometimes more depending on the type. Something like TACT switch may never stop slightly bouncing if you slightly move the finger while button is pressed. There is absolutely no need to wait until closed contact is 100% stable, especially for this long. In fact there is no need to debounce button press at all (beside removing possible electrical interference in noisy environment) as switch does not bounce in open state and thus only button release actually needs a debounce (this sort of algorithm would be fine if used for that alone). Contact present even for a brief moment means that switch is certainly either pressed or didn't change the state yet when just released. I have a washing machine with switch debounce of this sort, and I passionately hate using its interface because it prohibits me doing things too fast.

[exe]

I don't think this is meant for keyboards. Though, tbh, I'm not sure if there is much advantage in doing debouncing in hardware, rather in software. Software debouncing requires less components (=cheaper and less pcb real estate)  and can be fine-tuned. Change my mind)

In my last project I do like below. This way there is no delay when the keypress is registered, but it won't let to press the same button twice too fast (300ms in my case, intentionally large as device doesn't require much input, but low-enough not to annoy).

The actual code from rp2040 and micropython:
```
    def on_press(self, *args):
        now = time.ticks_ms()
        if time.ticks_diff(now, self.last_push) > 300:
            self.last_push = now
            self.cb()  # callback
```

PS I realized there is a small bug in the code. Timer can overflow, so every TICKS_MAX (internet says it's ~300 hours), if the key was not pressed, it will be "blind" for 300ms. I can live with that)

[jpanhalt]

If you can press and release in 30 ms or less, you might make Vladimir Horowitz look slow.  In a study of cell phone gestures, the average tap was 83 ms (n=13 subjects).  It was the fastest of the gestures tested.
Source:
https://pubmed.ncbi.nlm.nih.gov/28314216/#:~:text=The%20direction%20of%20force%20application,at%20421(181)ms.

I disagree on need for debouncing.  Of course, there are different ways to code around that, but constructively, they are doing debounce.  The TS specifically wanted a chip to debounce, not advice on debouncing.

[aliarifat794]

You can design, print and make a breakout board for this IC. 

[wraper]

If you can press and release in 30 ms or less, you might make Vladimir Horowitz look slow.  In a study of cell phone gestures, the average tap was 83 ms (n=13 subjects).  It was the fastest of the gestures tested.
Source:
https://pubmed.ncbi.nlm.nih.gov/28314216/#:~:text=The%20direction%20of%20force%20application,at%20421(181)ms.

I disagree on need for debouncing.  Of course, there are different ways to code around that, but constructively, they are doing debounce.  The TS specifically wanted a chip to debounce, not advice on debouncing.

Why in hell you compare button press with touch gestures? Not to say what matters is how fast it can be, not average. Something may work on average but fail miserably regardless. Not to say I said not a duration of a whole movement but for how long contact is closed.
EDIT: I just tried this https://cps-check.com/keyboard-cp and got 7.5 hits per second = 133ms for the entire movement, at least 2/3 of which is button being in depressed state. With shallow movement switches you can be even faster, and it's not unrealistic use case at all. One example is when you want to adjust time or some other setting quickly.

[eeguy]

In my application, the switch is used as a limit switch to prevent a moving thing from reaching the end of a rail and continuing to move to cause damage. So, the activation is not press and release and repeat. It is more like press continuously and stop before the motor or mechanical structure gets damaged. Tried a few software approaches posted on the internet but did not work well.

By the way, what adapter should I use if I want to insert an IC chip with 14DIP to a breadboard?

[wraper]

In my application, the switch is used as a limit switch to prevent a moving thing from reaching the end of a rail and continuing to move to cause damage. So, the activation is not press and release and repeat. It is more like press continuously and stop before the motor or mechanical structure gets damaged. Tried a few software approaches posted on the internet but did not work well.

By the way, what adapter should I use if I want to insert an IC chip with 14DIP to a breadboard?

Depending on what it is, 40+ms delay may be not the best idea. Not to say variable delay may introduce additional uncertainty if it's used for homing. I don't think you need a debounce for this at all.

[shapirus]

In my application, the switch is used as a limit switch to prevent a moving thing from reaching the end of a rail and continuing to move to cause damage. So, the activation is not press and release and repeat. It is more like press continuously and stop before the motor or mechanical structure gets damaged. Tried a few software approaches posted on the internet but did not work well.

Sounds like a latch operation to me rather than what is normally considered debouncing. Latch in a certain state (motor disable) on receiving first pulse (when the switch makes first contact), then send a reset pulse when a respective condition is met.
That's something that can be done with a D flip-flop or an SR latch. Shouldn't be a problem to implement in software, either, unless there is more to it: I didn't quite get the "press continuously" part. Why should we care for what happens after first contact is made and before we determine that it's safe to reset the "motor stop" state?

By the way, what adapter should I use if I want to insert an IC chip with 14DIP to a breadboard?

Something like this:

https://www.aliexpress.com/item/1005002396961323.html

There are many listings, SSOP20 to DIP adapters are easy to find.

(note that MAX6818 is SSOP20, not SSOP14)

[eeguy]

In my application, the switch is used as a limit switch to prevent a moving thing from reaching the end of a rail and continuing to move to cause damage. So, the activation is not press and release and repeat. It is more like press continuously and stop before the motor or mechanical structure gets damaged. Tried a few software approaches posted on the internet but did not work well.

Sounds like a latch operation to me rather than what is normally considered debouncing. Latch in a certain state (motor disable) on receiving first pulse (when the switch makes first contact), then send a reset pulse when a respective condition is met.
That's something that can be done with a D flip-flop or an SR latch. Shouldn't be a problem to implement in software, either, unless there is more to it: I didn't quite get the "press continuously" part. Why should we care for what happens after first contact is made and before we determine that it's safe to reset the "motor stop" state?

By the way, what adapter should I use if I want to insert an IC chip with 14DIP to a breadboard?

Something like this:

https://www.aliexpress.com/item/1005002396961323.html

There are many listings, SSOP20 to DIP adapters are easy to find.

(note that MAX6818 is SSOP20, not SSOP14)

Exactly! As soon as the first contact is made, I want the motor to stop immediately or backtrack to a certain distance for homing.
When I tried the software approach of denouncing by following some guides on youtube, either the motor continued to move and stopped with a delay of about 1-1.5 seconds or the thing driven by the motor continued to move to press against the switch as if the system did not detect the button had been pressed.

I was talking about adaptor for the SN74HC14N Schmitt Trigger IC chip from Texas Instruments. It has 14 DIP/PDIP. Sorry for the confusion. Should have posted on a separate thread.

[shapirus]

I was talking about adaptor for the SN74HC14N Schmitt Trigger IC chip from Texas Instruments. It has 14 DIP/PDIP. Sorry for the confusion. Should have posted on a separate thread.

There are "NR" and "NSR" suffixes. The former is a through-hole DIP package which doesn't require any adapter to be used with a breadboard. The latter is an SMD SO-14 for which it is very easy to find breakout boards, just search for "SO14 DIP adapter".
There are SMD ZIF socket adapters too, which may be more convenient by making soldering unnecessary: https://www.aliexpress.com/item/1005003958961361.html (SOP14 is a synonym for SO14 and SOIC14 if I'm not wrong -- someone please correct me if I am).

[wraper]

Exactly! As soon as the first contact is made, I want the motor to stop immediately or backtrack to a certain distance for homing.
When I tried the software approach of denouncing by following some guides on youtube, either the motor continued to move and stopped with a delay of about 1-1.5 seconds or the thing driven by the motor continued to move to press against the switch as if the system did not detect the button had been pressed.

Again, why do you even want to debounce it? Debouncing is to avoid detecting multiple button presses when only one was made. All you care about is that switch was activated at all, not how many times. Not to say if the switch becomes finicky, you'd rater have false positives (not that it will actually happen unless switch is totally broken), not re-veryfiing and asking it "are you sure?" while mechanics are self destroying.

[Peabody]

It seems the software solutions you tried waited until the switch stopped bouncing, or just waited long enough to be sure any bouncing had stopped, before recognizing that the switch had been pressed in the first place.  What you want is to immediately recognize a press, then poll it until it continuouly reads as released for a certain time, like maybe 100ms, before recognizing a release.

If you use a debouncer chip, you need to be really clear about how it works - what the algorithm is.  But it's not clear that you need anything but the right software solution.

[eeguy]

Exactly! As soon as the first contact is made, I want the motor to stop immediately or backtrack to a certain distance for homing.
When I tried the software approach of denouncing by following some guides on youtube, either the motor continued to move and stopped with a delay of about 1-1.5 seconds or the thing driven by the motor continued to move to press against the switch as if the system did not detect the button had been pressed.

Again, why do you even want to debounce it? Debouncing is to avoid detecting multiple button presses when only one was made. All you care about is that switch was activated at all, not how many times. Not to say if the switch becomes finicky, you'd rater have false positives (not that it will actually happen unless switch is totally broken), not re-veryfiing and asking it "are you sure?" while mechanics are self destroying.

I talked about the two problems I mentioned and somebody suggested Denouncing. Perhaps it was an incorrect advice.

[shapirus]

I talked about the two problems I mentioned and somebody suggested Denouncing. Perhaps it was an incorrect advice.

That can be thought of as debouncing, too, only the logic may be different from what you've tried so far.

It looks like you need pretty much the following:

1. If the switch is closed then set the "alarm" state high and (re)start a countdown timer (say 100 ms)
2. If the timer expires (which can only happen no less than 100 ms after the switch was released), then set the "alarm" state low
3. Goto 1

It's fairly easy to do in both hardware and software, although doing it in software requires that the controller receiving the signal from the switch is able to detect short-lasting pulses, or they need to be pre-conditioned.

In hardware, this can be achieved using what's called a retriggerable monostable multivibrator, with a caveat that retriggering must happen not only on the rising edge (i.e., low->high transition), but as long as the switch is closed. A very simple implementation would be a schmitt-trigger buffer or inverter that charges an RC circuit.

Here's what you can do using the hex schmitt trigger inverter IC (74<whatever>14) that you mentioned:




The voltage-controlled switch shown is controlled by a voltage source that emits 6 pulses each 5 ms wide, simulating bouncing contacts.
Resistor R3 limits the current that the inverter has to source when it's charging the timing capacitor. It introduces some (generally undesired) delay after the first contact is made and the alarm state going high, but it, considering the application, is very short: simulation shows only ~35 microseconds when R3=200 Ohms (100 Ohms, as shown in the schematic, is a bit too low -- consult the datasheet).


Here's how it simulates.




Then of course you'll have some additional logic for "what to do when the alarm state goes high", but it's another story.

[eeguy]

I talked about the two problems I mentioned and somebody suggested Denouncing. Perhaps it was an incorrect advice.

That can be thought of as debouncing, too, only the logic may be different from what you've tried so far.

It looks like you need pretty much the following:

1. If the switch is closed then set the "alarm" state high and (re)start a countdown timer (say 100 ms)
2. If the timer expires (which can only happen no less than 100 ms after the switch was released), then set the "alarm" state low
3. Goto 1

It's fairly easy to do in both hardware and software, although doing it in software requires that the controller receiving the signal from the switch is able to detect short-lasting pulses, or they need to be pre-conditioned.

In hardware, this can be achieved using what's called a retriggerable monostable multivibrator, with a caveat that retriggering must happen not only on the rising edge (i.e., low->high transition), but as long as the switch is closed. A very simple implementation would be a schmitt-trigger buffer or inverter that charges an RC circuit.

Here's what you can do using the hex schmitt trigger inverter IC (74<whatever>14) that you mentioned:

(Attachment Link)


The voltage-controlled switch shown is controlled by a voltage source that emits 6 pulses each 5 ms wide, simulating bouncing contacts.
Resistor R3 limits the current that the inverter has to source when it's charging the timing capacitor. It introduces some (generally undesired) delay after the first contact is made and the alarm state going high, but it, considering the application, is very short: simulation shows only ~35 microseconds when R3=200 Ohms (100 Ohms, as shown in the schematic, is a bit too low -- consult the datasheet).


Here's how it simulates.

(Attachment Link)


Then of course you'll have some additional logic for "what to do when the alarm state goes high", but it's another story.

Thank you. The switch I use produces a high voltage when it is not pressed. It is supposed to drop to zero when pressed. So high to low upon activation. Will your circuit work in this configuration?

[shapirus]

Thank you. The switch I use produces a high voltage when it is not pressed. It is supposed to drop to zero when pressed. So high to low upon activation. Will your circuit work in this configuration?

Well, in my example it's the same: the switch pulls the control node to ground when pressed. Either way, I showed a concept, and it's up to you to adapt it to your specific case, if it looks suitable.

The idea is simple: when the button is pressed, the first inverter's input is pulled to ground, output goes high and quickly charges C1 and drives input of the second inverter high, so its output goes low and is then inverted again with the third inverter, setting the ALARM node high. Now the task is to keep that high level for some time even if the button is released (including the period of contacts bounce).

When the button is released, the first inverter's input goes high, its output goes low, but it cannot discharge C1 because of the diode. Instead, C1 is slowly discharged via R2 (and the input of the second inverter, but it can normally be ignored, as it has high input impedance -- however I believe I saw it simulated as just 1 MOhm, so YMMV, make sure you test it in hardware). Once it discharges to a low enough voltage, the second inverter triggers and its output goes high, then it's inverted again, and the ALARM node goes low. That's what you can see in the simulation plot.

It's not the best implementation (reaction time is limited by the charging time of C1, so it depends on a specific pattern of the contacts bouncing), but it's one of the simplest. The mentioned disadvantage can be mitigated to some extent by reducing the value of C1 and increasing the value of R2 accordingly. A more advanced implementation would use e.g. a D flip-flop that would toggle its output immediately as the switch makes even the shortest lasting contact, and then something similar to my example to keep the alarm state active for some time after no more button contacts closing is detected.

p.s. of course I had to write a disclaimer: I haven't assembled it in hardware, I only simulated it. I have no reason to believe that it won't work in real hardware, but YMMV.