I have been attempting to get the timing right on a paradigm that I hope to use for fMRI - and hence the timing needs to be accurate. I understand that when presenting images the screen refresh rate comes into play, and have checked out other threads about timing problems. The refresh rate on the laptop I’m using is 60 Hz; I followed the formula of allowing 16.7ms for the 1st refresh (to draw the buffer to the screen) / n refreshes to the time limit / and 1 more refresh to erase the stimulus. I adjusted the “end” times accordingly for each event.
Unfortunately, the fun run of the experiment is still +10 seconds out, which is too much for fMRI. Do you have any other suggestions as to the best way to calculate the “end” time for each event so that it will run on time?
I’m having difficulty finding the thread you’ve referenced, but I remember writing the explanation. We’ve always maintained that the best way to synchronize with an fMRI (or similar) machine is using the Trial Synchronization feature, which is done using the “End” tab in the Trial Editor. Here, you specify the desired length of the trial in milliseconds. You must make sure that the cumulative time taken within the Trial is less than this amount of time, as this feature will not end a trial currently in progress. Therefore, if you don’t need participant response, set the length of the event to 1ms (this ensures it still shows up in your data file).
There is processing that occurs between every trial, so if you are using the sync-trial feature, this processing occurs in the idle time at the end of one trial, and then SuperLab waits immediately before presenting the first event of the next trial. There will be no accumulation of error if you use this approach.
Ok - I tried setting the End of the trial to 2500ms and the event length to 1ms - but this only showed the event picture for 1 ms, which is not going to work.
So I went back to the original shortened times based on the screen refresh rate [each trial = picture event (2000ms) plus fixation cross event (500ms)]. So the picture event was set to 1967ms and the fixation event to 467ms. And I ran the program.
What I got were error messages that “Superlab was unable to synchronize the presentation of trial “A1”(etc), probably because 2500 msec is too short. The previous trial, “N8”, took 2664 msec” - and many more of that nature.
I checked the log. The total time for the two events comprising each trial should be 2500 msec, but the event times totalled 2434 to account for the 60 Hz screen refresh rate. Unfortunately, the amount of time that the events over-ran was not consistent, and it didn’t seem to be related to the size of the picture file, for example. Trials were running between 2581 and 2669 msec rather than 2500.
Any suggestions for getting the timing right on this?
Thanks,
CJS
Here’s the important question: why did the picture go away when the event was set to be run for only 1ms? If you want your fixation cross visible for 500ms, it still needs to be set to 500ms. The last event in the trial should be set to 1ms instead of 2000ms. Unless you have that event configured to erase the screen or stimulus at the event’s end, the picture should stay on the screen.
There is more that goes into a trial than just the two events. The only way to see exactly where the extra 164ms went is to use the verbose log feature. Directions for how to enable this are included here for Windows and here for Mac OS X. This is a mostly human-readable log of everything that happens while SuperLab runs an experiment, but it’s definitively not user-friendly.