|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+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.
|