Experiment Start timestamp

[EC]

> Hmm, you no doubt already know that SessionTime in the .edat file
> records the clock time for the start of the experiment, but I suspect
> you want something that records the clock time down the millisecond,
> whereas SessionTime goes only to the second.  That will be a tall
> order, because typically Windows does not keep clock time down to ms
> resolution, E-Prime only gets that by interposing DirectX
> commands.  E.g., you could use the Time$ function, but that goes down
> only to seconds (and is what SessionTime already uses anyway, as you
> can see by reading the generated E-Run code).
Yes, I was looking for millisecond precision or at least something
considerably smaller than 1 second so Time/Time$ and SessionTime
weren't enough.

> You might instead use some common signal to start both your EP
> experiment and your external device at the same time, and then count
> from there.
The external device has a long setup and is usually started before
Eprime runs because we need to use another software to check if the
device is well setup and recording - so we cannot have Eprime running
fullscreen with the experiment already.
However, you made me realize that there may be still some way to send
a signal and "restart" the external device when Eprime starts the
experiment. I'll check this route too.

> 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".
(This code can actually contains some mistakes as I'm just writing the
way I remember it, I do not have the code on this pc).

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".
On most runs infact I get this kind of values for my first stimulus
OnSetTime:
3514
7514
13514
16530
18514
22514

The milliseconds part is on most cases identical, or different just by
a few milliseconds (e.g. by a 16ms refresh), so this gives me
confidence that the synchronization code is indeed working, and with a
good precision too.

However, when doing some test runs I've noticed the following
happening:
3514
7500
9486
12465
15450

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).
This however does not happen on all runs and sometimes disappears
completely.

These tests were not done with the computer "properly setup" for time
precision (e.g. all other software stopped, no internet connection,
etc) so this might not be a problem if it doesn't happen when we start
Eprime "alone" on the system.
Anyway, even if this drift won't happen when the computer is setup
properly I think I'll investigate the problem some more as I'm curious
to know the cause of this drift (which looks quite linear when it
happens, not a simple "random missed tick" caused by CPU being busy).

Thank you for your reply!

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