inaccurate Trigger

177 views
Skip to first unread message

Julie Paré

unread,
Dec 14, 2014, 5:46:13 PM12/14/14
to e-p...@googlegroups.com
Hi,

I am experiencing problems with the accuracy of my response triggers E-Prime is sending to PyCorder. The timing is ok and my stimuli triggers are correctly labelled. The problem is with my response triggers, the label is different from what I thought I programmed, and I get the same incorrectly labelled trigger for a good or bad participant response. I went over and over my paradigm but I can`t figure out what I did wrong.

Does anyone had that problem before? 

Many thanks,

Julie

Michiel Sovijärvi-Spapé

unread,
Dec 15, 2014, 3:13:24 PM12/15/14
to e-p...@googlegroups.com

Hi,

Unless we do things *very* different, a “Stimulus trigger” is exactly the same as a “Response trigger”, which in E-Prime seems to mean, normally, a value between 1 and 255. PyCorder is Brain Products, yes? So I suspect that you, like most of us, are indeed aiming to send a byte over parallel. Three things that happen a lot:

·         One normal thing that will make the trigger come out wrong is by having values go higher than 255

·         Another is that the signal isn’t reset to 0. Say, you send a trigger of 25, manually, then later on 25 happens again: if it’s not reset to 0, there’s only the first. Quick and dirty solution, wait 2 ms, send a writeport outport, 0. Better: send .onsignaldata and .offsignaldata (or some such code, I keep forgetting and have to copy it myself from previous studies).

·         Finally, sending writeport outport, 25, then waiting 1, then writeport outpot, 22 may still give unintelligible results if the amplifier uses a sampling rate lower than 1000 Hz (because the two values get to be scrambled into a new byte!).

 

These are pretty much the normal cases of something going wrong with triggers, anything else is likely in your own design (especially if the other triggers are going fine). My suggestion with triggers:

Say, you have a reaction time paradigm. There’s a stimulus – stimulusSlide – which shows until response. Turn off off-sync (default). Say, you have 20 conditions in a 4x5 design.

1.       You set stimulusslide.onsetsignaldata to be 1-20 depending on your condition

2.       You set stimulusslide.offsetsignaldata to be 21. That’s the RT.

3.       After the stimulusslide, you add the code

Sleep 5 (to be sure it doesn’t interfere with the previous!)

If StimulusSlide.ACC = 1 then Writeport outport, 22 else Writeport outport, 23

Sleep 5

Writeport outport, 0

 

Now you have pretty much everything a normal experiment needs. Make sure you don’t reuse triggers (otherwise, we have other tricks for that).

Hope that helps!

Best,

Michiel

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/1795b976-a487-40c4-8892-bf2cc148c6a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David McFarlane

unread,
Dec 15, 2014, 4:34:23 PM12/15/14
to e-p...@googlegroups.com
Julie,

(Disclaimer: I have no experience with PyCorder itself.)

What verions of E-Prime do you use? What
mechanism do you use for your "response triggers"
-- WritePort, OnsetSignal..., Task Events? By
"response trigger" do you mean a *signal* sent to
PyCorder upon a subject response?

E.g., if you wrote your program with EP2.0.10 or
later, and used WritePort in code after your
stimulus object, then the new default of
PreRelease = "(same as duration)" would mean that
your response WritePort may execute *before* your
subject responds, and would always send the same
value. Lots of ways to go wrong here. For more discussion on this, see
https://groups.google.com/d/topic/e-prime/z8PQMH1cf70
https://groups.google.com/d/topic/e-prime/7w5ajYuHqgw
https://groups.google.com/d/topic/e-prime/xmnq_4kSHAU
https://groups.google.com/d/topic/e-prime/OeiZ00V9SRc

-- David McFarlane


At 12/15/2014 03:13 PM Monday, Michiel Sovijärvi-Spapé wrote:
>Hi,
>Unless we do things *very* different, a
>“Stimulus trigger†is exactly the same as a
>“Response trigger†, which in E-Prime seems
>to mean, normally, a value between 1 and 255.
>PyCorder is Brain Products, yes? So I suspect
>that you, like most of us, are indeed aiming to
>send a byte over parallel. Three things that happen a lot:
>· One normal thing that will make the
>trigger come out wrong is by having values go higher than 255
>· Another is that the signal isn’t
>reset to 0. Say, you send a trigger of 25,
>manually, then later on 25 happens again: if
>it’s not reset to 0, there’s only the first.
>Quick and dirty solution, wait 2 ms, send a
>writeport outport, 0. Better: send .onsignaldata
>and .offsignaldata (or some such code, I keep
>forgetting and have to copy it myself from previous studies).
>· Finally, sending writeport outport,
>25, then waiting 1, then writeport outpot, 22
>may still give unintelligible results if the
>amplifier uses a sampling rate lower than 1000
>Hz (because the two values get to be scrambled into a new byte!).
>
>These are pretty much the normal cases of
>something going wrong with triggers, anything
>else is likely in your own design (especially if
>the other triggers are going fine). My suggestion with triggers:
>Say, you have a reaction time paradigm.
>There’s a stimulus – stimulusSlide – which
>shows until respesponse. Turn off off-sync
>(default). Say, you have 20 conditions in a 4x5 design.
>1. You set stimulusslide.onsetsignaldata
>to be 1-20 depending on your condition
>2. You set stimulusslide.offsetsignaldata to be 21. That’s the RT.
>3. After the stimulusslide, you add the code
>Sleep 5 (to be sure it doesn’t interfere with the previous!)
>If StimulusSlide.ACC = 1 then Writeport outport, 22 else Writeport outport, 23
>Sleep 5
>Writeport outport, 0
>
>Now you have pretty much everything a normal
>experiment needs. Make sure you don’t reuse

Julie Paré

unread,
Dec 17, 2014, 7:23:11 AM12/17/14
to e-p...@googlegroups.com
Thanks a lot Michiel and David,
 
I haven't had a chance to try your tips yet, but I a am sure these well explained answers will help me a lot.
 
Best regards,
 
Julie 
Reply all
Reply to author
Forward
0 new messages