| Reference | Downloads | Github

PST Box Refresh Detector, Dropped Frames

Hello! I am trying to write a program for the PST Response Box Refresh Detector which would flash the screen between black and white and compare the coded timings of flashes and the refresh detector responses. My lab is planning to run ERP experiments and the timing needs to be as accurate as possible.

I am having troubles with dropped frames, so I am wondering if it is due to my system or my code. I tried to change the graphics card’s (ATI FirePro V4800) settings and it performs differently on the timeByFrames test with the Waiting for Vertical Refresh setting off and on. It does not make any difference for the dropped frames issue though. I have an Intel Xeon 3.07 GHz CPU.

So, how do I prevent the system from dropping frames?

I am attaching the sysInfo test results, the timeByFrames test results, my code and the sample of the output for my code.

Thank you. (1.3 KB) (4.0 KB) (1.3 KB)

Waiting for Vertical Refresh OFF:

Waiting for Vertical Refresh ON:

None of these are actually dropped frames. It’s weird that the timing is reporting being out by +/-4ms on roughly alternate frames, but if it were dropped frames then the times would jump to 33ms and <5ms for the refresh.

Hello Jon, thanks for the reply.

So, what do I do about it? How can I make sure that the stimulus timing is matching its representation on the screen?

We’ll if you time your stimulus by a certain number of frames then it is going to be correct. The physical updates of the screen are not variable like this. Just for some reason on your machine the time being reported back afterwards is (sometimes) variable. I can’t honestly say why - there are too many variables from one computer to another (all possible hardware, driver and software configurations) for me to work out why some machines have bad timing. Sorry I can’t help more. But, as I say, in terms of actual stimulus presentation this isn’t particularly alarming.

1 Like