Timing Accuracy


I’m having difficulty with the accuracy of the timing for an experiment. Some details –

I have v 2.0 installed on my lab computer, but was having considerable trouble with it in a number of domains. I was told, after emailing SuperLab support, that purchasing the newer version would likely fix these problems.

So, I am now using the downloaded demo version 4.0 in order to assess whether it is worth purchasing for us, but am still encountering problems. Specifically, my experiement is taking longer to run than it should.

My experiment consists of 8 blocks, each containing 56 fixation screens at 500ms, 56 ISIs (presented as a blank Bitmap file - 961 KB) at 2500ms, and 56 Bitmap files (2305 KB each) at 200ms. All in all, this should mean that each block adds up to 2m59s. However, when I run the paradigm, each block takes 3m26s.

My computer is a Dell with Intel Pentium 4, 1.99 GHz, 1.00 GB of RAM, running Windows XP Professional as its OS.

I hope this is enough information to garner some help. Timing is crucial to this experiment, and I was hoping you would have some insight as to why it is not accurate.

Many thanks for any help you can offer.

SuperLab 4.0 is more accurate than v2, which explains the extra time you’re getting. :slight_smile: I’ll explain.

SuperLab was designed to make the presentation of trials as fast as possible. In version 4.0, SuperLab explicitly synchronizes the presentation of a picture with the refresh rate of the monitor. It caches pictures better. It supports JPG which requires decompression, etc. I know you’re not using JPG, but it’s an example of the housekeeping tasks that SuperLab must do before the trial even starts.

Because of this, the presentation of events within a trial is more accurate and sometimes even faster, but the inter-trial delay is longer. Hence the longer total duration of the experiment that you’re witnessing.

If you want trials to be presented at precise periodic intervals, look at the End tab in the trial editor. It might be what you need.

Hi Hisham,

Thanks for your reply. I tried setting the paradigm up using the “End” option, and it did not make any difference. But, this should not matter if I understand your reply properly - so, the actual events are being presented accurately, for the amount of time I have dictated, but the entire trial is just taking longer? Where does that extra time (it breaks down to about 500 ms per trial) manifest itself - within the ISI?

That is, if each trial breaks down as such:

fixation 500 ms - stimulus 200 ms - ISI (blank screen) 2500 ms –

will the blank screen just be present for longer?

Sorry to harass, I just want to make sure I fully understand. If this extra time is not affecting the actual stimulus presentation, then I should be fine. Thanks again!


Using the Trial Synchronization feature is the correct way to go, but there’s one additional critical detail that is mentioned in the Trial Editor itself: the actual trial MUST be shorter than the time limit you’re entering. Therefore, to get your timing correct, you’ll want to shave a little bit off the last event in your trial (the ISI?) in order to get the trial lengths correct.

This is a very common question, and I realize there’s not an adequate explanation posted anywhere. I’ve written up a few personalized very detailed explanations over the past year or so, and I’ve posted these explanations inside Cedrus so that other people here could potentially learn what information is available in the verbose log. I’ve attached a PDF for you including two of these explanations. Names and actual experiments have been removed, but the explanations should be just as useful without this.

The information referenced is all available in the verbose log. A completely different example of the kind of information that can be extracted from the verbose log is available in this thread. Instructions to enable this functionality is separately available for Windows and Mac OS X.

How to Debug an Experiment with the Verbose Log.pdf (86.9 KB)

I’ve “stickied” this thread because this issue is very common, and I would like this solution to be easily found, as it’s a critical detail for experiments being used with MRI/fMRI (and until just now, these words weren’t even in this thread).

output of timing?

I’m sure that this is a silly question, but I can’t seem to find an answer. Is it possible to generate an output file of all the trial/event onset times in an experiment, with or without ss responses?

I saw your question in my email inbox and was about to send you a link to this thread, actually. That’s basically what the verbose log is, except that it doesn’t spit out a file, and it does a LOT more than that. Or was this not what you were looking for?

timing accuracy help

Hi all,
I found this thread which might be related to the issues we are also having with timing. If anyone could help clarify this, I would greatly appreciate it!!

Our basic setup: Present a series of stimuli, all of the same duration. Every now and then, participants enter a response while the stimulus presentation continues without stopping. According to our log file, there seems to be an additional time added to the overall duration of the trial. Is this a problem resulting from pressing the key? It seems that the added time also is not a constant, therefore, making it more difficult for me to troubleshoot.

Any help would be wonderful!!

thank you!!


It would be very helpful if you posted your experiment.