|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+x+x+x+x+x+x+xhello, i am using an inquisit script for a scanning experiment. while some delays are accounted for (when tested on a separate computer), there is an added delay (about 100 ms) that occurs for the trial below when it is being run in the scanner and only when there is a response. this delay does not occur when testing outside of the scanner (with or without response). is there any way to prevent this or account for it? thank you! computer specs: Dell Precision 5820: Intel i9-1090X 3.7Ghz; 16GB DDR4; 512TB PCIe NVMe SSD; ATI Radeon Pro W6600 8GB, Windows 10 64-bit, Inquisit 5.0.14. <trial new_art> / ontrialbegin = [ values.artSample = list.newList_art.nextvalue; values.trialtimestamp = trial.new_art.timestamp; ] / stimulustimes = [0=blank, artP; 3000=newOld, memScale, mem_leftHand, mem_rightHand] / validresponse = ("0","1","2","3","4","5","6","7","8","9") / beginresponsetime = 3000 / trialduration = 5000 / ontrialend = [values.trialelapsedtime = trial.new_art.elapsedtime] / branch = [ trial.mem_iti ] </trial> How did you determine the existence and duration of this added delay? Is there any supporting data? yes, we are tracking the time as evidenced in the trial element above (specifically the initial timestamp has been the most useful attribute). It's not evident from that single trial element what exactly you are measuring and how. / ontrialend = [values.trialelapsedtime = trial.new_art.elapsedtime] for example does not reflect the trial's duration, but the time elapsed until that particular /ontrialend statement was executed, which may vary depeinding on a host of factors. So, show the supposed delay, please, with data as i mentioned before, we are using the intial timestamp "values.trialtimestamp = trial.new_art.timestamp;". we've measured the delay for all of the other trials and have accounted for the delay successfully. in this case it only happens when there's a response in the scanner (versus when there's no response, then there's barely any delay). i'm not sure how looking at the data will help you in this case, and will take a lot of explanation (since it's a very long script and there are many trial types). if you insist, i can send you the data. again, i don't know how this would help you. (to be crystal clear, we use the initial timestamp for each trial and subtract it from the previous one). and again, this is a direct comparison between this trial when there is and isn't a response. i don't think the issue is in how we're measuring the delay). > i'm not sure how looking at the data will help you in this case, and will take a lot of explanation (since it's a very long script and there are many trial types). It will help me: (1) verify your measurement method. (2) verify the magnitude of the delay. (3) check if and how the delay varies. (4) potentially narrow down where, exactly, it may occur. But since, you say, it only occurs in the scanner when there is a response (not outside of the scanner when there is a response), I would start looking at what the response hardware in the scanner scenario is doing. You've not said a word about that, i.e. is it a FMRI compatible keyboard -- wired, wireless, optical? A response box? Something else? Are the batteries, if any, okay? Do any of the cables have a shielding issue? Does the issue occur on that same Dell Precision 5820 computer even when not scanning? And so forth. it's a button box within the fMRI scanner. to be honest, i don't think we could change the hardware to accommodate this issue. i'm wondering whether we can change the trial code (ie., the software) to prevent a delay that could occur with a response (for example would adding a posttrialpause, allowing the response to register, help mitigate this?). normally we would just account for the delay by shortening the trials, but since this is response contingent, and we cannot predict when someone will miss a trial, we cannot do that. if there's is nothing you can suggest at the level of the software, then you can also say that. There's nothing wrong with the code per se, as you've seen for yourself when running outside the scanner on, I'm assuming, a different computer. I cannot propose any mitigations since it's not clear what's causing the delay / where exactly it arises. So, narrow that down, and then perhaps there's something that can be mitigated at the software-level. i can tell you that it reliably happens when someone inputs a response for that trial, it's about 100 ms, every single time. would setting /audit = true in data give more precise information? i appreciate and thank you for your help. > would setting /audit = true in data give more precise information? Potentially, yes.
|