Problem with stimulusonset when setting beginresponsetime

Back

Home
»
Millisecond Forums
»
Inquisit 4
»
Problem with stimulusonset when setting beginresponsetime

Problem with stimulusonset when setting beginresponsetime

Author	Message
Kolfers	Kolfers posted 9 Years Ago Topic Details Share Topic
Group: Forum Members Posts: 24, Visits: 137	Hi all, I'm struggling with resolving some timing issues I've encountered. Basically: I'm presenting a stimulus (stimA) at t = 0 ms, and then erasing that stimulus with another blank stimulus (stimB) at t = 500ms (this interval needs to be tight), the trial then continues for another 1000 ms. Now, I want to start logging responses from the start, so I use the / beginresponsetime = 0. However, if I do this, the stimB.stimulusonset varies as from 507 ms up to as high as 690 ms, which is unacceptable for this experiment. If I set the / beginresponsetime = 500+ ms, stimB.stimulusonset is always a tight 500 ms. The original trial: <trial lettertask_notarget> / skip = [values.run_exit \|\| values.run_redoblock ] / pretrialpause = 250 / stimulustimes = [0 = stimA; 500 = stimB] / timeout = 1750 / beginresponsetime = 0 / isvalidresponse = [if(values.resp == 0 && trial.lettertask_notarget.response != 0) {values.resp = trial.lettertask_notarget.response}; values.resp == 999] / responseinterrupt = immediate </trial> I tried to see what was causing the problem: - removing /isvalidresponse expression --> same problem - giving no response at all --> same problem - different computer --> same problem (running on Windows 8.1, core i7 haswell, 16gb ram) Is there that much overhead from checking for a response (even in the absence of a response) that subsequent stimuli get delayed as much as 190 ms? And if so, is there any way to increase the timing precision? P.S. I've though about the possibility of splitting the trial up in two parts (present stimA & present stimB), but I think the problem would be the same. - Either in the second trial I'd have to log responses before the stimB onset, which would introduce the exact same problem - Or I'd have to let the first trial run for 500ms and then start the second trial, but the overhead from loading the stimuli would introduce unknown variability between the trials, and using a posst / pretrialpause would mean participants wouldn't be able to respond for that interval. Tags beginresponsetime stimulusonset
	Reply Like 91
Dave	Dave posted 9 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	I sincerely doubt that the /beginresponsetime setting has anything to do with it. Also, I am unable to reproduce the issue. Attached is a data file generated with the following code (analogous to your <trial> definition). No responses were given, you can see that stimulusonset2 is always at exactly 500ms. <block myblock> / trials = [1-10=lettertask_notarget] </block> <trial lettertask_notarget> / pretrialpause = 250 / stimulustimes = [0 = stimA; 500 = stimB] / timeout = 1750 / beginresponsetime = 0 / validresponse = (0,57) / responseinterrupt = immediate </trial> <text stimA> / items = ("A") </text> <text stimB> / items = (" ") </text> <data> / separatefiles = true </data> So, how exactly do you determine the respective onsets? What's worth pointing out is that with / responseinterrupt = immediate stimB will not be displayed by the given trial if the response occurs prior to 500ms. In those cases there cannot be any onset for stimB. Also, the trial does not necessarily continue another 1000ms after stimB. /timeout defines the trial's maximum duration, if a response occurs prior to the timeout, the trial terminates immediately and the next trial starts. Attachments experiment_1_2015-03-02-15-19-39-365.iqdat (842 views, 1.00 KB) Edited 9 Years Ago by Dave
	Reply Like 91
Kolfers	Kolfers posted 9 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 24, Visits: 137	Hi Dave, Thanks for the quick response! So, how exactly do you determine the respective onsets? I have a custom datafile specified with stimB.stimulusonset stimB will not be displayed by the given trial if the response occurs prior to 500ms. In those cases there cannot be any onset for stimB. Also, the trial does not necessarily continue another 1000ms after stimB. /timeout defines the trial's maximum duration, if a response occurs prior to the timeout, the trial terminates immediately and the next trial starts. I should have explained a little more. In principle I want the trial to continue regardless of response, except if the exit key is pressed (working with elderly people). As you can see in my example, the / isvalidresponse will not evaluate to true unless the exit key is pressed, but it will nonetheless register the first response given. In that sense, the trial always lasts for the entire timeout (unless the exit key is pressed). I worked out the example a bit more below, and found the culprit. It turns out the weird timings only appear when I use the monkeymode... (please see attached file "data(1).iqdat"). I guess it doesn't play nice with my trial set up? I tried whether specifying the monkeyresponses changes anything but it didn't. In any case, it looks like for regular mode the timings are in order, so the monkey gave me a scare for nothing. (Still, changing the beginresponsetime to 500+ also results in normal monkeymode timings) <values> / resp_key = 0 / resp_exit = 999 </values> <block myblock> / trials = [1-20=lettertask_notarget] </block> <monkey> / latencydistribution = uniform (100,600) </monkey> <trial lettertask_notarget> / ontrialbegin = [values.resp_key = 0] / pretrialpause = 250 / stimulustimes = [0 = stimA; 500 = stimB] / timeout = 1750 / beginresponsetime = 0 / isvalidresponse = [if(values.resp_key == 0 && trial.lettertask_notarget.response != 0) {values.resp_key = trial.lettertask_notarget.response}; values.resp_key == values.resp_exit; ] / responseinterrupt = immediate </trial> <text stimA> / items = ("A") </text> <text stimB> / items = (" ") </text> <data> / separatefiles = true </data> - See more at: http://www.millisecond.com/forums/Topic15641.aspx#sthash.jjrZ2DQe.dpuf Attachments data.iqdat (871 views, 1.00 KB) data (1).iqdat (923 views, 1.00 KB)
	Reply Like 88