By James Rounds - 6/17/2025
Hello all!
I am writing to ask about a discrepancy we're noticing in our Inquisit data files, specifically between the "elapsedtime" field and the "trialduration" fields. These data were collected with Inquisit Lab 6.5.1, in a script that presents
Our trials look like this (full script attached):
<trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>
The trialduration field in our data files matches exactly what we specified in the trial element itself in the script. For our final few subjects, we also had Inquisit save an audit/log file, which perfectly matches our expected trialduration fields, except in rare situations where a participant didn't respond (in which case there was a 26-27 ms delay in the onset of the next trial).
However, the elapsedtime field in our data files sometimes seem to diverge by tens or hundreds of milliseconds from the trial duration.
The reason we're double-checking this carefully is because these data were collected in an fMRI experiment, and we're using the Inquisit data to create event-timing files for analyzing the fMRI data.
What exactly is the elapsedtime field measuring? We can provide more example data to illustrate this point if it's helpful. Thank you!
|
By Dave - 6/17/2025
+xHello all! I am writing to ask about a discrepancy we're noticing in our Inquisit data files, specifically between the "elapsedtime" field and the "trialduration" fields. These data were collected with Inquisit Lab 6.5.1, in a script that presents Our trials look like this (full script attached): <trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>
The trialduration field in our data files matches exactly what we specified in the trial element itself in the script. For our final few subjects, we also had Inquisit save an audit/log file, which perfectly matches our expected trialduration fields, except in rare situations where a participant didn't respond (in which case there was a 26-27 ms delay in the onset of the next trial).
However, the elapsedtime field in our data files sometimes seem to diverge by tens or hundreds of milliseconds from the trial duration.
The reason we're double-checking this carefully is because these data were collected in an fMRI experiment, and we're using the Inquisit data to create event-timing files for analyzing the fMRI data.
What exactly is the elapsedtime field measuring? We can provide more example data to illustrate this point if it's helpful. Thank you!
elapsedtime in your script is time in milliseconds since the start of *script* execution as it stood when the respective row of data was logged. Data is generally logged when the given trial has collected its response, i.e. elapsedtime at this point does not reflect trial duration. Everything else that happens outside of trial elements also goes into the overall elapsedtime, e.g. time it takes to initialize the <expt> object, <block> objects, time spent on instruction pages, etc.
|
By James Rounds - 6/17/2025
+x+xHello all! I am writing to ask about a discrepancy we're noticing in our Inquisit data files, specifically between the "elapsedtime" field and the "trialduration" fields. These data were collected with Inquisit Lab 6.5.1, in a script that presents Our trials look like this (full script attached): <trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>
The trialduration field in our data files matches exactly what we specified in the trial element itself in the script. For our final few subjects, we also had Inquisit save an audit/log file, which perfectly matches our expected trialduration fields, except in rare situations where a participant didn't respond (in which case there was a 26-27 ms delay in the onset of the next trial).
However, the elapsedtime field in our data files sometimes seem to diverge by tens or hundreds of milliseconds from the trial duration.
The reason we're double-checking this carefully is because these data were collected in an fMRI experiment, and we're using the Inquisit data to create event-timing files for analyzing the fMRI data.
What exactly is the elapsedtime field measuring? We can provide more example data to illustrate this point if it's helpful. Thank you! elapsedtime in your script is time in milliseconds since the start of *script* execution as it stood when the respective row of data was logged. Data is generally logged when the given trial has collected its response, i.e. elapsedtime at this point does not reflect trial duration. Everything else that happens outside of trial elements also goes into the overall elapsedtime, e.g. time it takes to initialize the <expt> object, <block> objects, time spent on instruction pages, etc.
Amazing, thank you Dave. We're still confused though about why the elapsedtime field doesn't match the expected trial durations on a trial-by-trial basis. I've uploaded a sample of our data, in an Excel file that contains four rows of trial data from the .iqdat file in one tab, and in the second tab, the corresponding trial data as it was logged in the audit file.
I had Inquisit save the elapsedtime field for several elements, not knowing exactly how it would behave. But I realized afterwards they are largely redundant with each other. But the important question is why does it seem that the elapsedtime field doesn't match the expected duration of each trial. It's not off by just a few milliseconds, it seems to be just totally unrelated to the actual trial duration.
Also, we are wondering about the log/audit files - they seem to include what I'll call "administrative" events, such as indicating that the "block" is starting, a few milliseconds before the trial starts. Do these discrepancies/delays get accounted for by Inquisit, so that it can still successfully space the trials exactly as far apart as they are supposed to be?
Since we're collecting this data for an fMRI study, we do need to know exactly what participants are seeing at each moment. We trust the log files because they match the trialdurations so closely. But we just want to make sure we know when each event truly starts.
For example, on the first trial in our log file, our fixation cross shows up 34 ms after the trial starts (presumably, two refresh cycles on our 60 Hz monitor). The fixation cross is supposed to be the very first thing that happens on a trial. If it starts 34 ms after the trial starts, and everything else in the trial occurs at precisely the time we expect to, based on the log events, with respect to the trial beginning, how is the next trial starting precisely when we expect it to?
Can you confirm that the stimulus onset is the number next to each event in the iqdat file? If so, that just means our ITIs are slightly different than we expected, I guess, because the lost milliseconds must be coming from somewhere, right?
Thank you so much! - James
|
By Dave - 6/17/2025
+x+x+xHello all! I am writing to ask about a discrepancy we're noticing in our Inquisit data files, specifically between the "elapsedtime" field and the "trialduration" fields. These data were collected with Inquisit Lab 6.5.1, in a script that presents Our trials look like this (full script attached): <trial POSO_posBG_shrt_ITI_6pt4>
/ validresponse = ("1", "4")
/ correctresponse = ("4")
/ stimulustimes = [0 = fixation; 800=noreplace (POSO);
1000 = blanks;
1100 = poso_goodtarget;
1600 = blanks]
/ trialdata = [POSO poso_goodtarget]
/ beginresponsetime = 1100
/ trialduration = 8000
/ responseinterrupt=frames
</trial>
The trialduration field in our data files matches exactly what we specified in the trial element itself in the script. For our final few subjects, we also had Inquisit save an audit/log file, which perfectly matches our expected trialduration fields, except in rare situations where a participant didn't respond (in which case there was a 26-27 ms delay in the onset of the next trial).
However, the elapsedtime field in our data files sometimes seem to diverge by tens or hundreds of milliseconds from the trial duration.
The reason we're double-checking this carefully is because these data were collected in an fMRI experiment, and we're using the Inquisit data to create event-timing files for analyzing the fMRI data.
What exactly is the elapsedtime field measuring? We can provide more example data to illustrate this point if it's helpful. Thank you! elapsedtime in your script is time in milliseconds since the start of *script* execution as it stood when the respective row of data was logged. Data is generally logged when the given trial has collected its response, i.e. elapsedtime at this point does not reflect trial duration. Everything else that happens outside of trial elements also goes into the overall elapsedtime, e.g. time it takes to initialize the <expt> object, <block> objects, time spent on instruction pages, etc. Amazing, thank you Dave. We're still confused though about why the elapsedtime field doesn't match the expected trial durations on a trial-by-trial basis. I've uploaded a sample of our data, in an Excel file that contains four rows of trial data from the .iqdat file in one tab, and in the second tab, the corresponding trial data as it was logged in the audit file. I had Inquisit save the elapsedtime field for several elements, not knowing exactly how it would behave. But I realized afterwards they are largely redundant with each other. But the important question is why does it seem that the elapsedtime field doesn't match the expected duration of each trial. It's not off by just a few milliseconds, it seems to be just totally unrelated to the actual trial duration. Also, we are wondering about the log/audit files - they seem to include what I'll call "administrative" events, such as indicating that the "block" is starting, a few milliseconds before the trial starts. Do these discrepancies/delays get accounted for by Inquisit, so that it can still successfully space the trials exactly as far apart as they are supposed to be? Since we're collecting this data for an fMRI study, we do need to know exactly what participants are seeing at each moment. We trust the log files because they match the trialdurations so closely. But we just want to make sure we know when each event truly starts. For example, on the first trial in our log file, our fixation cross shows up 34 ms after the trial starts (presumably, two refresh cycles on our 60 Hz monitor). The fixation cross is supposed to be the very first thing that happens on a trial. If it starts 34 ms after the trial starts, and everything else in the trial occurs at precisely the time we expect to, based on the log events, with respect to the trial beginning, how is the next trial starting precisely when we expect it to? Can you confirm that the stimulus onset is the number next to each event in the iqdat file? If so, that just means our ITIs are slightly different than we expected, I guess, because the lost milliseconds must be coming from somewhere, right? Thank you so much! - James
I already explained why elapsedtime does not, and is not supposed to, reflect trial duration. It's milliseconds elapsed since script execution (or since block execution, if you were to log a block's elapsedtime property). A data row is logged when the trial has its response, generally speaking. In most cases that will occur before the trial reaches the fixed duration you specified.
The audit logs record the time -- also in milliseconds elapsed since start of execution -- when any number of events occur. Initialization of a block, initialization of a trial, display of stimulus within that trial, and so forth.
The simulusonset columns are the stimulus onsets in milliseconds relative to the start of the trial's stimulus presentation sequence. The start of a trial object is not equal to the start of its stimulus presentation sequence. The trial object has to be initialized, it needs to load things into memory, it needs to execute /ontrialbegin logic if there is any, and -- importantly -- it needs to wait for the start of a display refresh cycle before it can begin drawing anything to the screen.
The first time a given trial object is run will always have slightly worse timing / greater delay. Once a given trial object is in memory, subsequent instances of that trial object will have less delay.
As I pointed out in your other thread, if you are serious about minimizing timing variations, you should make ample use of pre- and posttrialpauses.
|
|