Refresh rate TFT

David McFarlane mcfarla9 at msu.edu
Fri Jul 1 14:10:57 UTC 2011


Tobias,

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.

That said, here is my take...

Nice test, and excellent question.  The problem arises because 
E-Prime uses two entirely different and incompatible definitions of 
"actual" duration:

(1) Actual duration = (OnsetTime of next visual object) - (OnsetTime 
of this visual object)
(2) Actual duration = (OffsetTime of this visual object) - (OnsetTime 
of this visual object)

So, if DurationError = (Duration (i.e., specified Duration)) - 
("actual" duration), then you have to know which definition of 
"actual" duration is used.

Because a visual object typically remains visible until the onset of 
the next visual object, most of us think of "actual" duration in 
terms of definition (1), and so would expect that definition to be 
used for calculating DurationError.  But if you think of that from a 
programming point of view, you will see the problem with 
that:  E-Prime cannot know the OnsetTime of the next object until, 
well, that object appears, and by that time it is too late to use the 
value in logging anything regarding the previous object.

So, E-Prime uses definition (2) for "actual" duration (see the 
RteRunnableInputObject.DurationError topic in the E-Basic Help 
facility), and your results follow.  (Don't take my word for this, 
log all the appropriate values and see for yourself that it does the 
calculation as I describe.)  IOW, at a (specified) Duration of 40 ms, 
the object OnsetTime occurs late (by 10 ms), but OffsetTime still 
occurs 40 ms later, thus DurationError = Duration - (OffsetTime - 
OnsetTime) = 40 ms, as measured (hmm, did you use Event or Cumulative 
timing mode?  your results do not look quite right for Event timing 
mode); but since the next object again appears 10 ms late, the 
"actual" duration of each object (according to definition (1)) 
remains 50 ms.  Follow?

Perhaps they could have chosen better terminology, although offhand I 
have nothing better to suggest myself .

One more note about measuring performance of LCD/TFT vs CRT.  It may 
casually seem that images appear and disappear from the display with 
high performance, however, several years ago when we measured LCD 
performance with a photodetector and oscilloscope we found that it 
took a *long* time for "off" pixels to return to baseline (some 
hundreds of ms, as I recall).  That may not matter for your studies, 
but it mattered to us at the time.  We have not done that measurement 
again, so don't know how modern LCDs perform; instead, we have just 
stockpiled our own stash of CRTs to provide for our future studies.

Regards,
-- David McFarlane, Professional Faultfinder


At 7/1/2011 05:54 AM Friday, you wrote:
>HI together,
>
>as CRTs are hard to get nowadays, we equipped our labs with tft
>screens. I wrote short and simple experiment to test the timing.
>basically, there are 4 display elements, alternating black and white
>background with nothing on it. As the refresh rate is 60 Hertz, I
>first set the duration to 50 ms (which is about 3 refresh circles).
>Prerelease is set on 20 ms.
>
>These are the results (duration, duration error, onset delay
>[according to logged data in results file])
>
>slide 1: 50, 0, 5
>slide 2: 50, 0, 0
>slide 3: 50, 0, 0
>slide 4: 50, 0, 0
>
>These are the results for a duration of 40 ms
>
>slide 1: 40, 0, 6
>slide 2: 40, 0, 10
>slide 3: 40, 0, 10
>slide 4: 40, 0, 10
>
>The first onset delay might be due to waiting for the next refresh
>circle to start. If the duration value matches the screen refresh
>rate, there seems to be no delay. If it doesn't (in this case, 40 ms),
>there is a delay that adds up to the next value that matches (50 ms).
>However, it is not clear to me how the duration arror can be 0 if
>refresh rate and duration value do not match. The screen should not be
>able to display something for 40 ms.
>
>Any ideas? Any hints for using TFTs or testing the timing of such
>screens?
>
>Thanks a lot! Cheers, Tobias

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



More information about the Eprime mailing list