Refresh rate TFT

Tue Jul 5 19:27:00 UTC 2011

At 7/4/2011 06:42 AM Monday, you wrote:
>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?

As far as I understand, yes.  Of course, it would be best to further 
verify this with a photodector and oscilloscope.

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

Exactly.  Checking the "Response time" article at Wikipedia, I see 
that LCD response times are defined as the time for a pixel to go 
from black, to white, and back to black.  With response times defined 
as such, and LCD manufacturers claiming response times under 10 ms, 
we should be in good shape.  But I would not trust those numbers 
unless I measured it for myself, as I still wonder whether these 
claims actually include the white-to-black time.  Furthermore, some 
manufacturers use "repsonse time" to refer to a gray-to-gray-to-gray 
transition, which is a another whole matter.

As I said earlier, when we measured this ourselves several years ago, 
white-to-black took a *long* time.  As I recall, it was actually a 
biphasic decay, with a rapid early phase (say, down to 10% of 
baseline after 10-20 ms), with a long slow tail (over 100 ms to get 
closer to baseline).

As always, as scientists, we cannot take the word of equipment 
manufacturers (or even other scientists), it is incumbent upon us to 
measure our own equipment in our own labs.

Regards,
-- David McFarlane, Professional Faultfinder
"You got to test that lab equipment, You got to test it for yourself,
No one else can test it for you, You got to test it for yourself."
(Apologies to the Fairfield Four)

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