[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reaction time measures

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 (
http://www.cortex.salk.edu/CortexCircuit.php ), 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

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 http://www.m-audio.com/images/global/manuals/070208_Delta1010_UG_EN01.pdf (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 http://www.logix4u.net/inpout32.htm 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 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