Is there a breadboard compatible version of MAX6818 switch debouncer? - Page 1
Forum section: electronics / beginners

author: eeguy
author_rank: Regular Contributor
timestamp: May 22, 2024, 02:49:30 pm
content: It seems that they are in SMD form. I am looking for one that is compatible with breadboard.

author: K5_489
author_rank: Regular Contributor
timestamp: May 22, 2024, 03:34:05 pm
content: SMD Breakout boards -https://www.adafruit.com/category/198Use just about any type of SMD component in a breadboard.

author: jpanhalt
author_rank: Super Contributor
timestamp: May 22, 2024, 05:37:48 pm
content: 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

author: eeguy
author_rank: Regular Contributor
timestamp: May 23, 2024, 03:22:27 am
content: 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

author: wraper
author_rank: Unknown
timestamp: May 23, 2024, 04:33:22 am
content: 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.QuoteA 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.

author: jpanhalt
author_rank: Super Contributor
timestamp: May 23, 2024, 05:51:15 am
content: 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?

author: wraper
author_rank: Unknown
timestamp: May 23, 2024, 06:38:07 am
content: Quote from: jpanhalt on May 23, 2024, 05:51:15 amAsk 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.

author: exe
author_rank: Unknown
timestamp: May 23, 2024, 07:13:40 am
content: 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 isno 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 = nowself.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)

author: jpanhalt
author_rank: Super Contributor
timestamp: May 23, 2024, 10:05:23 am
content: 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.

author: aliarifat794
author_rank: Regular Contributor
timestamp: May 23, 2024, 10:08:30 am
content: You can design, print and make a breakout board for this IC.

author: wraper
author_rank: Unknown
timestamp: May 23, 2024, 10:51:44 am
content: Quote from: jpanhalt on May 23, 2024, 10:05:23 amWhy 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 thishttps://cps-check.com/keyboard-cpand 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.

author: eeguy
author_rank: Regular Contributor
timestamp: May 23, 2024, 12:15:39 pm
content: 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?

author: wraper
author_rank: Unknown
timestamp: May 23, 2024, 12:28:08 pm
content: Quote from: eeguy on May 23, 2024, 12:15:39 pmDepending 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.

author: shapirus
author_rank: Super Contributor
timestamp: May 23, 2024, 12:30:31 pm
content: Quote from: eeguy on May 23, 2024, 12:15:39 pmSounds 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?Quote from: eeguy on May 23, 2024, 12:15:39 pmSomething like this:https://www.aliexpress.com/item/1005002396961323.htmlThere are many listings, SSOP20 to DIP adapters are easy to find.(note that MAX6818 is SSOP20, not SSOP14)

author: eeguy
author_rank: Regular Contributor
timestamp: May 23, 2024, 12:51:39 pm
content: Quote from: shapirus on May 23, 2024, 12:30:31 pmExactly! 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.

author: shapirus
author_rank: Super Contributor
timestamp: May 23, 2024, 01:11:17 pm
content: Quote from: eeguy on May 23, 2024, 12:51:39 pmThere 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).

author: wraper
author_rank: Unknown
timestamp: May 23, 2024, 01:17:10 pm
content: Quote from: eeguy on May 23, 2024, 12:51:39 pmAgain, 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.

author: Peabody
author_rank: Super Contributor
timestamp: May 23, 2024, 01:50:53 pm
content: 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.

author: eeguy
author_rank: Regular Contributor
timestamp: May 23, 2024, 02:30:51 pm
content: Quote from: wraper on May 23, 2024, 01:17:10 pmI talked about the two problems I mentioned and somebody suggested Denouncing. Perhaps it was an incorrect advice.

author: shapirus
author_rank: Super Contributor
timestamp: May 23, 2024, 04:01:53 pm
content: Quote from: eeguy on May 23, 2024, 02:30:51 pmThat 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 low3. Goto 1It'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.

author: eeguy
author_rank: Regular Contributor
timestamp: May 26, 2024, 05:40:25 pm
content: Quote from: shapirus on May 23, 2024, 04:01:53 pmThank 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?

author: shapirus
author_rank: Super Contributor
timestamp: May 26, 2024, 07:25:34 pm
content: Quote from: eeguy on May 26, 2024, 05:40:25 pmWell, 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.