Millisecond Forums

Hi,

I understand from Inquisit documentation that specifying 'stimulusonset' in the columns attribute of the data element will write the "actual" stimulus presentation time for each trial, in milliseconds.  I have used 'stimulusonset' and I am familiar with how its output appears, but I have two questions about it:

1.  How does Inquisit determine the "actual" presentation time?  I imagine that it somehow extracts this information from the DirectX controller, but I really have no idea.  I do trust the developers' claim that 'stimulusonset' tells me the actual onset time, but I would feel much better if I knew how this was computed and how reliable it is so that I could justify it to colleagues.

2.  When I specify the beginning of the allowed response window to occur before all stimuli are presented (using the responsetime attribute), Inquisit will not output stimulusonset values for stimuli that are presented after the beginning of the response window.  For example:

<trial straightGS>
/ validresponse = ("a", "l")
/ correctresponse = ("l")
/ stimulustimes = [0 = fixation; 1000 = noreplace(ASM); 1060 = mask; 1100 = blank]
/ responsetime = 1000
/ trialdata = [ASM]
</trial>

This design results in all 0's being recorded when I specify stimulusonset four times in the columns attribute of the data element.  When I remove the responsetime attribute from the trial element, but do not change anything else, then stimulusonset is recoreded correctly for each of the four items.  In another example:

<trial straightGS>

/ validresponse = ("a", "l")

/ correctresponse = ("l")

/ stimulustimes = [0 = fixation; 1000 = noreplace(ASM); 1060 = mask; 1100 = blank]

/ responsetime = 1060

/ trialdata = [ASM]

</trial>

This results in correct recording of the stimulusonset of 'fixation' and 'ASM', but 0's are recorded for 'mask' and 'blank' when I specify stimulusonset four
times in the columns attribute of the data element.  As in the first example, when I remove the
responsetime attribute from the trial element, but do not change
anything else, then stimulusonset is recoreded correctly for each of
the four items.

The problem is that I would like to allow responses to be entered before the conclusion of stimulus presentation and I would like to record stimulusonset.  Is there some work-around here?

Many thanks for everyone's help.

Hello,

The stimulusonset data column is actually pretty simple - immediately after the function call is made that presents the stimulus, Inquisit checks the time according to the CPU and subtracts the CPU time that the trial started.

Note that the onset of the physical stimulus may differ from this reported onset. For example, a visual stimulus may not appear until a few milliseconds later when the screen repaints. And videos operate asynchronously on a separate thread, so there may be a lag after Inquisit calls the "play" function.

The purpose of these are to insure that stimulusonsets are as expected from a software standpoint. This allows you to detect, for example, if the computer hiccuped during a stimulus presentation causing some to be presented later than they should be. Or you could detect lags caused by presenting two many high resolution pictures simultaneously on a computer with a weak graphics system.

2. Are you using 3.0.2.0 or later? It appears you've hit a bug - I'll investigate and see if I can find a fix or a workaround.

-Sean

Hi, Sean

Thanks for your reply.

Is there any way for me to audit physical presentation time? If not, can this be estimated manually somehow? I'm worried that if I'm using the Web version of Inquisit and participants use their laptop computers (or any other computer with an LCD display), my stimuli may not reliably appear for 40, 50, or 60ms as specified. Assuming that all LCDs refresh at 60 Hz, just for simplicity, is there any way to estimate when physical stimulus onset occurs based upon the CPU time generated by stimulusonset? Or, more generally, I guess I am wondering if there is there a typical lag time between CPU time and the next refresh of the display. I realize that this would depend upon display refresh rate, graphics card, and other factors -- but if a practical upper limit were, say, 2ms, then I wouldn't worry; if the practical upper limit of lag time were closer to 8ms, then I would have some thinking to do. (For reference, the pictures that I am using are grayscale faces in *.bmp format, ranging in size from 60 to 130kb per image, and are presented one at a time.)

Also, I encounter the bug in Web version 3.0.2.0 and desktop version 3.0.1.1.

Thank you for your continued support.
-Josh

Josh,

To monitor the physical onset of the stimuli, you'd need a photosensor that is rigged up to a timer that is synchronized with Inquisit. If you are an electrical engineer, you could build this yourself as it's not super complicated. If not, then you might look into purchasing Blackbox Toolkit, which has preconfigured photosensors among other things. However, if you are conducting research over the web on participants' home and office computers, that's not going to be very helpful.

With tachistoscopic presentations, there are two things to look out for - a given stimulus is presented too early or too late. The way Inquisit is designed, it would be very rare for stimuli to show up too early, and if this happened, it would likely be due to a messed up video driver that doesn't properly signal vertical retrace status. (Even then, Inquisit would likely detect the problem and simply throw an error.)

Stimuli can show up late if the time required to load them into video memory exceeds the duration of a retrace interval. With modern video cards and CPUs, this should also be quite rare unless you are presenting very very long sequences of high resolution images on an older machine.

You can detect either case via the stimulusonset parameter. Each stimulusonset should be on the border of  a retrace interval, plus or minus 2 milliseconds or so. For example, if you are presenting a stimulus at the 3rd retrace on a 60hz monitor, the stimulus onset should be around 50ms. That marks the time point that the stimulus is completely loaded into display memory, so it will appear on the monitor on the next refresh cycle. The 2 ms fudge factor is because the vertical blank interval itself (the period after a refresh is complete and before the next one begins) takes some time. Also, since memory is drawn top to bottom, the fudge factor for stimuli on the bottom of the screen is actually a little greater.

LCD monitors do introduce pixel latencies into the mix. On most LCDs, it takes a given pixel anywhere from 4 to 20 ms to fully light up once the graphics card has instructed it to do so. The latency will also vary depending on the color, with high contrast (e.g., black to white) transitions being the fastest. LCDs are getting faster, though, and companies are coming up with new technologies to speed up the pixels. This is primarily being driven by the gaming and movies.

P.S. Just for the record, there is no performance penalty for using different pictures formats (jpg, bmp, gif, etc) in Inquisit. Inquisit loads and translates all pictures at the beginning of the experiment into a native Windows format, so once they've been loaded, they are all the same format. I thought it was worth pointing this out, because I know that's not how some other experimentation packages work.

-Sean