Hi,
I am programming a simple experiment, showing letter strings with a fixed duration of 1000ms and interstimulus fixation crosses with variable durations (using a trial variable ISI durations). However, each stimulus takes 9 to 11 ms longer than the specified time, which wouldn’t be so bad if the error were not cumulative. In this case, it leads to 2 seconds extra on 100 trials.
I know this may have to do with the monitor refresh rate, but the error occurs whether I set this to 60 or 75 Hz. I have also tried expanding the trials (the presented words use stimulus lists) and setting the trial time manually (because it is different for each trial - a trial being word presentation and fixation cross), making sure the time of the individual events is shorter than the trial time. This, however, still yields the same error, although aproximately cut in half, of course. Even if this were to solve the problem though (which it doesn’t), this is of course very time consuming and labor intensive, so it’s definitely not what I want.
So, here’s my questions:
Is there no way around the strict dependence on the monitor refresh rate (which I assume is the cause of the error)?
Is there a way to at least not make the error cumulative?
Why is it not possible to use presentation time lists for trials, just like for events?
If no other solution works, I guess I have to recalculate my presentation times into intervals that fit the monitor refresh rate, but this certainly does not seem to be the ideal solution, if only because I may wish to present the experiment on different machines …
Since SuperLab synchronizes with the refresh rate of the screen, durations on the screen are always rounded up to the next multiple of the refresh cycle. In addition, there are delays due to the experiment’s own overhead, e.g. loading stimuli files, allocation memory, freeing it, saving data, etc.
What is the range of variable durations for the fixation crosses? do your trials have have a fixed overall duration?
thanks - my fixation cross times (with the ISI durations list) vary between 1900 and 7100 ms… The added time error is between 9 and 11 ms per event (also for the presented word stimuli, which should all be 1000ms).
My trial times are not fixed, but as a check I did program one run with fixed trial times, each trial consisting of a stimulus (1000ms) and a fixation cross (set to 100 ms). In that case the error was 9-11 ms per trial, and also cumulative, so that the error after 100 trials was 1 second.
I have also tried taking of 16 ms of each event time (my refresh rate is 60Hz). That leads to each event being between 5 and 7 ms. fast (so, should I perhaps take of 17 ms, instead?), and my experiment after 100 trials (=200 events) being 1 second fast.
I guess I can combine fixing the trial times with taking 16 ms. off each trial. I expect this would then lead to my experiment only being about 500 ms. fast after 100 trials. Still, that seems like a lot of work for something that appears to be quite straightforward …
As I said, the error itself is very small (even 10 ms. is fine for this fMRI experiment) - the only problem is that is cumulative, so that even a small error leads to gross mistiming after multiple trials/events. Even the ‘fixed trial time’ solution leads to cumulative errors.
I just hope there’s a clever solution, that saves my from calculating different trial times if I decide to use a different monitor and that saves me from manually putting in the variable times for each trial …
In MRI experiments, total trial durations are usually fixed and correspond to the scanner’s TR. Is your trial duration fixed overall despite the fact that the fixation crosses have variable durations? If it is not fixed, are you using a variable scanner TR?
I’m not sure what solution I can offer if your overall trial durations are not fixed. I was going to suggest synchronizing with the scanner but it doesn’t look like an available option.