trejo@nprdc.arpa (Leonard J. Trejo) (03/30/89)
We're planning to buy a microcomputer for conducting
psychophysiological experiments. We now use a Masscomp 5500 running
RTU 4.0 ("real-time" UNIX) to control presentation of graphics stimuli
and to digitize and store physiological signals. Problem is that RTU's
time is not "real" enough for some of the things we want to do. For
example, we want to flash a visual stimulus on a graphics monitor
for exactly one video field at 125 ms after the onset of data
acquisition on an A/D converter and then record the response latency
of a subject (button-press) to the picture with an accuracy of 1
ms. Everything must be synchronized to within 1 ms, e.g.
|------------S---------------R---------------------|
| | | |
Time 0 125 X 1000
(ms)
Start Stimulus Response End
A/D Onset Time A/D
Transfer Time Transfer
S should be 125 +/- 1ms and X should be measured to within +/- 1ms.
On the Masscomp we time S by putting a light sensor on the face of the
graphics CRT which sends a pulse into one channel of the A/D
converter. Although it's a bit awkward, this can provide stimulus
timing accuracy limited only by A/D sampling rate, which can go up to 1
MHz/# channels. We can time X similarly. However, this only works
well for simple events, such as the whole screen turning on or off. It
wouldn't work for the appearance of a character on the screen whose
coordinates vary from trial to trial. Besides, we want to get rid of
the screen sensor and use a mouse for subject responses.
Our thinking now is to acquire a dedicated PC (e.g. an 80386 based AT
clone) to produce stimuli and measure responses. The system should be
able to do the following:
o Be able to send a 16-bit parallel word out which marks the onset
time of a visual (graphic) stimulus (one per video field)
with a latency of 1 ms or less. This to be followed within
100 ms by two words which code the type of stimulus and its
screen coordinates.
o Be able to respond to a mouse button press and send a parallel
word out in 1 ms or less which marks the time a mouse button is
pressed (this is probably asking too much). This to be followed
within 100 ms by two more words which code which buttons were
pressed and mouse coordinates when pressed.
o Graphics capability of minimum 640 by 480 pixels with
independently addressable color lookup tables using 8-bit (
or higher) D/A converters (i.e. 16.7 M color palette).
Also capable of simple animation (e.g. video game quality).
Library of C graphics subroutines. Sound-producing chip
would be a plus.
o C compiler. (UNIX development system would be a plus, but
is not required.)
o Cost of hardware and O/S to be about $5K.
Most of this boils down to very tight coordination between graphics
and parallel digital I/O plus fast intterrupt responses.
We'll use this PC as a fancy stimulator which sends/receives event-related
synchronizing digital signals to the Masscomp. These signals will be
monitored by a fast parallel I/O board controlled by the Masscomp
data acquistion/control processor, which will coordinate the digital
and analog I/O. Thus, the Masscomp will serve as a fancy A/D
converter and near-real-time signal processor.
Sorry to be so long-winded, but if you have suggestions please send
them to my by e-mail. If there's interest, I'll post a summary.
Thanks in advance.
L. J. T.
============================================================================
ARPANET : trejo@nprdc.arpa UUCP: ucsd!nprdc!trejo
Phone: (619) 553-7981 Postal Address: Leonard J. Trejo, Ph. D.
(AV) 553-7981 NPRDC
Code 52
San Diego, CA 92152-6800nusip@maccs.mcmaster.ca (Mike Borza) (04/17/89)
[Moderators Note:- This newsgroup goes around the planet. I've been
asked to try and ensure that i/ the content is worth it, and ii/
that it isn't too long. With this in mind, in future, would people
please try and be brief. Thanks... - Der]
I tried emailing this response to
<gatech!ucsd!nprdc.arpa!trejo@uunet.UU.NET>
(whose name I've now lost), but it bounced, so I'm posting it here.
This is a response to a recent request for information on real-time
physiological data acquisition.
I've worked on a similar project, with the exception that we
had considerably tighter timing requirements (athough still not
particularly tight as real-time data acquisition systems go). We were
working at extracting audio evoked potentials from single trials on
4 channels at 10 kHz/channel. (Visuals were a little down the road.)
We were able to do this with an 8 MHz IBM 339 AT (a machine I'd not
recommend). By carefully interleaving start of conversion and a
computation loop, we could collect on 4 channels at this rate with a
simple artifact rejection algorithm in place.
Anyway, I'd suggest that you change your approach slightly. I like your
idea about sampling the screen to resolve your stimulus arrival time,
but I'd suggest using an indirect method to determine the start of the
stimulus. From your posting, it appears that you're going to go with a
PC/AT or 386/AT type machine, either of which should suffice. I'd suggest
running under MS-DOS (more about this later). From the description of
your video requirements, you'll be running a VGA or enhanced EGA. Since
you know (or can determine) the character (or pixel) position on the
screen, you can sit in a tight loop sampling the status bit in the EGA/VGA
registers which indicates the beginning of horizontal re-trace. You can
compute the start of stimulus as an offset from this time using the
character position and the scan rate, to within the loop time and
the dot clock time. Naturally, you also have to be careful to write the
character to video memory such that you know that it doesn't appear one cycle
early. If necessary, your tight loop can also be collecting data during
the pre-stimulus phase.
I'd suggest MS-DOS rather than UNIX (with real-time extensions), and just
take over the machine during your data collection sessions. This gives you
easier control over the machine and removes some possible unwanted
interruptions. QNX is another possibility, but I'm not sure of the
interrupt latency. I did all the code development and maintenance for our
system on a '286 running Microport Unix. To test the high-level code,
I wrote an emulator to fake the d/a and a/d subsystems. The low-level
stuff had to be debugged in situ on the MS-DOS machine. The data
acquisition subsystem was a single-board unit from Scientific Solutions
(a.k.a. Tecmar) for about $CDN 1000-- there are probably better ones around.
We built the outboard antialiasing filters, sample and hold amps, and
digital I/O isolation ourselves from off-the-shelf chips. Given your
rather coarse timing requirements, you can probably make do with a PC/AT
clone at 10-16 MHz, but given the price differential, I'd just get a cheap
16 or 20 MHz 386 box. The bonus is that it's a nice cross development
environment for DOS if you get VP/ix or Merge for it, so it's easy to test
your high level stuff, and you can use it for something else when you
finish this line of research (or your funding runs out:). (You won't be
able to test the low-level stuff that reads EGA reg's or anything like
that.) I'm using ISC's 386/ix and like it a lot (though I no longer do
any DOS work, and only started VP/ix out of curiosity a couple of
times). For bang-fer-the-buck, Everex's ENIX seems to be the best value
these days.
I'd also suggest polling the various port states rather than writing
interrupt handlers. On a slower AT box, the interrupt latency can be
several microseconds, which would have completely fried our single
channel 40 kHz experiments. You can test for false responses at various
points and have the software restart the collection automatically in
the event of "super-human" response times.
Hope this helps.
mike borza <antel!mike@maccs.uucp or boopsy!mike@maccs.uucp>