|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+xHello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+xHello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames.
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port>
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration.
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Dave, Thanks again. The following are my results and some observations/ponderings. I added /erase = false to both markers (onset and offset) and then ran through the first training trail 3 times (2nd ~ 4th below). The following are time duration results for each of the ten stimuli in the trial. The first set is data from prior to adding the erase = false statements Stimuli# 1st Trial 2nd Trial 3rd Trial 4th Trial Pre none none 50.29. none 1st 767.8. 635.51 788,12. 803.25 2nd 717.52 767.27 666.55 787.23 3rd. 783.5 799.63 539.15 783.57 4th 783.36 783.85 383.73 784.34 5th 783.14 783.86 788.2 767.41 6th 783.06 783.35 776.57 800.04 7th 773.81 783.56 707.7 783.32 8th 618.07 783.24 783.85 782.87 9th 782.78 783.03 449.81 785.7 10th 719.33 783.67 nothing? 568.78 Whew! That was a bit painful to format. A few observations: 1. It seems every other trial run through resutls in a short duration of marker 1 at the beginning. I'll run some more and see what I end up with...have to step away for a bit now. 2. For the trial labeled #2 above, I made a conscious effort from stimuls 3 or 4 to not respond until after the short audio file had completed. Initially I thought maybe this was the reason for the consistency that appears in the 2nd trial from stimulus 4 on but that appears to be unrelated. I did the same thing for the 3rd and 4th trials but didn't get the same results. 3. I am using the Tobii tracker on a MacBook Pro connected via Ethernet (via a USB-C dedicated adapter for ethernet). The computer is connected to a LAN network via a highspeed USB-C adapter...wondering if I would get different results if I disconnect everything except for the eyetracker... Gotta run for now for a bit but will come back and post more later. Regards Jason
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles)
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x[quote] stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) Dave, Thanks again. Regarding the stimulus onset times, the numbers I'm getting in the raw file are perfectly consistent.... -8, 391, 391, 391 all the way down (through all 10 stimuli). I'd tried adding pretrial pause = 100 and got the following, very promising, result (again, with everything off and disconnected): Stimuli Duration Samples 1 790.28 24 2 783.04 48 3 783.2 48 4 783.61 48 5 783.85 48 6 783.2 48 7 782.78 48 8 783.26 48 9 782.67 48 10 783.38 48 :-) It appears the pretrial pause setting really helped. I'm going to try extending it a bit, from 100, to see if that stabilizes the times for the 1st stimuli in the trial. Thanks so much for your help! Jason
|
|
|
|