synchronize event markers with refresh rate

[Hank Jedema]

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

[David McFarlane]

Hank,

Stock reminder: 1) I do not work for PST. 2) PST's trained staff
takes any and all questions at
http://support.pstnet.com/e%2Dprime/support/login.asp , and they
strive to respond to all requests in 24-48 hours -- this is pretty
much their substitute for proper documentation, so make full use of
it. 3) If you do get an answer from PST Web Support, please extend
the courtesy of posting their reply back here for the sake of
others. (Flash -- As noted in the most recent PST e-mail Newsletter,
we can all now access the E-Prime Knowledge Base without having to
log in. Woo hoo!)

That said, here is my take...

Hmm. Could you post some details on how you measured this
discrepancy? Are you using the "OnsetSignal..." properties of the
stimulus to send your signals to your device? And are you sure that
you have Onset Sync set to "vertical blank" for your stimulus?

I have to admit that the documentation in the online E-Basic Help
remains vague on when exactly OnsetSignal is supposed to send its
signal -- At the StartTime of the
stimulus? TargetOnsetTime? OnsetTime? ActionTime? (See the EP
manuals for explanation of these items, or my own discussion at
http://groups.google.com/group/e-prime/browse_thread/thread/39e899d3457d4917 ).

But let's suppose that OnsetSignal acts at the OnsetTime. Then, as I
understand it, as long as Onset Sync is set to "vertical blank",
then, once EP reaches the TargetOnsetTime for the stimulus, it
further withholds the stimulus until the next vertical blank, then
presents the stimulus (which should now appear almost simultaneously
on the screen), sends the OnsetSignal, and considers this the actual
OnsetTime. Thus, there would be no way for the OnsetSignal to not be
synchronized with the vertical blank, unless you do not have Onset
Sync set to "vertical blank", or I am just wrong about how
OnsetSignal works. So again, we need to know (1) whether the
OnsetSignal really does always coincide with the stimulus OnsetTime,
and (2) whether you have Onset Sync set to "vertical blank".

Although I have measured many of these things in detail myself, I
have not yet done so for this exact issue, so I will be interested to
learn of your methodology and measurements.

-- David McFarlane, Professional Faultfinder

[Baris Demiral]

Hank, 

In practice, there is no trigger which can be sent on the exact complete onset of the stimulus. Only thing is that the trigger can best be written out when the stimulus is started to be written on the screen. In LCD monitors this is a bit different but lets come to the main issue.

There are some strategies that you can follow in order to minimize the trigger jitters between the trials in e-prime. I will list these for you. But beforehand you need to know i) what the refresh rate of your monitor is ii) what your digital loading (on the digital card) is on your LCD monitor (if you are using one). 

Try to set the duration of the object (which I will can Y)  preceding the main object (which I will call X, that you will send trigger to be marked for the onset) to be the multiples of the refresh rate.

First option: Maybe the best option is to use something like:

X.OnsetSignalEnabled

X.OnsetSignalPort
X.OnsetSignalData

 

where "X" is the actual name of the object on which the property is being set.

Write an inline at the beginning of the experiment/trial and set these. You can read more about this at http://www.pstnet.com/eprimelegFAQ.cfm.

If you want to control the length of the trigger, you either write the following lines in the same on-line object:

X.OffsetSignalEnabled
X.OffsetSignalPort
X.OffsetSignalData

Or, use WRitePort and prepare another in-line object, put this inline after the X object and set X object's PreRelease to [X duration minus length of the trigger you desire]. In e-prime PreRelease "releases" (or executes) the inline objects coming after right away. It does not wait. Then, it prepares the next object to be shown as soon as the offset of X. But, make sure that Pre-release did not alter the length of the X object, because if you keep PreRelease very long it can act weird (at very long prereleases compared to the object's original duration). So this option is great if you have stimuli with very short durations. Almost exact onset time is caught. But you go with a long trigger as long as the X object if this does not bother you. 

Second option: (Offset correction/consideration needed, but no jitters).   Set Y's PreRelease to a value which will be good enough to cover up for  i) vertical blank time ii) trigger length. I assume you loaded your images/sounds at the beginning of the trial. If you did not,  you need to include iii) loading time of the stimulus. For example: You have an image shown in X which takes 40-50ms to load (you can find this in e-prime output when you are designing your experiment and testing some dummy experiment. Look at the onset latency).  

You know your monitor's refresh rate is 100Hz, and you want your trigger to be 5ms (for some other reasons).  Total time required for the image to be ready to be displayed is minimum 40+10+5=55ms maximum 65ms. Use Pre-release in Y and set it to 70ms (or if you want to be safer, set it to 100ms). Then write the in-line to send the trigger after Y. This will ensure that all your triggers will be sent exactly 70 or 100ms before time the stimulus is started to be written to the screen. If you load your images at the beginning of the trial or you are showing text, you can make the PrRelase shorter, 20ms.

