+xHello,
I was wondering what would you recommend to improve the timing in an experiment where images are presented. There are software that allows for instance to preload the image or to reduce the screen resolution to improve the timing.
I am particularly interested in the delays between the trigger sent to an EEG system, in correspondence of a picture and appearance of the picture itself on the screen (as detected by a light sensor attached on the screen).
Currently I am presenting the stimuli with stimulusframes (that if I understood correctly provide a better timing than the
stimulustime attribute?) but when I analyse the delays I have sometimes a variability of up to 14ms (with an average delay of 3ms).
Thank you for any help you will be able to provide,
Elena
Inquisit puts all images into RAM when parsing the script at the start. You can define a /pretrialpause to give each trial a predictable amount of time to prepare the stimuli to be presented during that instance of the trial. There is no timing difference between /stimulusframes and /stimulustimes per se, ultimately they map to the same thing: Display work in fixed refresh cycles ("frames"), the duration of which depend on your display's refresh rate. I.e. with display running at 100Hz, you get a refresh cycle / frame duration of 10ms. For any stimuli to be displayed, Inquisit has to wait for the start of the next available refresh cycle / frame.
With /stimulusframes you specify the ordinal frame number you want a given stimulus displayed in during a given trial. With /stimulustimes, you specify the point in time (in ms) you want a stimulus displayed during a trial -- Inquisit determines the frame that's closest to the specified time based on the display's refresh rate.
What Inquisit (and any other similar software) can control is when it instructs the hardware to do something (e.g. display a stimulus); it has no direct control over when the hardware actually executes the task it's been given. For example, different displays come with different response times (time until a pixel fully lights up) and other hardware features can introduce delays and some amount of variability. (see e.g.
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0044048 and
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0012792 regarding how messy display timing actually gets when you really take a hard look at it).
As for the delays you describe, those on the order of only a few milliseconds (you report an average of 3ms) are most likely simply due to the fact that the parellel port / EEG has a shorter response time than the display you are using. For anything more, I'd have to see some actual code and data.