flood's input lag measurements

Everything about input lag. Tips, testing methods, mouse lag, display lag, game engine lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
flood
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 27 Nov 2016, 22:19

posting here for reference purposes:
flood wrote:Image
k so i made this circuit deadbug style, but non-inverting input on the first ad8655 is connected to a voltage divider (430kohm/560ohm) instead of ground. otherwise the circuit is unstable in complete darkness, i believe because the inputs aren't truly rail-to-rail
Image

step response:
Image

a lot of overshoot, coming from the first stage.
probably because the wizard didn't take into account the ad8655's input capacitance
adding a gimmick capacitor to the first stage removes the overshoot, for large signals at least. small signals still overshoot.

whatever good enough for now.

Image

4V step response:
Image
2V:
Image
0.5V:
Image
0.2V:
Image

flood
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 27 Nov 2016, 22:24

well that's convenient... new post on a new page.

response to a 1 pixel horizontal white line on a black background, on my crt:

top of screen
Image

center of screen
Image

bottom of screen
Image

love2d script/code for drawing the 1 line (in case i delete everything in the future again):
http://pastebin.com/rjBC37Jm

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 28 Nov 2016, 00:40

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
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 28 Nov 2016, 11:04

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
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 28 Nov 2016, 12:26

flood wrote: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
Posts: 648
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Post by Sparky » 28 Nov 2016, 20:00

spacediver wrote:
flood wrote: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
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 28 Nov 2016, 20:25

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
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 29 Nov 2016, 22:57

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.
spacediver wrote: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
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 29 Nov 2016, 23:32

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
Last edited by flood on 30 Nov 2016, 00:06, edited 1 time in total.

flood
Posts: 897
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 29 Nov 2016, 23:42

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

Post Reply