You also factor in if there are some LCD digital preparation duration latencies in the digital card of the LCD monitor. For instance for Samsung 100Hz LCD I found this to be 10ms. But it is, at least, presenting the image as a whole once (I think), not bit by bits consecutively as in CRT.

Third Option: Use Canvas object like things and write your code.  You can have full control. There were some nice scripts on this list written by some others. Or use something like WaitForVerticaBlank after you load your images and make them ready. WaitForVerticalBlank makes the object ready to be shown, then you can send the trigger, and the object is shown in the next refresh time. This option will make sure you fix the latency between the trigger and the stimulus just one refresh rate. Don't make the length of the trigger longer than the refresh rate.

If you know how earlier the triggers were sent, then you can use this information to adjust for time windows or other statistics later.

Best

Baris

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

--
SB Demiral, PhD.
Department of Psychology
7 George Square
The University of Edinburgh
Edinburgh, EH8 9JZ
UK
Phone: +44 (0131) 6503063

[Paul Groot]

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...@pitt.edu>:

[Hank Jedema]

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

[Paul Groot]

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...@pitt.edu>:

[Hank Jedema]

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

[David McFarlane]

Hank,

(Hmm, I see OnsetDelay, OnsetSignalData, OnsetSignalEnabled, and
OnsetSignalPort, but no OnsetSignalDelay, so not sure what you are
referring to there. But no matter...)

Yes, both OnsetSignal... and WritePort can handle all 8 bits of any
digital I/O port. For more background information on how to
generally handle multiple digitital I/O bits, please read "Parallel
Port Complete" by Jan Axelson
(http://www.amazon.com/Parallel-Port-Complete-Programming-Interfacing/dp/0965081915/ref=sr_1_1?ie=UTF8&s=books&qid=1302813230&sr=1-1
), or just Google around.

-- David McFarlane, Professional Faultfinder

[Paul Groot]

Hi Hank,

The OnsetSignal-properties can only address one IO-port at the time
(all 8 bits at the same time because there is no masking mechanism).
Using any kind of handshaking just complicates the one-way digital
interface. However, if you still would like to use a separate strobe
signal, you could use the WritePort function in an inline just before
the stimulus object to set/prepare the 8 data-pins. Then configure the
OnsetSignal properties to generate the time-critical strobe signal, so
it 'triggers' at stimulus onset. However, the OnsetSignal properties
cannot write individual bits of the control register (C0), so this
might complicate things a bit if other bits of the control register
should be preserved. Also note that this wouldn't work if the duration
of the strobe is critical and is different from the stimulus duration.

The markers that have to be generated for responses are indeed
different. In most cases these markers can be generated with the
writeport function after termination of the stimulus object. Because
of this, these response markers will not be exactly in sync with the
actual response (i.e. it takes time in eprime to handle the response,
terminate the object and start the inline script). There are two
possible workarounds if the timing of response markers is very
critical: 1) use special hardware to detect responses and route it
digitally to both the eprime system and the second system. 2) apply an
off-line correction by using the stimulus-onset marker and the
(accurate) RT recorded by eprime to insert response markers at the
right places in the acquired data. However, my guess would be that the
touch responses are not detected very accurately anyway, so simply
using writeport would be sufficient in this case. (You could simply
estimate the delay by comparing the RT values recorded by eprime with
the time differences of the stim/response markers.)

best,
Paul

[David McFarlane]

At 4/15/2011 03:02 PM Friday, Paul Groot wrote:
>Hi Hank,
>
>The OnsetSignal-properties can only address one IO-port at the time
>(all 8 bits at the same time because there is no masking mechanism).

Hmm, couldn't one apply a mask using And or Or in inline code before
the stimulus object? E.g., if you wanted to apply only bits 0-2 of
some other input port, how about something like

'/------------------------------------------------------
' Using Consts in order to avoid "magic numbers" in code:
Const InPort as Integer = &h1234 ' whatever
Const OutPort as Integer = &h0378
Const OutMask as Integer = &h07 ' bits 0-2

StimText.OnsetSignalEnabled = True
StimText.OnsetSignalPort = OutPort
StimText.OnsetSignalData = ReadPort(InPort) And OutMask
'\------------------------------------------------------

Or, if one merely wanted to apply bits 0-2 without affecting any
other bits, how about

'/------------------------------------------------------
' Using Consts in order to avoid "magic numbers" in code:
Const OutPort as Integer = &h0378
Const OutMask as Integer = &h07 ' bits 0-2
Const OutData as Integer = &h05 ' for example

StimText.OnsetSignalEnabled = True
StimText.OnsetSignalPort = OutPort
StimText.OnsetSignalData = (ReadPort(OutPort) And OutMask) _
Or OutData
'\------------------------------------------------------