Experiment Start timestamp

[David McFarlane]

> > Or you might program your EP experiment to delay until
> > the clock time reaches some round value, although once again I would
> > not expect that to be accurate down to the millisecond.
>
>That's what I've been doing so far, using the following inline code
>before our first stimulus:
>
>Dim thisSecond
>thisSecond = Time
>Do
>'Nothing
>Loop Until (thisSecond <> Time)
>
>Using this inline code, the stimulus is delayed until the "start of a
>new second" on "Time clock".

That's pretty much what I had in mind...

>No guarantee of a perfect millisecond precision obviously but it
>should be close enough.
>
>The inline code is placed right before the first stimulus of a trial,
>so each trial is "synchronized to the start of a second".

... but I would not use this to resync on each trial.  Instead, I 
would store the initial trial start time to a global variable, e.g.,

Dim thisSecond
thisSecond = Time
Do
     ' Nothing
Loop Until (Time > thisSecond)
g_t0 = Clock.Read  ' g_t0 defined in global User Script area

Thereafter, I would use Clock.Read to resynch each trial to a 
multiple of g_t0 (I leave this as an exercise), which would guarantee 
from this point on that everything is synched down to the 
millisecond.  Or, depending on your experiment design (fully timed 
vs. self-paced, etc.), judicious use of Cumulative timing mode might 
take care of subsequent synchronizations once you have the first one 
done (I'm not prepared to write this up now, but try a message board 
search for "Cumulative").

<snip>
>Instead of having a similar millisecond part, the syncronization seems
>to drift: I guess that this is the famous System Clock Drift that I've
>read about, although I do not get any warning about it from Eprime
>software (this is probably because its version is old - 1.2.1 I think
>- Clock hasn't got the System Drift Threshold property).

Hmm, I think that Clock.SystemTimeDrift taps into a similar but 
different issue, so might be irrelevant here.  But I do think that 
Time and Clock.Read use different hardware clocks, which might 
contribute to the problem.  All the more why I would just synchonize 
once to Time, and then use Clock.Read for everything else.

Just my $.02,
-- David McFarlane, Professional Faultfinder

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