synchronize event markers with refresh rate

Wed Apr 13 19:27:23 UTC 2011

Thanks Paul. I did incorporate your recommendation into my program.
However, there are still some issues unresolved. So I use the
OnsetSignalDelay command for the event markers associated with the
appearance of stimuli on the screen and I still use the writeport
command to send event markers associated with the timing of touch
screen responses. Can the OnsetSignalDelay command address multiple
"pins" (OnsetSignalData) in its output ?
The signal that E-prime sends to the other PC is actually an "8-bit
strobe" which requires a "strobe signal" to be sent immediately after
the 8-bit strobe. Currently it seems that the strobed event marker is
not received until the end of the actual stimulus because the strobe
signal is not received until an inline immediately after the stimulus.
Is there a way to set OnsetSignalData to address  two pins (one
included in the strobe (parallel port output pins 2-9 (= D0-D7 = &H378
1-255) and one on parallel port pin 1 (=C0, &H378+2) ? This may sound
complicated but we have used this approach successfully as a way to
communicate between systems where the timing was not as critical.
Hank

On Mar 30, 12:40 pm, Paul Groot <pfc.gr... at gmail.com> wrote:
> Hi Hank,
>
> When using event markers for visual stimuli, you never should use the
> writeport function. This is because (in most cases) you would like to
> present the visual stimulus during the short refresh fase of the
> display. This is the default case when onset sync is set to vertical
> blank. (As David already explained!) If the stimulus is not synced
> this way, you will end up with an incomplete first frame (flickering).
> So, in most cases this causes unpredictable onset delays. Therfore,
> any writeport call will be executed to early, because eprime will hold
> the image presentation until the next refresh occurs (=OnsetDelay).
> So, just use the Onset/Offset properties described in the previous
> emails. The OnsetSignal will automatically generate a trigger as soon
> as the image is presented. (I.e. EPrime will automatically sync the
> implicit writeport command properly)
>
> Also: Preparation of  the image (loading, uncompressing, scaling, ...)
> could be performed during a so called pre-release period. This period
> can be defined in the object just before the stimulus. This is advised
> for accurate onset times because image preparation time is NOT fixed
> in general. However, be carefull if you put any inline script between
> this object and the stimulus. (It will be executed at the start of the
> pre-release period!)
>
> best
> paul
>
> 2011/3/30 Hank Jedema <Jed... at pitt.edu>:
>
>
>
>
>
>
>
> > Thanks to Davis, Baris, and Paul for your quick responses.
> > I used a writeport command in my code to send my event markers to my
> > recording system. I will have to look up what the exact loading time
> > of an image on my Elo Carroll touch screen is, because I did not
> > adjust for that (fixed) delay yet.
> > I based my question on the timing of the event markers on the
> > following: I collect multiple event markers for both the stimulus
> > appearance as well as the response timing using a electrophysiology
> > rig with sub-millisecond (<0.15 msec) timing accuracy. When I compare
> > the time difference between 2 event markers from touch screen
> > responses it seems that Eprime and my Plexon rig correspond nicely
> > (<1msec difference). When I compare the time difference between an
> > event marker from a stimulus appearance and a touch screen response,
> > there is a much greater difference (10-18msec). On a trial by trial
> > basis the difference between the two event markers seems to match the
> > stimulus.onset delay listed in the Eprime output. Based on this, I
> > believe that the event marker sent out by my E-prime code precedes the
> > appearance of the stimulus on the screen. I will try the suggestion to
> > use an inline as soon as the stimulus is on the screen next week. I
> > will also check on the thread that David provided and post my results.
>
> > Best,
> > Hank
>
> > On Mar 30, 2:39 am, Paul Groot <pfc.gr... at gmail.com> wrote:
> >> Hi Hank,
>
> >> The event markers should be in sync when you prepare the markers using
> >> the following functions:
>
> >> Stim.OffsetSignalEnabled = True
> >> Stim.OnsetSignalEnabled = True
> >> Stim.OffsetSignalPort = &H378
> >> Stim.OnsetSignalPort = &H378
> >> Stim.OffsetSignalData = &H00
> >> Stim.OnsetSignalData = &HFF  ' < this is your onset code in hexadedimal notation
>
> >> Where Stim is your display object.
>
> >> Most flatscreens have an onset delay of a few milliseconds, so this
> >> would be a fixed delay caused by the properties of the display.
>
> >> Best,
> >> Paul
>
> >> 2011/3/29 Hank Jedema <Jed... at pitt.edu>:
>
> >> > Hi All,
>
> >> > I am trying to run a stop signal response task while recording
> >> > electrophysiological activity on another setup. In order to get
> >> > synchronization of behavior with the timing of my recordings, I have E-
> >> > prime sent out event markers via the parallel port to an input of my
> >> > recording device. It seems that this works well responses, but it
> >> > seems that E-prime sends out the event markers for the display of
> >> > stimuli before the stimulus actually appears on the screen: the
> >> > eventmarker/timestamp is sent when the code issues the request for the
> >> > stimulus to appear, rather than when the stimulus actually appears on
> >> > the screen (i.e at the vertical blank/screen refresh after the
> >> > stimulus.onset delay). Is there a way to get the event marker signal
> >> > to synchronize with the actual appearance of the stimulus or is this
> >> > something that can only be corrected offline by correcting the
> >> > timestamps for stimulus appearance with their onset delay ?
>
> >> > Thanks very much for your help.
>
> >> > Hank
>
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "E-Prime" group.
> >> > To post to this group, send email to e-prime at googlegroups.com.
> >> > To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
> >> > For more options, visit this group athttp://groups.google.com/group/e-prime?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "E-Prime" group.
> > To post to this group, send email to e-prime at googlegroups.com.
> > To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/e-prime?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.