Refresh rate TFT

[Tobias]

Thanks David for the detailed reply. If I understand you correctly,
you assume that, entering a duration value of 40 ms, you will always
have an actual duration of 50 ms (using the refresh rate of 60 Hz),
right?
Still, anoher question is, how long it physically takes for the pixels
to cease glowing even after, let's say a black screen, sets on. This
should be measured with external light sensitive hardware I guess...

Best,
Tobias


On 1 Jul., 16:10, David McFarlane <mcfar... at msu.edu> wrote:
> Tobias,
>
> Stock reminder:  1) I do not work for PST.  2) PST's trained staff
> takes any and all questions athttp://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.