FMRI Stop Signal about craconweb HOT 18 CLOSED

Yup. Thanks

from craconweb.

Yes, 11pm central time?

from craconweb.

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

from craconweb.

@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.

from craconweb.

@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?

from craconweb.

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?

from craconweb.

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.

from craconweb.

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?

from craconweb.

@abadi199

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

from craconweb.

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.

from craconweb.

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

from craconweb.

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

from craconweb.

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?

from craconweb.

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

from craconweb.

Could we do a call tonight?

from craconweb.

@abadi199 ^

from craconweb.

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

from craconweb.

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

from craconweb.