Computers lend themselves to presenting human subjects with many repetitions of a test of bio-physiological performance.
Such a test typically measures some form of reaction time, and might consist of repeated measurements, known as trials. Each trial usually consists of the presentation of a stimulus, followed by a response from the subject. The time it takes the subject to respond appropriately to the stimulus, and the accuracy of their response, are the measured values.
Performing these tests requires the timing of real-world physical events with an accuracy of at least centi-seconds.
Note with respect to the statistical analysis of the results of
The tests are either of a Between Subjects or Within Subjects paradigm. In Within Subjects tests, the same subject is tested twice under different conditions. In Between Subjects tests, subjects are usually not tested twice, instead, the different conditions are applied to different subjects.
Since the analyses are nearly always performed on the differences between the times measured in each condition, rather than the absolute values of the times, the absolute values are less important. Consequently, it is more important that the timer is at least synchronised with the events, and less important that the timer is extremely accurate.
Note: It is not critical for the timer to start and stop exactly simultaneously with the start and stop events (stimulus and response), provided it starts and stops within a predictable (preferably constant) time of these events.
An accuracy of less than +/- 3% is typical for analogue measurements. Most of the times we measure in experiments are less than one second, and almost never more than five seconds. Assuming a typical reaction time value of one second, a timing accuracy of at least +/- 0.03sec (30 milliseconds) is required.
In addition to accuracy, there is also the matter of resolution, which is frequently confused with accuracy. Some software authors claim to achieve millisecond accuracy. However, it usually turns out that the time values their software recorded, whilst containing three decimal places, had an accuracy much worse than +/- one millisecond. In reality, they had confused resolution for accuracy. Their timer could measure milliseconds, but it was not synchronised to the real-world events (stimulus and response) properly, so was inaccurate.
It is possible to attain accuracies of +/- one millsecond, using Arcom's PCIB40 interface card. Indeed, it was possible to perform millisecond timing on PCs using only the computer hardware, by reprogramming the Programmable Interrupt Controller chip on the motherboard. This may still be possible on the newer motherboards, assuming the interrupt architecture is the same. There are a few technical articles on acheiving this, but the coding tends to be at a very low and obscure level, making it rather unintelligible, and requiring technical information which is difficult to obtain.
Stimulii events are usually the onset of some visual or auditory signal, generated by the computer.
The VDU monitor is normally used for visual stimulii, but this has inherent drawbacks due to its stroboscopic nature. The screen is re-drawn between 50 and 100 times a second depending on the quality of the monitor (high-quality monitors are faster). The screen is drawn by an electron beam as a series of horizontal lines. The electron beam draws each line from left to right (as the viewer looks at the screen) and draws each consecutive line below the previous line. Thus, the screen is generated from top left to bottom right. Upon reaching the bottom of the screen, the electron beam returns to the top left, and repeats the process. The electron beam is switched off during its return to the top-left corner so nothing is drawn during this period. To allow synchronisation of screen processes, the monitor generates a vertical sync. pulse which is active for a short period when the electron beam is at the top left of the screen, just before starting to draw the next screen. Each drawing of the screen is known as a screen refresh.
Given the stroboscopic nature of a monitor, when the software draws the image to the video RAM, it is difficult to know how long it will be before it actually appears on the screen. This is because, unless we lock the source code to the monitor's vertical sync pulse, we can't guarantee the position of the electron beam when the image drawing routine is being processed. For instance, if the image is drawn to video RAM just before the electron beam has reached the position of the image, the latency will be very small - the image will apear alomst immediately. However, if the electron beam has just passed spot on the screen here the image is to appear when the software writes the image to video RAM, then the delay will be maximal, as the electron beam will have to complete the remainder of the current screen, and the first part of the next screen before it reaches the location of the image to be drawn.
Clearly, it is necessary to time the subjects response starting from when the subject first sees the image. Normally, the software draws the image in one step, then in the very next step starts the timer. However, given the limitations described above, it cannot be guaranteed that the image will appear at the same time the software draws it. In this case, the timer will never start late, but it will always start early, by an amount which we need to predict in order to rmove the error.
It is possible to control the delay between the drawing and the appearance of the image, using the vertical sync pulse signal from the monitor. The software can poll (monitor by taking repeated readings) this signal from the video card. It indicates that the electron beam has returned to the top-left corner of the screen and is starting to draw the next screen. If the software drawing process is synchronised with the electron beam, by waiting for the next sync pulse before drawing an image, the delay will be predictable, and will be multiples of the screen refresh rate. Given a simple-enough image, and/or a fast-enough computer, the image will be drawn to the video RAM before the electron beam has reached its position. This rule can become unreliable if the iamge is to be drawn at the tope of the screen, as the electron beam reaches this area immediately after the sync pulse.
The usual procedure is to wait for a screen sync pulse (which is read from a port value), then call the drawing routine. The code would look something like this:
WaitForSyncPulse() DrawImage() StartTimer()
One can reasonably assume that the drawing routine will complete before the screen's electron beam reaches the image, assuming it is far enough away from the top-left corner. In this case, even if the image has not physically appeared when the timer is started, at least it is synchronised.
The worst-case scenario would be for the image to be drawn to RAM whilst the electron beam is mid-way through the position of the image. This means that half of the image would be presented during the first refresh, followed by a complete image on the next refresh. In this case, the subject will be disadvantaged because for the first split-second the subject is presented with an incomplete stimulus.
On a non-multitaking computer, such as MS-DOS, the three processes mentioned above would occur immediately after one another (in an ideal world, the timer-start, image-drawing, and image-appearance would all be simultaneous). However, on a pre-emptive multi-tasking OS such as Windows, it is not possible to know or control what the computer does between (or even during) the three processes.
The subject-response event is typically the press or release of a button, or the onset of a sound (the subject says something). They form the input to the computer. For buttons, we normally use proprietary hardware (rather than the keyboard) for robustness' sake, or for when a special button arrangement is required. For audio responses, we use audio-activated switches giving logic outputs.
In this case, we have a similar problem in that we need to ensure that the timer is stopped immediately after a button is pressed. However, at least in the case of responses, we don't have to deal with any latencies between the physical onset of a response, and its associated electrical signal to the computer.
In the past, we have stopped the timer, using one of two methods. Where possible, we hard-wired the response buttons to the timer, so that they stopped it immediately (there is a latency due to the electronic switching effects, but these are less than microseconds, and can be ignored). In other cases, we polled the response channels and stopped the timer, as soon as a response was detected, using the software. With this technique, it is important to ensure that the response channels are being polled often enough to avoid latencies. Obviously, for millisecond accuracy, it is necessary to poll them at least once per millisecond.
|Home||About Me||Copyright © Neil Carter|
Content last updated: 2000-04-06