How do you debounce a clapping monkey?
Probes The Monkey makes his return.
All about contact debouncing, setting up a universal counter as an event counter, and other issues that can arise on a seemingly simple test setup.
Interesting. I would have used a hall sensor or optics and filtered it in the digital domain. Looking forward to seeing the actual testing of that little boost converter.
We were taught to use a latch to debounce a switch at Uni
"how many times it claps" in a chinese or japanese accent would be much more funny
Or German. "Ve haf veys of making you clap, monkey!"
Worth mentioning is also that constantly shorting a capacitor will over time seriously corrode the contact surfaces, so the circuit will appear to work in the beginning but may stop counting after a while.
Use an Arduino!
It's two minutes' work to write a sketch that waits a minimum time between claps.
It can output pulses to your counter for display.
pinMode(counterOut,OUTPUT);
pinMode(clap,INPUT_PULLUP);
if (digitalRead(clap)==0) {
// This creates 20ms of delay before it will recognize another clap
// Adjust timing as needed
digitalWrite(counterOut,LOW);
delay(10);
digitalWrite(counterOut,HIGH);
delay(10);
}
It's two minutes' work to write a sketch that waits a minimum time between claps.
Will that be reliable if there's noise on the line when it's making the squeaking noises?
Whilst the 330uF cap across the inputs of the counter is, frankly, at least 10x too large for this job, it does suggest the false counting from the head nodding motor noise has to be common mode noise, because that massive cap creates a low impedance AC "short" across the input of the counter. Putting the two leads from Probes hands together a couple of turns round a large ferrite (as a common mode choke) would probably have fixed the issue without requiring the pass filter device used!
This was great lesson. What appears on the surface to be a pointless and silly exercise turns out to be a good lesson in setting up a test and some basic functions of multiple pieces of test gear, and even various signal issues such as noise, shape, etc.
It's two minutes' work to write a sketch that waits a minimum time between claps.
Will that be reliable if there's noise on the line when it's making the squeaking noises?
If there's
that much noise on the line then the entire setup won't work anyway, doesn't matter what you do.
I think Dave's choice of components in the video isn't great - the capacitor/resistor values are much too large and will leave it very susceptible to noise. Maybe he chose those values to make a pretty video (see the capacitor charge!). In real life the capacitor should recharge in much less than a second.
Just saw this while surfing...
Most top-end counters have a gate hold-off or delay so that once it triggers, it will not trigger again for the delay/hold-off time you set.
With this method, the noise becomes irrelevant because the counter trigger is disabled for the duration of the noise.
Doesn't this counter have a delay->time setting?
Edit: had a quick look at the manual and it looks like it does have a delay function but it may be it only works with the external gate input. Not sure about that.
Mm, not sure if it's a good idea to measure number of "cycles" versus exact numbers of claps.
If I recall correctly from previous videos Probes The Monkey does slow down in clapping quite significantly at lower voltage levels.
Thus you'll reach a point where it becomes a little trickier in determining exactly what one cycle is.
Since one clap at low voltage could be as long as one entire cycle at nominal voltage.
Other than that, super interesting video!~ Thanks much
Whilst the 330uF cap across the inputs of the counter is, frankly, at least 10x too large for this job, it does suggest the false counting from the head nodding motor noise has to be common mode noise, because that massive cap creates a low impedance AC "short" across the input of the counter. Putting the two leads from Probes hands together a couple of turns round a large ferrite (as a common mode choke) would probably have fixed the issue without requiring the pass filter device used!
I agree on this one, in fact I would say it's at least 1000x to large for a normal design. For a simple one-time solution like Dave needs here a quick-and-dirty solution is more acceptable, but I was hoping for a 555 solution right from the start.
This circuit is also a bit high on the load of the batteries that feed the switch. At each (1st)clap 1mC is thrown away. So I expect the batteries are starting to drain after a couple of thousand claps.
It's two minutes' work to write a sketch that waits a minimum time between claps.
Will that be reliable if there's noise on the line when it's making the squeaking noises?
If there's that much noise on the line then the entire setup won't work anyway, doesn't matter what you do.
I think Dave's choice of components in the video isn't great - the capacitor/resistor values are much too large and will leave it very susceptible to noise. Maybe he chose those values to make a pretty video (see the capacitor charge!). In real life the capacitor should recharge in much less than a second.
I think the micro is fine but not use a simple delay. You really want a counter running at some rate faster than the cycle time that is reading the input and waiting for it to settle. Any change in the input state resets the counter. So you want what ever your debounce time to be a number of consecutive reads of the input with no state change.
if clear = '1' then
state <= S_INIT;
cnt <= (others => '0'); -- Reset filter timer
filt_out <= '0'; -- Force output low
elsif (clock'event and clock = '1') then
case state is
when S_INIT =>
nt <= (others => '0'); -- Reset filter timer
if input /= filt_out then -- Test input state change
state <= S_SETTLE; -- Wait for input to settle
end if;
when S_SETTLE =>
cnt <= cnt + 1; -- Increment the filter timer
if input = filt_out then -- Check if input glitched
state <= S_INIT; -- Glitched, reset filter
elsif cnt > FILTPERIOD then -- Check filter timeout
state <= S_DEBNCED; -- We have a clean signal
end if;
when S_DEBNCED =>
filt_out <= input; -- Change output state
state <= S_INIT; -- Reset filter and search for next edge
when others=>
state <= s0; -- We are lost, reset filter
end case;
end if;
This circuit is also a bit high on the load of the batteries that feed the switch. At each (1st)clap 1mC is thrown away. So I expect the batteries are starting to drain after a couple of thousand claps.
No worries, mate! Just slap a batteriser on it, and she'll be right!
In all seriousness though, the batteries driving the switch detector circuitry should last an order of magnitude or so longer than the batteries driving Probes, no?
Use an Arduino!
It's two minutes' work to write a sketch that waits a minimum time between claps.
It can output pulses to your counter for display.
You keep the switch pressed and have a 50Hz signal generator. Great solution there, buddy.
Kudos on the blocking code.
Yet after ALL that work, I see the monkey STILL bounces after he claps....
Worth mentioning is also that constantly shorting a capacitor will over time seriously corrode the contact surfaces, so the circuit will appear to work in the beginning but may stop counting after a while.
Good point there. I always yell pissed, where someone puts a pair of 100n caps directly accross a mechanical rotary encoder, as a means of debouncing the contacts.