These look to be a whole 1000 microseconds slower than your previous input lag measurements. The drop from 13000 fps to 6000 fps wouldn't account for this. Is it just because it's an older PC?flood wrote: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
flood's input lag measurements
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Re: flood's input lag measurements
are there any results of different monitors?
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Q83Ia7ta wrote:are there any results of different monitors?
flood wrote:i'm also planning to use this setup to measure lcd's
Re: flood's input lag measurements
not sure yet, probably just csgo again, and more carefully than last timeSparky wrote:Nice. What are you planning to test next?
the other motivation for the new setup is to measure rise/fall times of my lcd screens
well yes, but every component of the older PC is different, so "just" isn't the right wordspacediver wrote:Is it just because it's an older PC?
yup i thought about this, but probably it is easier to just flash the screen black/white at 1000fps or so and use a camera. at 800x600 it should be easily visible if a line is broken somewhere in the middlespacediver wrote: 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.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Cool, and how are you measuring the actual pixel onset?
spacediver wrote: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.
Re: flood's input lag measurements
(pixel isn't really the right word for crt's but i think we understand each other)
not sure exactly what you mean
as for how fast the phosphor is at lighting up, i think it should be instant (i.e. <1us)
for how long it takes for my thing to respond after the 1st "pixel" lights up, it's needs maybe 25% to 50% of a whole row of pixels to light up before it responds.
not sure exactly what you mean
as for how fast the phosphor is at lighting up, i think it should be instant (i.e. <1us)
for how long it takes for my thing to respond after the 1st "pixel" lights up, it's needs maybe 25% to 50% of a whole row of pixels to light up before it responds.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Yep, this is what I'm getting at.flood wrote:
for how long it takes for my thing to respond after the 1st "pixel" lights up, it's needs maybe 25% to 50% of a whole row of pixels to light up before it responds.
Let's assume that the lines always start from left side of screen. This means that the photodiode's response to the 1st "pixel" (or luminance transient) occurs at the trough of the periodic background signal. Yet, in order to reliably distinguish the response due to the luminance transient from the response to the ~100khz radiation, you have to wait until the signal rises to a certain magnitude before you can say "yes, this is a signal".
Look at the image below. The red line indicates a level at which you can reliably make a decision that the signal has occurred. The distance between the two green lines indicates the time between the moment this signal is detected, and the time that the luminance transient occurred.
If indeed the luminance transient is phase locked to the background radiation, then you can simply choose a threshold level (red line), and then subtract the offset (distance between green lines) to find the true pixel onset time.
How are you currently measuring the photodiode's response? Your circuit is always producing a signal, even when the screen is black. So what are you currently using as a criterion for the luminance transient? Are you choosing the peak of the response? If so, that's an additional ~8 microseconds you need to subtract. In fact, you don't even need to do the whole arbitrary threshold. Just assume that each line takes ~8 microseconds to draw, and that the photodiode's response peaks at the end of the line, and then subtract ~8 microseconds.
Re: flood's input lag measurements
oh, i'm not choosing anything
the atmega32u4 has a threshold voltage for its gpio pins. for instance if the voltage goes above 1.5V or so it's considered 1, if it goes below 1.4V or so it's considered 0. don't remember the exact numbers, but the datasheet has them
from my camera pictures, it does seem the lines always start from the left (for the gtx460 at least.)
the atmega32u4 has a threshold voltage for its gpio pins. for instance if the voltage goes above 1.5V or so it's considered 1, if it goes below 1.4V or so it's considered 0. don't remember the exact numbers, but the datasheet has them
from my camera pictures, it does seem the lines always start from the left (for the gtx460 at least.)
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
And I assume that the percentage of the line that needs to be drawn to cause 1.5V is variable, as it depends on both the brightness of the line (which might change from trial to trial), and, more importantly, which "row" on the screen the line is being drawn (e.g. it'll require less % of line when row is in middle of screen).flood wrote:oh, i'm not choosing anything
the atmega32u4 has a threshold voltage for its gpio pins. for instance if the voltage goes above 1.5V or so it's considered 1, if it goes below 1.4V or so it's considered 0. don't remember the exact numbers, but the datasheet has them
Perhaps you could expand the circuit to include a component that directly measures the voltage coming off the photodiode, stores that information, and then you can write code that finds the timestamp that peak voltage occurs, and then you can subtract the ~8us from that timestamp to find the actual time that the line started drawing.
neatflood wrote:from my camera pictures, it does seem the lines always start from the left (for the gtx460 at least.)
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: flood's input lag measurements
Hello flood,
Which microcontroller are you using at the moment?
I've been testing several microcontrollers. Older Arduino has an average of 4.1ms USB lag, while some newer microcontrollers have only 0.19ms USB lag, assuming a microcontroller that supports USB buffer flushing. (Directly plugged into a USB3 port). I am trying to find the cheapest microcontroller capable of <0.20ms USB lag for some experiments.
Which microcontroller are you using at the moment?
I've been testing several microcontrollers. Older Arduino has an average of 4.1ms USB lag, while some newer microcontrollers have only 0.19ms USB lag, assuming a microcontroller that supports USB buffer flushing. (Directly plugged into a USB3 port). I am trying to find the cheapest microcontroller capable of <0.20ms USB lag for some experiments.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!