debounce time

David McFarlane mcfarla9 at msu.edu
Thu Jul 14 19:37:41 UTC 2011


Tobias,

<gentle_ribbing>
Hmm, "I have just received a nice self-made buttonbox..."??  If it is 
self-made then you could not receive it, because you already have it; 
if you just received it then it is not self-made.  Perhaps you meant 
"custom-made".  But I quibble...
</gentle_ribbing>

Like Paul Groot said, it is best to use hardware-debounced switches, 
and the circuitry for that is very straightforward, you can also find 
instructions in the classic text "The Art of Electronics" by Horowitz 
& Hill.  Every lab should have someone who is familiar with that text.

Nevertheless I rarely follow that advice myself because, even though 
the circuitry is trivial, it requires a power source, and that just 
makes things a tad too inconvenient for me (the parallel port does 
not include any power source).  I like simmple passive circuitry 
whenever I can get away with it.  And in almost every case the task 
itself presents sufficient delay between responses so that switch 
bouncing does not present a problem.

But I gather you need this for something like a rapid tapping task, 
where switch bounces become a problem.  For our tapping tasks we 
solve this by running a custom passive-switch box much like yours 
through an SRBox -- that way we get switches with good mechanical 
feel combined with the ease of use of the SRBox, and still have 
sub-millisecond resolution.

But as a last resort I will do software debouncing.  The cheapest way 
to do that is just to add a sufficient Sleep after a response, and 
trust both that no further responses come in during that Sleep and 
that the switch finishes bouncing during that Sleep.  I would rather 
have something more secure.  So here is an example of the sort of 
code I might use, using a ReadPort (you would have to modify this if 
you use an input mask, but you can handle that) (I did not test this, 
just constructed it from memory, so caveat user):

Const  PortAdd as Integer = &hABCD  ' just an example, replace with 
real port address
Const  BitMask as Integer = &H01
Const  DtDebounce as Long = 50  ' ms
Dim  tDebounce as Long
tDebounce = Clock.Read + DtDebounce
Do Until (Clock.Read >= tDebounce)
     If ((ReadPort(PortAdd) and BitMask) <> 0) Then _
         tDebounce = Clock.Read + DtDebounce
Loop

The example supposes that we are only interested in bit 0 of the 
input, and that a bit value of 1 indicates button pressed, while a 
bit value of 0 indicates button released.  The code simply considers 
bouncing to be over as soon as it finds that the button has been 
released for (in this example) 50 ms without interruption.  More 
specifically, it starts by setting a goal of (in this example) 50 ms 
from now.  It then monitors the input until it reaches the goal 
time.  If it detects another button press during this time, then it 
resets the goal for (in this example) 50 ms more from the current 
time, and continues.  As a result, the program runs this loop as long 
as the button is pressed, and does not move on until 50 ms after the 
button has been fully released and all bouncing is done.

This code could go either right before you want to get a response, or 
right after you have gotten your response.

<editorial>
Pretty cool if Presentation has a "dead-time" setting, maybe yet 
another reason to consider it as an alternative to E-Prime.
</editorial>

-- David McFarlane, Professional Faultfinder


At 7/14/2011 07:54 AM Thursday, Paul Groot wrote:
>Hi Tobias,
>
>You're right. Mechanical switches suffer from this debounce effect.
>Especially if the switch becomes older! In most cases this is not an
>issue if you are only interested in the response time of a single
>button press. When repeating presses are allowed, an 'ignore interval'
>of about 50 ms should be enough for even the worst switches. Things
>become more complicated when several buttons are allowed to be
>pressed. An electrical solution using a Schmitt trigger is preferred
>in that case (for example:
>http://www.labbookpages.co.uk/electronics/debounce.html)
>
>Unfortunately Eprime has no dead-time setting as Presentation does...;-((
>
>best
>Paul
>
>2011/7/14 Tobias <tobias.fw at gmail.com>:
> > Dear E-Prime community,
> >
> > I have just received a nice self-made buttonbox with three buttons
> > that can be attached to a parallel port. THus I have very good timing
> > of RTs for my experiments now :)
> >
> > However, there seems to be a problem with the bouncing of the keys.
> > Single key presses cause several signals in a row. That is, if I have
> > two consecutive slides with a duration of "-1", one key press is
> > enough to terminate both slides.
> >
> > A collegue of mine said that in the experimental software
> > 'Presentation', a debounce time can be specified so that such double
> > responses are not possible.
> >
> > Is there any way of doing so in E-Prime?
> >
> > Best,
> > Tobias

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.



More information about the Eprime mailing list