debounce time

[Tobias]

Sorry for my bad English, I just literally translated from German
where "self-made" (selbstgemacht) doesn't necessarily mean that you
yourself made it but also that someone else might have made it
himself. As opposed to mass production related stuff.

Anyway, your code works. Thanks for that!

On 14 Jul., 21:37, David McFarlane <mcfar... at msu.edu> wrote:
> 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... 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.