RSVP timing

Hi. I want to run a RSVP with pictrue stiumuli. The SOA is 100 ms, each stimulus is on for 20 ms and is followed by a blank/mask for 80 ms. I measured the actual display change using a photo cell. the timing worked well in Pro. The same timing setting, however, does not work in 4.02. Stimulus presentation duration was 20 ms, but the mask was presented about 120 ms instead of 80ms.

I used the same stimuli, video card, monitor etc., for the comparison. Do you have any idea what is causing the difference? And, how to let the program do what I want?


P.S. I also tested your new RSVP object option in 4.02. The results were the same. For a sequence of

A//B//C//D (stim + blank)
20, 80, 20, 80, 20, 80, 20, 80 (timing)

The actual display time was

20ms - approx. 120- 20ms - approx. 120- 20ms - approx. 120- 20ms - approx. 120

With 4.03, the presentation duration was

20 ms - approx. 100 ms - 20 ms - approx. 100 ms…

SuperLab 4.0.3 includes quite a few timing improvements, most of which are on the Mac, but a few of which are on Windows.

SuperLab Pro 2 on Windows did not synchronize with the monitor’s refresh rate. SuperLab Pro 1 on the Mac did synchronize in 256 colors. SuperLab 4 does synchronize with your monitor’s refresh. Therefore, it’s important to know what your refresh rate is on your monitor when picking the times you request of SuperLab.

Here’s a small list:

rate period
60Hz: 16.7ms
66Hz: 15.2ms
72Hz: 13.9ms
75Hz: 13.3ms
85Hz: 11.8ms
100Hz: 10.0ms
150Hz: 6.7ms
200Hz: 5.0ms

Not many of these refresh rates are conducive to a 20ms exposure. Specifically, 20ms is 1/50th of a second, so any refresh rate you pick should be a multiple of 50 (that is 100Hz, 150Hz, 200Hz, but please don’t pick 50Hz for the sake of the people sitting in front of the screen).

I just ran through this a few times on my own to double-check exactly what SuperLab does so I can tell you. The time limit that you are specifying is not the time that the stimulus is on the screen. This time is the amount of time that SuperLab stops and waits before moving on. In the case of RSVP, here’s what happens:

1st refresh - draw buffer to screen (stimulus)
n refreshes - take your time limit, round it up to the nearest refresh, and insert it here
1 more refresh - erase stimulus

Therefore, the amount of time it will take is the amount you specified rounded up to the nearest refresh plus two more refreshes–one to draw the stimulus, and one to erase the stimulus. The amount of time the stimulus would be on the screen would be your time rounded up plus one refresh. The amount of time you specify for your blank interval will depend on your refresh rate, but it should be definitely be a bit less than 80ms if you want your stimuli to appear every 100ms.

The information above I determined from a new obscure and undocumented 4.0.3 feature. SuperLab can now provide you with very detailed information about what happens when you run an experiment. This is still a work-in-progress, but the basics are available now. If you launch SuperLab from a DOS prompt with the “–verbose” flag, you will get a report after you finish running your experiment. This is not intended for data collection, but rather as an experimenter’s debugging tool. Instead of launching from a DOS prompt, you can also create a shortcut and then add " --verbose" to the end of the Target name in the shortcut’s properties. My target looks like this:

“C:\Program Files\SuperLab 4.0\SuperLab.exe” --verbose

Many things were improved with SuperLab 4.0.3 with respect to timing; it may not look it on the surface, but it’s a pretty hefty improvement over 4.0.2.

Thanks for your reply. It was very helpful.

The extra refresh that erases a stimulus explains the 20 ms delay observed in our test using 4.03. Our display refresh rate is 100Hz. Time limits of 20ms and 80ms for the stimulus and mask implement a refresh sequence of:

stim-stim-ERASE-mask-mask-mask-mask-mask-mask-mask-mask-ERASE …

It gives an ISI of 100 ms, instead of 80 ms!

With some trials and errors, I found that time limits of 17 ms for stimulus and 57 ms for blank/mask gaves 2-3 refreshes per stimulus every 100 ms. The fluctuation in stimulus refresh may be due to the round up. Delays due to the round up occured (in our hardwares) 4 times in 100 repetition, whcih looks good for my experiment.

If you think of a better way to control the timing, please let me know. (Is it better to use an ISI event?)

Thanks, again!

At a refresh rate of 100Hz, I would expect 11ms and 51ms to be most likely to give you two refreshes per stimulus every 100ms. SuperLab waits for the vertical blanking period before flushing its offscreen buffer to the screen, and in 4.0.3, the “onset” of the stimulus is set to be when that VBLANK occurs. The 11ms delay is relative to that stimulus onset time. A refresh rate of 100Hz means that the VBLANK period occurs every 10ms. Setting the delay to 11ms means that the following will occur:

draw stimulus to offscreen buffer
wait for VBLANK…
flush stimulus to screen
wait 1 ms { 1 = 11 (mod 10) }
erase the offscreen buffer
wait for VBLANK…
flush blank buffer to screen…

It’s important on Windows that you have as little as possible running in the background while you run your experiment. CPU features like hyperthreading and multiple cores are very helpful here–anything that allows SuperLab to dominate a core on Windows is going to help your timing. This is far, far less of an issue on OS X, but neither platform is perfect.

Well. I though that 11 - 20 ms time limits for a stimulus and 51-60 ms for a mask would give the same results. But actual display refresh sequence was different.

For 11ms-stim and 51ms-mask combination, average ISI was LESS than 80ms.
For 20ms and 60ms, it was more than 80 ms.
As I’ve reported, for 17ms -57 ms, it was about 80 ms.

I also tried to minimize the numer of processes running on the CPU.