FMRI Stop Signal

[nqthqn]

Respect new field user.jitter.

• add statically seeded randomized 3 - 7 second inter-trial jitter
• store jitter=true in gsession
• change key responses for stop signal (spacebar -> 0) NOT '
• trigger start on ' (scanner emits this keyboard events at start of scan, and continually pulses)
• add fmri checkbox to admin for each user (PUT /user with jitter=true)
• staff side button to start game.

[nqthqn]

@abadi199 Could I get an ETA on this, please?

[nqthqn]

@abadi199

My apologies, there's been a spec change as of this mornings meeting.

The game will need to reside on the admin side and the staff member will need to input a valid username which will determine the correct ugimages to preload.

[abadi199]

@nqthqn I'm still a bit confused by this jitter. When you said 3-7 second inter-trial jitter, do you mean total rest period will be between 3-7 seconds, or 500ms + jitter?

[nqthqn]

The former. Total rest period will be between 3-7 seconds. The order randomization for trial and jitter should be based on the same see.

So, all participants, in the scanner will see the same order of trials and have the same order of inter-trial jitter.

example

first run:
pic1/blue, 3sec, pic2/gray, 4sec, pic3/blue, 5sec, pic4/blue, 7sec...

second run:
pic1/blue, 3sec, pic2/gray, 4sec, pic3/blue, 5sec, pic4/blue, 7sec...

Make sense?

[abadi199]

Yup. Thanks

[nqthqn]

And, do you understand the new twist? Instead of Stop Signal with a jitter setting, it's a separate Stop Signal that only staff can administer to the participants while they are in the FMRI.

[abadi199]

I think I understand the requirement. I'm just not sure how the UI should look like, e.g. for the login form, where in admin page should the button be, etc.
Do you think you can create a simple mockup for this?

[nqthqn]

@abadi199

then after clicking "start" the whole page would be the game, which needs to be triggered by '.

[abadi199]

Two things:

• do we need to ask for the user's password on the user dialog? if not, can we just implement the button inside of the user row? that way, we can avoid having the need for the username dialog.
• we're going to need a new backend api for submitting fmri gcycles data since we need to include the userId data.

[nqthqn]

Gsession Has user I'd and entering username is a requirement. It ensures the game is getting played by the correct participant - so if the username does not exist then it will not play the game

[nqthqn]

No need to enter password. Basically the fmri person is in as staff then starts the stop signal game on behalf of the participant who is in the machine

[abadi199]

More questions:

• I also need to load the user's filler, valid, and invalid images and then preload them, correct?
• If yes, wouldn't that make the game unique per user, e.g: each user will see different sets of images based on their profile? would it make sense to set ugimgset for admin, and when in fmri, we'll always use the admin's ugimgset?

[nqthqn]

For now, fetch and preload the users image set - I think the important thing that aligned was the timings. I emailed Sonja for clarification.

[nqthqn]

Could we do a call tonight?

[nqthqn]

@abadi199 ^

[abadi199]

Yes, 11pm central time?

[nqthqn]

@abadi199 CONFIRMED 💃 💯 😄 Think you'll be able to rush this feature for tomorrows testing?

[nqthqn]

@abadi199 The mechanics of this in relation to the fMRI scanner worked. We did discover incorrect game play behavior: #52