Keypresses not properly registered in the experiment (appearing within the .log-file not the .csv)

[lara_k]

OS (e.g. Win10): Win10
PsychoPy version (e.g. 2024.2.4 Py 3.8): 2024.1.4
Standard Standalone Installation? (y) If not then what?:
Do you want it to also run online? (n)
What are you trying to achieve?:
I am currently piloting an fMRI study (using Current Design Buttonboxes as response button) and ran into the problem that, from some point in the experiment on, the buttonpresses seem not to be logged correctly anymore. Even though i can see the subject’s buttonpress using the LED display of the buttonbox, they do not seem to be registered within the experiment (not displayed on a second screen of the presentation PC) and appear as “None”-response without a reaction time within the csv-logs. However, they have been registered within the .log-logfile that i intended to use primarily to check the timing of triggers etc.
“None” is registered as allowed key, perhaps that could be a problem, but then again it isn’t for the first part of the experiment. I cannot seem to find a pattern, except that the issue worsens as the experiment progresses, i.e. within the final block 40-90% of the responses are “missed” by the software. Since i am computing performance-based rewards on a block level and present this feedback to the subject, I cannot rely on the .log-logfile to “correct” the logfile afterwards.

I used the builder to create the experiment and added some custom code blocks to define the target response, log information and display information about the current trial and response on a second screen.

What did you try to make it work?:
I edited the keyboard components, added an else-statement to check whether there might be an issue with the definition of the target key-press and printed it to the second screen that i also use to monitor the responses. I also checked the keyboard-component.started and .stopped columns to find out whether the component is “active” during the window of 2.1 s for the response. I also spot-checked whether the keypresses registered within the logfile would fall into that window.

I will add the pyhton script as well as some screenshots of the keyboard component and the data tab from the settings-cog. I have two subsequent conditions, each with a nested trial/block loop and both are started by triggers from the scanner (emulated as ‘t’ keypress). The keyboard components within both trial routines have identical settings and different variable names but the problem appears primarily within the second loop (or perhaps worsens more dramatically because the loop is longer and starts later within the study).

Please let me know if you need additional information, I’d be happy to add files or screenshots if it helps.

Best,
Lara

sfb940a1-b03-experiment.py (228.4 KB)
sfb940a1-b03-experiment.psyexp (289.9 KB)

[wakecarter]

Why do you have “None” as an allowed key? I can’t think of that doing anything good.

In your Each Frame code you have

but you don’t have 8 and 9 as allowed keys.

I also note that there is 400ms after the end of the keyboard component before the routine ends, where key presses won’t be accepted.

[lara_k]

Yes, i removed “None” as an allowed key following my post here. I originally used it, thinking that it might be easier to discriminate no responses from wron buttons but i recognized that it’s not needed for that. Similarly, i included 8 and 9 in the each frame code, just in case a subject presses one of the other buttons on the buttonbox, but in practice that rarely happens, so i removed them from the “allowed keys” tab and forgot to adapt the code snippet.

We originally planned with a 2s response time-out and i had the trial routine set up in a way that it would last 2s (with the keyboard component also ending after 2s) followed by a 500 ms blank screen. Following those problems with registering of the responses i moved the blank phase inside the trial component and wanted to check whether a longer keyboard component duration and a short pause at the end of the trial might help saving all data. I thought that maybe, some operations might benefit from that, as I suspected that perhaps there might be problems when several components start and end at the same time. But I suspect that should not be a problem.

I will pilot the experiment again with a button- and a triggerbox on my laptop, to check whether removing “none” from the allowed keys section and extending the duration of the keyboard component to the end of the routine already does the trick!