flood's input lag measurements

[spacediver]

If I'm interpreting everything correctly, this means that a single line on your CRT can be detected within about 3-4 microseconds, correct?

Each square is 10 microseconds wide, and it looks like it takes 3-4 microseconds for the signal to be reliably detected above the background noise.

Not only that, but you'll be able to very precisely characterize the phosphor rise and decay function for different luminances and channels (R,G,B). That's pretty dope man.

[flood]

rise time should be effective instantaneous. in those images it isn't because of how long the beam is on when drawing out a line (roughly 1 / 125khz = 8us)

i'm also planning to use this setup to measure lcd's

[spacediver]

rise time should be effective instantaneous. in those images it isn't because of how long the beam is on when drawing out a line (roughly 1 / 125khz = 8us)

There seems to be periodic background noise. If the first pixel lights up during a trough of this baseline noise, then you would need to wait until the signal can be reliably distinguished against the crest of this baseline noise (unless you were to measure the gain itself, which would take a few samples to do).

[Sparky]

rise time should be effective instantaneous. in those images it isn't because of how long the beam is on when drawing out a line (roughly 1 / 125khz = 8us)

There seems to be periodic background noise. If the first pixel lights up during a trough of this baseline noise, then you would need to wait until the signal can be reliably distinguished against the crest of this baseline noise (unless you were to measure the gain itself, which would take a few samples to do).

Looks like that noise is aligned with the horizontal scan. Maybe the electron gun can't quite turn all the way off.

[spacediver]

Yea that makes sense, and it's a testament to flood's setup that it's able to detect that.

Also, from what I can tell from the code, the line only begins drawing from the left of the screen (I guess you'd call this HSync?). So doesn't that right there reduce the precision by a potential maximum 8 microseconds?

[flood]

periodic noise is because the circuit somehow picks up the crt's ~100khz radiation (i.e. from whatever electronics that sends the electron beam from left to right). i know this because i still get it even if i cover up the photodiode

the electron gun can turn basically all the way off (decreasing the brightness and/or g2 voltage can easily give a dynamic range >100000. spacediver and i measured this a few years ago). but anyway that's not relevant because i get exactly the same noise when i cover the photodiode.

Also, from what I can tell from the code, the line only begins drawing from the left of the screen (I guess you'd call this HSync?). So doesn't that right there reduce the precision by a potential maximum 8 microseconds?

the love2d code just draws a static image, so it always starts from the left.

i'm not sure completely how graphics card works, but for a crt which goes from a full black image to a full white image, the first pixel to do so could be either in the middle of the screen or always at the very left. i can take a picture and try to see.

because the setup responds faster when the first pixel to light up is in the middle of the screen rather than at the top or bottom, theres maybe a few us of inaccuracy from that factor. looking at my oscilloscope plots, it looks like a maximum of a 2-3us difference

[flood]

first measurements are in :d

my main pc is at my office at school so this is done on my old pc (i7 920, x58, gtx460)

https://docs.google.com/spreadsheets/d/ ... sp=sharing

code for dx9test (a minimal program that turns the screen white when you move the cursor right and black when you move the cursor left. left click to quit.):
http://pastebin.com/SpncbtGD

[flood]

current versions of teensy programs:
https://drive.google.com/file/d/0B5_qzx ... sp=sharing

use with pjrc's hid_listen: https://www.pjrc.com/teensy/hid_listen.html

lagtest measures the lag for dx9test (basically, move one pixel right, start a timer, wait until a signal is detected by the photodiode, record the elapsed time, move one pixel left, print the elapsed time in us to hid_listen)

printwidth prints how wide a pulse of light is in us. it can be used to check that a single line on the crt triggers the setup.


edit:
just thought of an idea for skipping the hid_listen part: just send the amount of latency as the number of pixels the cursor moves vertically. this makes things a bit easier. actually, maybe a lot easier

[Sparky]

Nice. What are you planning to test next?

I recently cleaned up and posted my test setup in the other thread, but I'm out of ideas on what to test with it:
http://forums.blurbusters.com/viewtopic ... =50#p22634

[spacediver]

periodic noise is because the circuit somehow picks up the crt's ~100khz radiation (i.e. from whatever electronics that sends the electron beam from left to right). i know this because i still get it even if i cover up the photodiode

Interesting.

i'm not sure completely how graphics card works, but for a crt which goes from a full black image to a full white image, the first pixel to do so could be either in the middle of the screen or always at the very left. i can take a picture and try to see.

Another way to do it would be to look at the oscilloscope plot over a few trials. If the onset of the rise-due-to-pixel-lighting-up always occurs at the same phase of the background radiation, then this indicates that the first pixel to light up is always at the same column of the screen (where first column indicates the far left). Based on your plots so far, it looks like it's at the same phase - at the trough of the background radiation, which I'm guessing corresponds to the first column.

Anyway, those left-right and up-down sources of variance are just uniform random variables, just like the variance due to a finite framerate, so with enough trials it will be easy to characterize the input lag. But I'm still curious about how you measure the actual onset of the pixel. Do you wait until the signal reaches a certain threshold and count that as the onset time? If so, and if it turns out that the pixel is actually "phase-locked" to the background radiation, then you can calculate the true onset time by subtracting the time it takes to go from trough of background to threshold of pixel signal.