By tecnika - 7/31/2017
Hello Dave,
I programmed this experiment in Inquisit and on my surprise I have seen that few participants had higher reaction times than expected.
The maximum that I thought I set up should be 800ms, but some participant had 3000ms plus to the button press "shoot" or "not shoot".
I send you in attachment a datafile and one experiment.
Please let me know if you need more details or the pictures. The experiment was set up for using cedrus response box.
Many thanks,
Elena
|
By Dave - 8/1/2017
+xHello Dave, I programmed this experiment in Inquisit and on my surprise I have seen that few participants had higher reaction times than expected. The maximum that I thought I set up should be 800ms, but some participant had 3000ms plus to the button press "shoot" or "not shoot". I send you in attachment a datafile and one experiment. Please let me know if you need more details or the pictures. The experiment was set up for using cedrus response box. Many thanks, Elena
Sorry, no idea offhand. My first guess would be a malfunction of the response box, but I'll additionally note that the Inquisit version used to run this participant seems outdated (4.0.8.0 was used, the latest release is 4.0.10.0). Is that also true for the other (how many?) participants where the latencies seem off? Where those data, perhaps, all collected on the same computer or on different machines?
|
By seandr - 8/1/2017
While it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem.
It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look.
Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed.
-Sean
|
By tecnika - 8/1/2017
+x+xHello Dave, I programmed this experiment in Inquisit and on my surprise I have seen that few participants had higher reaction times than expected. The maximum that I thought I set up should be 800ms, but some participant had 3000ms plus to the button press "shoot" or "not shoot". I send you in attachment a datafile and one experiment. Please let me know if you need more details or the pictures. The experiment was set up for using cedrus response box. Many thanks, Elena Sorry, no idea offhand. My first guess would be a malfunction of the response box, but I'll additionally note that the Inquisit version used to run this participant seems outdated (4.0.8.0 was used, the latest release is 4.0.10.0). Is that also true for the other (how many?) participants where the latencies seem off? Where those data, perhaps, all collected on the same computer or on different machines?
Hi Dave,
Thank you for your reply. This happened in all Macs the student was testing and with all the response boxes independently. Also if the response box isn't working from the program I set up, I would expect that after 800 ms of no response it will go to the next trial and not recording any response that is over 800ms...
Elena
|
By tecnika - 8/1/2017
+xWhile it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean
Hi Sean.
Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box
The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that?
Many thanks,
Elena
|
By Dave - 8/2/2017
+x+xWhile it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena
> The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms
> of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that?
No, you're absolutely right. This is precisely what the script should do. As you pointed out, with
<trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total?
|
By tecnika - 8/2/2017
+x+x+xWhile it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena > The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms > of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? No, you're absolutely right. This is precisely what the script should do. As you pointed out, with <trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total?
Almost half of them has few reaction times over 3000ms. I'll send you the data file with all the data
|
By tecnika - 8/2/2017
+x+x+x+x[quote]While it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena > The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms > of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? No, you're absolutely right. This is precisely what the script should do. As you pointed out, with <trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total? Almost half of them has few reaction times over 3000ms. I'll send you the data file with all the data
They are 13 participants out of 60. This happened with in all two Macs where the participant tested (one or the other) and with both Cedrus RB-730 used. The experiment files were 4 (R_B -= right blurred, L_B = left blurred, R_N = right focused/neat, L_N = left focused/neat). All the 4 programs were similarly built and with the same instructions and setting. Please find below the pivot tables with the number of trials with latency > 801ms per participant.
| Participant | nr trials with latency >801ms | | 12_R_B | 1 | | 19_L_N | 2 | | 22_R_N | 1 | | 25_L_B | 49 | | 26_R_N | 2 | | 31_L_N | 28 | | 34_R_N | 1 | | 42_R_N | 13 | | 48_R_B | 1 | | 49_L_B | 3 | | 54_R_N | 1 | | 56_R_B | 2 | | 60_R_B | 6 | | Grand Total | 110 |
|
By tecnika - 8/2/2017
+x+x+x+x+x[quote]While it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena > The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms > of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? No, you're absolutely right. This is precisely what the script should do. As you pointed out, with <trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total? Almost half of them has few reaction times over 3000ms. I'll send you the data file with all the data They are 13 participants out of 60. This happened with in all two Macs where the participant tested (one or the other) and with both Cedrus RB-730 used. The experiment files were 4 (R_B -= right blurred, L_B = left blurred, R_N = right focused/neat, L_N = left focused/neat). All the 4 programs were similarly built and with the same instructions and setting. Please find below the pivot tables with the number of trials with latency > 801ms per participant. | Participant | nr trials with latency >801ms | | 12_R_B | 1 | | 19_L_N | 2 | | 22_R_N | 1 | | 25_L_B | 49 | | 26_R_N | 2 | | 31_L_N | 28 | | 34_R_N | 1 | | 42_R_N | 13 | | 48_R_B | 1 | | 49_L_B | 3 | | 54_R_N | 1 | | 56_R_B | 2 | | 60_R_B | 6 | | Grand Total | 110 |
Trying to test it now...it look like you have longer reaction times when you answer really early (just as soon as the image appear)
|
By tecnika - 8/2/2017
+x+x+x+x+x+x[quote]While it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena > The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms > of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? No, you're absolutely right. This is precisely what the script should do. As you pointed out, with <trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total? Almost half of them has few reaction times over 3000ms. I'll send you the data file with all the data They are 13 participants out of 60. This happened with in all two Macs where the participant tested (one or the other) and with both Cedrus RB-730 used. The experiment files were 4 (R_B -= right blurred, L_B = left blurred, R_N = right focused/neat, L_N = left focused/neat). All the 4 programs were similarly built and with the same instructions and setting. Please find below the pivot tables with the number of trials with latency > 801ms per participant. | Participant | nr trials with latency >801ms | | 12_R_B | 1 | | 19_L_N | 2 | | 22_R_N | 1 | | 25_L_B | 49 | | 26_R_N | 2 | | 31_L_N | 28 | | 34_R_N | 1 | | 42_R_N | 13 | | 48_R_B | 1 | | 49_L_B | 3 | | 54_R_N | 1 | | 56_R_B | 2 | | 60_R_B | 6 | | Grand Total | 110 | Trying to test it now...it look like you have longer reaction times when you answer really early (just as soon as the image appear)
If the participant is responding during the fixation cross (500 ms) it's showing quickly the image but skipping immediately to the next trial and the response time will be summed from the previous sentence presentation (3000ms).
<trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
So if a participant respond during the fixation cross her/his reaction times registered will be between 3000ms and 3500ms. Is this interpretation something it may be? I though that the only part "sensitive" to a response would have been just the last part ("500 = Gun"). If not, I would expect a time between 0 and 500ms.
|
By Dave - 8/3/2017
+x+x+x+x+x+x+x[quote]While it's always good practice to update to the latest version, Inquisit 4.0.8 measures response times just fine, so I don't think that's the problem. It's possible there's a problem with the design, logic, or instructions of the script. If you could send a zip file with all the image files required to run it, we could take a look. Is there any reason to think this participant isn't simply slow, cautious, has poor eyesight, or was trying to game the test to respond in a non-biased way? Typically the POD imposes a very short response deadline, so it's curious that 3 second responses would even be allowed. -Sean Hi Sean. Thank you for your reply. Please find attached the zipped file with the images. I also used a cedrus response box The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? Many thanks, Elena > The problem is that answer slower than 800ms shouldn't be allowed by the script (the trial is total 1300 ms = 500ms of blank screen + 800ms > of image where the participant can answer) ... this is at least what I wanted and expected. Is the script not doing that? No, you're absolutely right. This is precisely what the script should do. As you pointed out, with <trial Gun>
/ ontrialend = [values.hazard = "Gun"]
/ stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300
/ validresponse = (144,112)
...
</trial>
response detection starts 500ms into the trial and the trial times out 800ms later, at 1300. I.e., in any given trial, the achievable maximum latency should be ~800ms, and higher latencies (such as those in the data file you kindly shared) should not be possible at all. So, there definitely is something wrong here, possibly in the interaction between Inquisit and the response box.
You mentioned in your initial post that a "few participants had higher reaction times than expected." May I ask how many out of the total? Almost half of them has few reaction times over 3000ms. I'll send you the data file with all the data They are 13 participants out of 60. This happened with in all two Macs where the participant tested (one or the other) and with both Cedrus RB-730 used. The experiment files were 4 (R_B -= right blurred, L_B = left blurred, R_N = right focused/neat, L_N = left focused/neat). All the 4 programs were similarly built and with the same instructions and setting. Please find below the pivot tables with the number of trials with latency > 801ms per participant. | Participant | nr trials with latency >801ms | | 12_R_B | 1 | | 19_L_N | 2 | | 22_R_N | 1 | | 25_L_B | 49 | | 26_R_N | 2 | | 31_L_N | 28 | | 34_R_N | 1 | | 42_R_N | 13 | | 48_R_B | 1 | | 49_L_B | 3 | | 54_R_N | 1 | | 56_R_B | 2 | | 60_R_B | 6 | | Grand Total | 110 | Trying to test it now...it look like you have longer reaction times when you answer really early (just as soon as the image appear) If the participant is responding during the fixation cross (500 ms) it's showing quickly the image but skipping immediately to the next trial and the response time will be summed from the previous sentence presentation (3000ms). <trial Gun> / ontrialend = [values.hazard = "Gun"] / stimulustimes = [0= cross; 500 =Gun]
/ timeout = 1300/ validresponse = (144,112) ... </trial> So if a participant respond during the fixation cross her/his reaction times registered will be between 3000ms and 3500ms. Is this interpretation something it may be? I though that the only part "sensitive" to a response would have been just the last part ("500 = Gun"). If not, I would expect a time between 0 and 500ms.
That sounds like a plausible theory, and may come down to the response box behavior (as opposed to other input devices). We'll check into this and let you know.
|
|