Eye tracker question (Tobii X2-60) - Stimulus Onset & Offset Markers


Eye tracker question (Tobii X2-60) - Stimulus Onset & Offset Markers

Author
Message
Musashi Jason
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
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=stimOffsetMarker

2. 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
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
Musashi Jason - Monday, January 28, 2019
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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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
Dave
Supreme Being
Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)

Group: Administrators
Posts: 9.3K, Visits: 41K
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019
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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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.
Attachments
TestExperiment.iqx (9 views, 14.00 KB)
Dave
Dave
Supreme Being
Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)

Group: Administrators
Posts: 9.3K, Visits: 41K
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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
Dave
Supreme Being
Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)

Group: Administrators
Posts: 9.3K, Visits: 41K
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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.

Edited
Last Month by Dave
Musashi Jason
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
Dave - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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                   48
Per 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                    48
Per 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                   48
Per pt ave              16.32ms            16.32ms

     7th                    784.54ms         783.32ms
Data Points                48                    48
Per pt ave              16.34ms            16.32ms

     8th                    783.47ms         783.68ms
Data Points                48                    48
Per 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                    48
Per 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
Dave
Supreme Being
Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)Supreme Being (568K reputation)

Group: Administrators
Posts: 9.3K, Visits: 41K
Musashi Jason - Wednesday, January 30, 2019
Dave - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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                   48
Per 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                    48
Per 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                   48
Per pt ave              16.32ms            16.32ms

     7th                    784.54ms         783.32ms
Data Points                48                    48
Per pt ave              16.34ms            16.32ms

     8th                    783.47ms         783.68ms
Data Points                48                    48
Per 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                    48
Per 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
Musashi Jason
Expert
Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)Expert (1.1K reputation)

Group: Forum Members
Posts: 53, Visits: 123
Dave - Wednesday, January 30, 2019
Musashi Jason - Wednesday, January 30, 2019
Dave - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
Musashi Jason - Monday, January 28, 2019

Dave - Wednesday, January 30, 2019
Musashi Jason - Wednesday, January 30, 2019
Dave - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Tuesday, January 29, 2019
Dave - Tuesday, January 29, 2019
Musashi Jason - Monday, January 28, 2019
[quote]
Musashi Jason - Monday, January 28, 2019

 

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=stimOffsetMarker

2. 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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                   48
Per 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                    48
Per 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                   48
Per pt ave              16.32ms            16.32ms

     7th                    784.54ms         783.32ms
Data Points                48                    48
Per pt ave              16.34ms            16.32ms

     8th                    783.47ms         783.68ms
Data Points                48                    48
Per 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                    48
Per 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.38
2 = 783.25
3 = 238.67
4 = 466.74
5 = 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                   48
Per 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                    48
Per 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                   48
Per pt ave              16.32ms            16.32ms

     7th                    784.54ms         783.32ms
Data Points                48                    48
Per pt ave              16.34ms            16.32ms

     8th                    783.47ms         783.68ms
Data Points                48                    48
Per 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                    48
Per 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
GO


Reading This Topic


Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....






Millisecond Forums


Search