|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+xDave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason Hmm, the stable stimulusonsets suggest that Inquisit is instructing the hardware to display stimuli / send the port signal out when it should be, so that's not where the bottleneck would appear to be. I don't know, maybe packet loss on the ethernet interface, some trouble at the sending end / the tracker, or maybe even a loose ethernet jack somewhere? EDITED TO ADD: Working from memory, it used to be the case that the plugin dropped gaze point samples the tracker marked as having "no validity" (e.g. the tracker detected an eye blink or other acquisition problem). So that could play a role with respect to the varying amounts of samples you're seeing per trial as well. There were plans to make this configurable (i.e. optionally record invalid samples), but I'm not 100% certain whether that's already in the current release (5.0.14.0). I will double-check on that tomorrow. In any case, are you running that latest version? Dave, Thanks - I think the data includes gaze point markers that have "no validity" as I notice there are columns titled leftvalidity, rightvalidity, (and others that I'm not sure about --> hasleftfixation, hasrightfixation, etc.) that for some samples indicate no validity which apparently is indicated with the number 4. This is, of course, if my understanding of that data, as explained in the link below, is correct. :-) Regards Jason https://www.millisecond.com/support/docs/v5/html/howto/tobii.htm Sorry, I forgot to add...I am using 5.0.11.0 I think this is the latest version...? Jason The latest version is 5.0.14.0, which is what I would recommend using: https://www.millisecond.com/download/
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+xDave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason Hmm, the stable stimulusonsets suggest that Inquisit is instructing the hardware to display stimuli / send the port signal out when it should be, so that's not where the bottleneck would appear to be. I don't know, maybe packet loss on the ethernet interface, some trouble at the sending end / the tracker, or maybe even a loose ethernet jack somewhere? EDITED TO ADD: Working from memory, it used to be the case that the plugin dropped gaze point samples the tracker marked as having "no validity" (e.g. the tracker detected an eye blink or other acquisition problem). So that could play a role with respect to the varying amounts of samples you're seeing per trial as well. There were plans to make this configurable (i.e. optionally record invalid samples), but I'm not 100% certain whether that's already in the current release (5.0.14.0). I will double-check on that tomorrow. In any case, are you running that latest version? Dave, Thanks - I think the data includes gaze point markers that have "no validity" as I notice there are columns titled leftvalidity, rightvalidity, (and others that I'm not sure about --> hasleftfixation, hasrightfixation, etc.) that for some samples indicate no validity which apparently is indicated with the number 4. This is, of course, if my understanding of that data, as explained in the link below, is correct. :-) Regards Jason https://www.millisecond.com/support/docs/v5/html/howto/tobii.htm Sorry, I forgot to add...I am using 5.0.11.0 I think this is the latest version...? Jason
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+xDave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason Hmm, the stable stimulusonsets suggest that Inquisit is instructing the hardware to display stimuli / send the port signal out when it should be, so that's not where the bottleneck would appear to be. I don't know, maybe packet loss on the ethernet interface, some trouble at the sending end / the tracker, or maybe even a loose ethernet jack somewhere? EDITED TO ADD: Working from memory, it used to be the case that the plugin dropped gaze point samples the tracker marked as having "no validity" (e.g. the tracker detected an eye blink or other acquisition problem). So that could play a role with respect to the varying amounts of samples you're seeing per trial as well. There were plans to make this configurable (i.e. optionally record invalid samples), but I'm not 100% certain whether that's already in the current release (5.0.14.0). I will double-check on that tomorrow. In any case, are you running that latest version? Dave, Thanks - I think the data includes gaze point markers that have "no validity" as I notice there are columns titled leftvalidity, rightvalidity, (and others that I'm not sure about --> hasleftfixation, hasrightfixation, etc.) that for some samples indicate no validity which apparently is indicated with the number 4. This is, of course, if my understanding of that data, as explained in the link below, is correct. :-) Regards Jason https://www.millisecond.com/support/docs/v5/html/howto/tobii.htm
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+xDave, One thought that just came to my mind....is it possible that the stimOffsetMarker at 1199ms is not getting set accurately because of interference with mysoundtrain at 1200ms? Maybe I should move that marker forward by a multiple of the refresh rate...? Does that logic apply here? Regards Jason That should not pose a problem per se -- Inquisit will just pick the refresh cycle that's closest to the specified time to send the offset marker. The sound and marker should not interfere with each other, but effectively both would be displayed / sent during the same display frame. P.S.: I've edited my previous response to add a remark about invalid gaze point samples, which might play a role here.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+xDave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason Hmm, the stable stimulusonsets suggest that Inquisit is instructing the hardware to display stimuli / send the port signal out when it should be, so that's not where the bottleneck would appear to be. I don't know, maybe packet loss on the ethernet interface, some trouble at the sending end / the tracker, or maybe even a loose ethernet jack somewhere? EDITED TO ADD: Working from memory, it used to be the case that the plugin dropped gaze point samples the tracker marked as having "no validity" (e.g. the tracker detected an eye blink or other acquisition problem). So that could play a role with respect to the varying amounts of samples you're seeing per trial as well. There were plans to make this configurable (i.e. optionally record invalid samples), but I'm not 100% certain whether that's already in the current release (5.0.14.0). I will double-check on that tomorrow. In any case, are you running that latest version?
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x[quote] stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) Dave, Thanks again. Regarding the stimulus onset times, the numbers I'm getting in the raw file are perfectly consistent.... -8, 391, 391, 391 all the way down (through all 10 stimuli). I'd tried adding pretrial pause = 100 and got the following, very promising, result (again, with everything off and disconnected): Stimuli Duration Samples 1 790.28 24 2 783.04 48 3 783.2 48 4 783.61 48 5 783.85 48 6 783.2 48 7 782.78 48 8 783.26 48 9 782.67 48 10 783.38 48 :-) It appears the pretrial pause setting really helped. I'm going to try extending it a bit, from 100, to see if that stabilizes the times for the 1st stimuli in the trial. Thanks so much for your help! Jason Dave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason Dave, One thought that just came to my mind....is it possible that the stimOffsetMarker at 1199ms is not getting set accurately because of interference with mysoundtrain at 1200ms? Maybe I should move that marker forward by a multiple of the refresh rate...? Does that logic apply here? Regards Jason
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x[quote] stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) Dave, Thanks again. Regarding the stimulus onset times, the numbers I'm getting in the raw file are perfectly consistent.... -8, 391, 391, 391 all the way down (through all 10 stimuli). I'd tried adding pretrial pause = 100 and got the following, very promising, result (again, with everything off and disconnected): Stimuli Duration Samples 1 790.28 24 2 783.04 48 3 783.2 48 4 783.61 48 5 783.85 48 6 783.2 48 7 782.78 48 8 783.26 48 9 782.67 48 10 783.38 48 :-) It appears the pretrial pause setting really helped. I'm going to try extending it a bit, from 100, to see if that stabilizes the times for the 1st stimuli in the trial. Thanks so much for your help! Jason Dave, Ok, this will be my last update for a bit as I have to return the eyetracker so another researcher can use it for a while. I've made some significant progress, thanks to your help, but it seems I'm still having some issues. With the pretrialpause setting at 150, I got the following results. Stimuli Duration Samples 1 769.41 47 2 450.72 23 3 783.23 48 4 766.29 46 5 783.14 48 6 760.29 21 7 738.79 26 8 783.45 48 9 782.83 46 10 783.24 48 The stimulus onset timings in the raw file continue to be stable at 391, 391, 391 The duration times, aside from stimulus 2, seem to be fairly stable but, for some reason, the samples are not...? I'll have to keep experimenting with my experiment to find a sweet spot that allows me to obtain maximum accuracy. Regards Jason
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+xDave, 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 That looks pretty promising indeed -- keep me posted in case you hit any additional snags and we'll take it from there.
|
|
|
|
|
Musashi Jason
|
|
|
Group: Forum Members
Posts: 61,
Visits: 158
|
+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x[quote] stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles) Dave, Thanks again. Regarding the stimulus onset times, the numbers I'm getting in the raw file are perfectly consistent.... -8, 391, 391, 391 all the way down (through all 10 stimuli). I'd tried adding pretrial pause = 100 and got the following, very promising, result (again, with everything off and disconnected): Stimuli Duration Samples 1 790.28 24 2 783.04 48 3 783.2 48 4 783.61 48 5 783.85 48 6 783.2 48 7 782.78 48 8 783.26 48 9 782.67 48 10 783.38 48 :-) It appears the pretrial pause setting really helped. I'm going to try extending it a bit, from 100, to see if that stabilizes the times for the 1st stimuli in the trial. Thanks so much for your help! Jason
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+x+x+x+x stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] Hello, I'm starting a new post here because my previous post was difficult to navigate as a result of my copy/pasting. I am using a Tobii X2-60 eye tracker and have a question about recording markers at stimulus onset and offset. I think my onset marker method is working as desired but the offset marker has an issue. Currently, my trial runs like this: (it is just a training trial at the beginning of my experiment) <trial trainingsession>
/ ontrialbegin = [
values.correcttrain = list.hpos.nextvalue;
values.distractortrain = list.hpos.nextvalue;
values.trainTitem = list.trainingitemsT.nextindex;
values.trainFitem = list.trainingitemsF.nextindex;
]
/ ontrialbegin = [
if (values.correcttrain == 30%) values.target = parameters.responsekeyleft else values.target = parameters.responsekeyright;
]
/ stimulustimes = [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1200=mysoundtrain; 1300=stimOffsetMarker]
/ inputdevice = keyboard
/ datastreams = eyetracker
/ validresponse = (parameters.responsekeyleft, parameters.responsekeyright)
/ correctresponse = (values.target)
/ response = correct
/ errormessage = true(errortxt, 500)
/ correctmessage = true(traincorrect, 800)
/ recorddata = true The above is with onset and offset markers set as follows earlier in the script /*this marker sends value "1" to signal onset of stimulus
<port stimOnsetMarker>
/port = eyetracker
/items = (1)
</port>
/*this marker sends value "0" to signal offset of stimulus
<port stimOffsetMarker>
/port = eyetracker
/items = (0) I was hoping to end up with regular intervals (e.g onset and offset markers should be present in my data for constant intervals of time - roughly 900ms (1300-400)) but this is not the result I am obtaining. I assume this is because a response can be made anytime during the trial (even before the sound stimuli...although that is not anticipated)... In such a case, I am unsure as to the timing of the offsetmarker. Currently, when testing this myself I get onset time intervals (for 10 items) ranging from 600ms to 891ms. Am I correct in assuming this is due to my response timing? (also, I understand that some minor fluctuation in times is the result of various margins of error (latencies) and their subsequent stackup - so far, this appears to account for very roughly 10ms or so) 1. Maybe I should be setting the offset marker just before the sound stimulus is presented. e.g. 1199=stimOffsetMarker2. Or, thinking from a different perspective, is it possible to set the offsetmarker to coincide with the keyboard response timing? 3. And, one additional question - is it possible to get stimulus item data in the eyetracker data stream? For example, a column appearing in the eyetracker data file with the heading stimulusitem that lists the stimulus present....or maybe sending this much data to the eyetracker slow everything down...? Regards Jason A quick followup to this inquiry: I just ran a quick test with the offsetmarker set at 1199 (just before the sound stimulus plays) and then trialed it once myself making sure not to select a response until after the sound had started to play. Oddly, of the ten items in my trial, the onset duration for 3 is considerably shorter than the remaining 7.... The duration of onset markers for the 10 stimuli are: 1 = 533.382 = 783.25 3 = 238.674 = 466.745 = 783.47 6 = 783.34 7 = 784.3 8 = 782.86 9 = 783.36 10 = 783.2 I'm baffled by the durations for #s 1, 3, and 4... 199-400=799 so the others seem to be very close and consistent....at roughly 16ms off of the calculated 'pure' duration. Jason If your trial allows responses at any time per some /beginresponsetime setting and is set to /responseinterrupt = immediate (the default), then the stimulus presentation sequence is terminated as soon as a response occurs, i.e. the offset marker will never be sent. Whether that is the case is not clear from your code. If you do allow responses while the stimulus presentation sequence is ongoing, but want the trial to complete said sequence despite a response, set the <trial>'s /responseinterrupt to frames. Dave, Thanks, as always, for your support. I've added /responseinterrup = frames to my trial but am still getting odd time durations that I cannot understand. With responseinterrrupt set to frames the trial should run through the entire sequence specified, correct? As such, I feel like the data file from the eyetracker should show markers at constant intervals but that is not what I'm getting. The stimulus times line from my script is: / stimulustimes : [0= clearscreen; 400=mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctoptiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] So, my assumption is that I should have markers in my eyetracker data that correspond with the amount of time the stiumus is present...or, to be more accurate, the amount of time between marker onset and marker offset. This is 1199-400=799. I get a duration close to this for some of the 10 items in the trial but not all...which is what is leaving me scratching my head. Additionally, I'm a bit perplexed, when looking at the eyetracker data file because the beginning data is sometimes marked, in the marker column, with a 1 and sometimes with a 0. I have the onset value =1 and offset=0. The inconsistency is what is confusing me here. I will attach the entire script here but cannot attach the entire package (with phots and audio files) due to size. Regards Jason P.S. I am currently only looking at the <trial trainingsession> trial. Code-wise, that all looks okay from the Inquisit perspective. I'm wondering whether -- sometimes, although it's unclear to me why that would be -- the onset marker is erased prematurely, thus yielding a shorter supposed offset than there should be. Inquisit's default behavior -- <port> stimuli as well as any other stimulus elements like <text> or <picture> -- is to erase the stimulus at the end, unless explicitly instructed not to per the stimulus element's /erase attribute. Erasing in the case of a <port> stimulus means returning the signal back to zero. With that in mind, I'm wondering whether you're getting consistent onset -> offset durations when setting /*this marker sends value "1" to signal onset of stimulus <port stimOnsetMarker> /port = eyetracker /items = (1) / erase = false</port> /*this marker sends value "0" to signal offset of stimulus <port stimOffsetMarker> /port = eyetracker /items = (0) / erase = false</port> Another thing to look at: For the trials where you see a shorter onset - > offset duration than expected (i.e. 1, 3 and 4 here https://www.millisecond.com/forums/FindPost26302.aspx ), look at the stimulusonsets for mypicturetrainT, mypicturetrainF and stimOnsetMarker. / stimulustimes = [0= clearscreen; 400= mypicturetrainT, mypicturetrainF, stimOnsetMarker; 450=correctopiontrain, distractoroptiontrain; 1199=stimOffsetMarker; 1200=mysoundtrain] To log these, add -- at a minimum -- three stimulusonset columns to the raw data file <data Sublim> / columns = (date,time,subject,group, blocknum,blockcode,trialnum,trialcode, stimulusonset, stimulusonset, stimulusonset, values.target, response, latency, eyetracker.lasttimestamp) / separatefiles = true </data> Inquisit will use the first display refresh cycle it can "catch" that's closest to the specified time in /stimulustimes to display the stimulus. If the system has some lag, looses refresh cycles due to resource exhaustion or a malfunctioning graphics card driver, or some other application running in the background is stealing processing and/or refresh cycles, that could delay the presentation of the image stimuli and the onset marker. The offset marker, however, could be presented on time, and you would end up with a shorter than expected onset->offset duration. Dave, Thanks for the suggestion of adding stimulusonset to the raw data file. I did that and ran through the 1st trial once with the following results. In the raw data file I see 3 stimulusonset times but it appears the 1st one is not mypicturetrainT but rather the time for clearscreen. Is this possible? The reason I am making this assumption is, the times shown are: -8, 391, 391 I added one more stimulusonset to the raw data log to end up with 4 in a row and get the following: -8, 391, 391, 391 So, I'm assuming the -8 is the clearscreen (not sure why it is a negative value) and the three 391s are my two stimuli and the marker. And, 391 + the 8 gives me 399 which is only 1ms off of the expected value of 400 so that all seems to make sense. I then continued to experiment some more and ran through the first trail, first with my internet connection via the USB-C hub on, with bluetooth on and a bluetooth mouse connected, and with various other programs running. The second time with everything off and disconnected. I even checked to make sure there were no odd runaway processes running in the background. The results of those two trail run-throughs, with some new data observations, follow: Stim Trial 1 Trial 2 1st 790.2ms 624.87ms Data Points 23 13 Per pt ave 34.26ms 48.07ms 2nd 785ms 783.3ms Data Points 46 48Per pt ave 17.07ms 16.32ms 3rd 768ms 351.82ms Data Points 47 18 Per pt ave 16.34ms 19.55ms 4th 721ms 783.3ms Data Points 41 48Per pt ave 17.59ms 16.32ms 5th 783.03ms 802.1ms Data Points 48 47 Per pt ave 16.31ms 17.07ms 6th 783.21ms 783.35ms Data Points 48 48Per pt ave 16.32ms 16.32ms 7th 784.54ms 783.32ms Data Points 48 48Per pt ave 16.34ms 16.32ms 8th 783.47ms 783.68ms Data Points 48 48Per pt ave 16.32ms 16.33ms 9th 519.36ms 486.35ms Data Points 25 26 Per pt ave 20.77ms 18.71ms 10th 600.28ms 783.54ms Data Points 29 48Per pt ave 20.70ms 16.32ms On a 60Hz monitor, I should get one frame per every 16.7ms which appears, if I'm thinking correctly, to coincide nicely with some of these ms per data point rates (the durations where there are 48 samples per duration). For the 2nd trial run, when everything was turned off and disconnected (thus theoretically minimizing processor competition) I was hoping to see an improvement but did not....or at least not as much as hoped. There are 6 durations with 48 samples in the second trial and only 4 in the first...so I guess that is a slight improvement. Is my thinking correct (or even in the ballpark) here? And, if so, what can I do to increase the accuracy of the data I'm obtaining from the Tobii eye tracker? I'm wondering where the weak link is...? My hardware, the Tobii plugin, the eyetracker and it's processor....all of the above? Any help and/or advice, as always, will be greatly appreciated. Regards Jason You are correct about the number of required stimulusonset columns. I neglected the clearscreen stimulus by mistake. Your assumptions about framerate and the resulting theoretical onset->offset duration are perfectly on point as well. What do the stimulusonsets for the trials with notably low number of samples say? E.g. the 9th and 10th trials for your first series, and the 3rd and 9th trials during your second series? Is there any commonality for those trials in the 1st and 2nd run, such as the same image stimuli selected? Finally, another thing to try and check whether it yields any improvement / increased consistency, would be adding a /pretrialpause (value should be rougly a multiple of the duration of one display refresh cycle) to the <trial> element -- that gives Inquisit some time to allocate memory, prepare stimuli, etc. before firing up the stimulus presentation sequence, i.e. something like <trial trainingsession> / pretrialpause = 50 ... </trial> (approx. 3 display refresh cycles) or <trial trainingsession> / pretrialpause = 100 ... </trial> (approx. 6 display refresh cycles)
|
|
|
|