Re: reaction time measures (Pawel Kusmierek )

Subject: Re: reaction time measures
From:    Pawel Kusmierek  <pawel.kusmierek@xxxxxxxx>
Date:    Sun, 10 Jun 2007 16:30:58 -0400

I'd like to continue this discussion, I find it very informative, hopefully others too. If not, please let me know, and I'll switch to bothering Bob off-list. > On 9 Jun 2007 at 14:48, Pawel Kusmierek wrote: > > I think that you could do the same with visual stimuli by attaching a > > sensor (photoresistor, photodiode) to an area somewhere near the > > border of your screen and displaying a marker in this area along with > > your stimulus. The signal from the sensor could go to your soundcard's > > input (via an appropriate circuit) for recording in one channel, and > > behavioral responses would be recorded on the other channel. This > > requires some external hardware, but I believe it could be small, > > especially if you use a USB port to power it. > > Interesting idea! Sort of like an old "light pen", but at a fixed location. > The circuitry would be pretty simple, needing only to stretch the > short dot-clock pulse to something suitable for the sound card. > (Or with a slow-responding photoresistor, maybe even this wouldn't > be needed.) I thought this would not be necessary, (but I do not know what a "dot clock pulse" is). I thought that usually LCDs (we are talking about a laptop, right?) are accused of being too slow rather than too fast, and even if the picture (and the marker) was displayed for a single frame, the signal would last a few ms. The other thing is that the marker might be left on after the picture (stimulus) is turned off, if necessary. Is there anything about LCD technology that would make the marker last for a too short time to be detected by a soundcard? Another nice way to make sure that a possibly very short input signal won't be missed by the input is to use a flip-flop circuit which keeps the input high until the computer reads it. Then the computer clears the circuit and may receive another input. This has been used by the Cortex spike recording program ( ), and I am using this solution in my program. This is probably again more suitable for TTL I/O than for soundcard-based I/O. > I have not tested any true multichannel input cards. Note that the vast > majority of "multichannel" cards (5.1, 7.1, etc) are referring to the > outputs... they still have only stereo inputs. However, a few "semi-pro" and > "pro" cards have 4 (or more) inputs, though I believe they require special > software. I referred to the semi-pro cards, like M-Audio delta series, not the x.1 things. I have no direct experience with multichannel cards, so I might get wrong impression from reading their manuals. > Nonetheless, I am certain that they retain perfect sync between > channels. I have never heard of a card that appears as multiple stereo > inputs; it would be the same as having multiple stereo cards. Except these "stereo" cards would (or should) be perfectly synchronized, because they use the same clock. Still don't how to handle this in windows without losing the relative timing between the pairs. I am pretty sure that audio recording programs can do this - so it should be possible. I got the "appearing as multiple stereo cards" idea from manuals like (see p. 12 there). > One problem is that Windows doesn't allow for easy dealing with the > parallel port lines as individual signals, like in the good old DOS days. > Win9x allowed direct I/O to the port, but later versions require special > ring-0 drivers. There will still be all the usual latencies in reading the > port, up to several milliseconds, so the experiment would have to > be such that there was no ambiguity about which TTL data went > with which sound card event. Yes, you are right. Do you have any knowledge about latencies caused by using such drivers (in addition to typical problems of timing under Windows)? I am using and the time between port checks is typically less than 50 us for about 20% of checks, less than 1 ms for 90 % of checks and less than 2 ms for 100% of checks. This would imply the the delay introduced by using the driver is less than 50 us, which would be negligible for me. But one can imagine that the driver uses a buffer and returns "old" data. This seems unlikely for me. Also, the timing of the data I am getting with this system seem to make sense - latency of neural response to sound in the auditory cortex is>= 10 ms. > For new designs, the printer port (and its attendant latency problems) could be > avoided by putting more processing into the audio inputs. Response buttons > could provide different DC levels. Each button could produce a short pulse of > a specified level, with different buttons having levels weighted in 1, 2, 4 > binary fashion. Or, each could produce a same-level pulse but with > different binary-weighted duration. Either way, you could always recover > the exact timing of the switch closures (pulse onsets) at sample-rate > resolution, even if multiple button presses overlapped in time. I am a little afraid that this may not work so well in real world, where sound card's input won't hold a DC signal. So the picture would be confounded by decays - have you tried this solution? Pawel -- Pawel Kusmierek PhD Department of Physiology and Biophysics Georgetown University Medical Center The Research Building WP23 3970 Reservoir Road NW Washington, DC 20007 phone: +1 202 687-8851 or 8028

This message came from the mail archive
maintained by:
DAn Ellis <>
Electrical Engineering Dept., Columbia University