Work In Progress Perfect setups (TV/monitor, console, capture device)

[aerokarp]

Slice~
Sorry if that sounded a little critical. I was thinking that it was the whole setup that had nanoseconds of lag (which doesn't really make sense now that I think about it), not the display, so I was confused.

 

[Slice~]

A aerokarp Every kind of criticism and incredulity is appreciated as long as it helps developing the whole issue.
Discussing the topic and making things clear just helps at creating a solid final outcome

 

[aerokarp]

This is unrelated, but there's a CVC 200 on Amazon for $50 right now.

 

[clickclack]

I'm looking to acquire a few more setups and I was just wondering if there was any opinion on slim CRTs like this one. There's one on craigslist right now and it would sure make bringing setups to tourneys/houses a lot easier. :>

Also to note I did a few google searches on it and there were a few sites that reported it as lag free but I'm not sure if I can trust those

 

[Kadano]

I'm looking to acquire a few more setups and I was just wondering if there was any opinion on slim CRTs like this one. There's one on craigslist right now and it would sure make bringing setups to tourneys/houses a lot easier. :>

Also to note I did a few google searches on it and there were a few sites that reported it as lag free but I'm not sure if I can trust those

I don't have experience with these, but just from the looks I'd stay away from them since they might lag. If I was you, I'd bring a console to the seller's place and test the CRT before buying.

 

[StabbyMcKniferson]

So I've been in talks with jmlee337 working on the same sort of oscilloscope measurements. He has been an enourmous help and I really appreciate all of the time he spent talking to me about this. I bought the Extron 405 USP as well, and long story short I ended up measuring the device to have 8ms lag. I also measured the photoresponse time of a CRT VGA monitor and found a lag <1us.

Equipment: Extron USP 405, ns response time photodiode, oscilloscope.

In this link I post the data for thwo different things: http://imgur.com/a/Qqc3j

The first trial was just measuring the processing lag of the USP 405. It seems like it's programmed to output a 8ms delayed signal regardless of the setting you have it on. If you change settings and watch the oscilloscope, it goes from an almost no delay signal, then every second it moves the delay more and more until it hits the 8ms mark. It does not matter the type of processing that it does (upscaling, transcoding, size and zoom correction) all result in an 8ms delay. If you set it to the NTSC signal, and splice your luminescence signal from your Wii, you can make the delay almost nothing. But this downscales it to 480i and makes it unusable on CRT monitors.

Then I hooked up my photodiode to the oscilloscope and used the green signal coming out of the RGBHV ports. When you compare those two, it's easy to see that there is almost no lag for this CRT monitor. Sometime later this night or tomorrow I will find out the model numbers. I have another CRT monitor that I will try as well. At the maximum the input lag on the TVs was around 1us. The TVs don't produce the quanitity of light needed for a shorter time measurement though. These photodiodes are meant for specific applications so I don't want to overclock their voltages.

I'm getting the right BNC cables and RCA adapters. I plan to take my photo response measurement to my local Melee community. I would like to create a list of monitors and lag times associated with them. I don't know how accurate Armada's claim is, but it would be nice to know!

EDIT: A couple of details since last time. I'm not super familiar with forum posting so I assume editing my post is the correct thing to do since no one has posted after me. After seeing the larger conversion time of the USP 405, I purchased a startech CPNT2VGAA and ran the same tests. I can confirm jmlee337's previous measurement of lagless on this device. I have included the results in the album here: http://imgur.com/a/zjjv7

It does weird things to the HSync, but the output signal looks quite crisp and there is no lag. I also included a photodiode response measurement. It's for the same CRT monitor as last time (ViewSonic Graphics Series G70f) so it's a little redundant, but really clearly shows how little lag there is betweeen output of Wii and photons from screen. I have now received permission from my lab to take both the photodiode and the oscilloscope to a melee weekly, so when I have time to go to the next one I will record more data on CRTs.

 

[jmlee337]

I found this neat subreddit with a list of broadcast CRTs: https://www.reddit.com/r/crtgaming/wiki/speclist
It adds some 480p capable monitors

• BVM-A32E1WU
• BVM-A24E1WU
• BVM-A20F1U
• BVM-A14F5U
• BVM-D32E1WU
• BVM-D24E1WU
• BVM-D14H1U/H5U

to the list of ones we already know about

• Sony PVM14L5
• Sony PVM20L5
• Sony PVM20M7MDE
• Sony BVM-D20F1U
• Sony BVM-F42U
• Sony BVM-1911
• JVC V1700CG
• JVC V1710CG
• JVC V1900CG
• JVC V1910CG
• Panasonic BT-H1700

 

[StabbyMcKniferson]

So I have some more photoresponse data from CRTs around the lab. I was able to measure 3 more VGA adapted CRTs and one LCD. I will eventually make a larger table with all of this data including the regular CRTs once I go to a weekly, but until that point here is some data:

VGA-CRT
Mitsubishi - Diamond Plus 73 (DiamondTron NF): 1.6 us
Sony - CPD-2003GT: 0.95 us
Gateway - EV700: 1.2us
Viewsonic - Graphic Series G70f: 1.3 us

LCD
Acer - AL1715: >14.8 ms
Dell - 1707FPt: unknown.

The Dell one was weird. It was outputting three signals in the course of one VSync signal. I thought it was a color thing so I dropped out Red and Green so only Blue was present, but the Blue still fired three times over the course of the signal and there was no difference in intensities. I checked the frame rate the monitor said and it reported to be 60Hz. So I'm not quite sure why it would fire three times in one frame. (VSync happens about every 16.7 ms, and this was firing once every 6ms). Maybe the LCD would look too dim without a reupping of the photons coming out. But still, there were too many signals to be able to tell which one was the correct one. It felt laggy to play on, but I had no real idea of exactly how much.

All of the LCDs could be more than one cycle off (so it could possible be 14.8+16.7), but that's hard for me to check reliably. You would need a more information heavy and slower method than mine. So what I am reporting here is the fastest maximum speed. The CRTs are unlikely to be a full cycle off when the variation from monitor to monitor is so slight. Each of them would then have to be exactly 16.7 ms + ~1us and that doesn't seem particularly likely. Especially because they would need a place to store the video data, and they don't have that.

When I do the whole table, I will also post images of the oscilloscope and TVs as well. Just so that everyone can see what I've been doing.

Edit: The LCD signal that I saw was most likely a 200Hz (5ms) refresh rate. So that's why I couldn't see anything. I would need to have a signal generator that did black/white oscillations to be able to accurately test it. I could probably go to FD and let the background change a bunch though. I might try that if I get tired of waiting for the next weekly.

 

[Kadano]

On a more positive note on Extron oscilloscope measuring results, I confirmed that the Extron MVX series is truly lagless today. I compared the green pin levels of a frame's first line (easy to tell because it was the first frame of a black to white change initiated through develop mode visibility toggle).
Input 1 had the green pin from Gamecube DAC VGA cable → Extron MVX 88 (output 8) → Rigol DS1054Z.
Input 4 had the green pin from Gamecube DAC VGA cable → Extron MVX 88 (output 7) → Extron MVX 84 → Rigol DS1054Z.

The difference was 10 nanoseconds. I also made sure to confirm beforehand that all the MVX 88's outputs are truly synced, and compared the output 7 with output 8 directly. The delay between these was 5 nanoseconds or less (at such low timescales and amplitudes, the error within the analog curve was substantial, so it was hard to tell where that line's level began).

So the MVX series is definitely lagless and now even more recommended to anyone who wants to route a number of high-bandwidth / high-quality video signals, especially when using a number of consoles and CRT monitors / recording stations for lagless play.

 

[Kadano]

So I have some more photoresponse data from CRTs around the lab. I was able to measure 3 more VGA adapted CRTs and one LCD. I will eventually make a larger table with all of this data including the regular CRTs once I go to a weekly, but until that point here is some data:

VGA-CRT
Mitsubishi - Diamond Plus 73 (DiamondTron NF): 1.6 us
Sony - CPD-2003GT: 0.95 us
Gateway - EV700: 1.2us
Viewsonic - Graphic Series G70f: 1.3 us

Thank you for doing this. I'm still waiting for my photodiodes to arrive and will measure all my CRTs when I receive it (7 VGA PC monitors, 1 Sony PVM and 8 CRT TVs).
It looks like, as I had suspected, VGA CRT monitors are the most reliably lagless displays for Melee, with all results so far between 0.7 and 2 µs. Their picture quality is also great, I don't think that the small improvement on Sony PVMs is worth the major increase in price.

With frequent reports of laggy CRT TVs, I continue to advocate people transitioning to VGA setups. Especially since Wii VGA cables are only 20$.

Edit: The LCD signal that I saw was most likely a 200Hz (5ms) refresh rate. So that's why I couldn't see anything. I would need to have a signal generator that did black/white oscillations to be able to accurately test it. I could probably go to FD and let the background change a bunch though. I might try that if I get tired of waiting for the next weekly.

LCDs usually use pulse-width modulation (PWM) to set a brightness level, which basically frequently turns the backlight on and off again. A 200 Hz rate is within the spectrum used for PWM, although iirc modern LCD monitors usually use higher rates between 500 and 2000 Hz. (Some newer LED-backlit LCDs even don't use PWM at all, which helps with lowering eye strain, and I expect lag measurement too.)

When I test lag, I usually use the following setup as high-contrast video signal:
1. Develop mode (non-20XX, Magus iso for example) on Yoshi's Story, game paused
2. Game visibility toggled to pure black (with X+↓ on the D-pad a few times), camera panned so that no characters are within the camera field
3. Now I press X+↓ one more time and then press the hold button on the oscilloscope about half a second afterwards.

This way there is a very strong pure black to very bright scene change that can be recognized on the color levels very easily, and is also easy and quick to repeat (with a couple more X+↓ presses). I would expect that this kind of brightness level should be recognizable on your Dell LCD too, even with its PWM interfering?

But maybe you are using something similar with PC-generated video already (?).

On a related note, I have tested Wii VGA cables and found both the "official" Mayflash ones and the "fake" knockoff ones to have zero lag.
Blue is input (Y), purple is output (Green):

Official Mayflash Wii VGA cable:


More measurements and writeups will follow.

 

[PrettyCoolGuy]

Hey Kadano , if I already have a knock off Wii VGA cable, would an X-Capture-1 or similar Yuan external recording device be able to pass through to a CRT monitor and record with no issues?

 

[Kadano]

Hey Kadano , if I already have a knock off Wii VGA cable, would an X-Capture-1 or similar Yuan external recording device be able to pass through to a CRT monitor and record with no issues?

I just tested this, and I do get a good picture when connecting the knockoff cables directly to my StarTech PEXHDCAP (Yuan SC500N1/DVI). It looks quite nice even.
The image below isn't 100% true image ratio (576x480 instead of 584x480¹), but its pretty close, so it should be enough as reference.

¹Video width must be multiple of 8 in the Yuan driver settings. The next closer setting would be 648x480, which would give an active resolution of 592x480, which is equally far from 584 horizontal as the 640x480 setting (which gives 576 horizontal active for some reason).

 

[aerokarp]

I'm not sure how this will compare to Extron CVC 200/300's video quality, but this could be promising. Also, I think I'm going to try to mod my GC for RGBHV output, so if that goes well I can show the process and try to help other people do the same.

 

[StabbyMcKniferson]

Long post incoming: Primarily about the difference between overscan and input lag


The method for evaluation that I used for input lag testing of the TVs involved three main components other than the TV. 1) The signal coming from the Wii/GC which was split off one going to the oscilloscope one going to the TV 2) The oscilloscope used to make the measurements of a change in voltage over time and 3) The photodiode which would detect light hitting the diode with a change in voltage.



What this method tests is the time it takes between a signal being sent from the Wii/GC and compares it to when the Photodiode first sees light. But what that time represents depends on two main factors: Overscan and Input lag.


Input lag is the answer to the question: just how long does it take the TV to display a given piece of information? It has to take a change in voltage, move an electron gun, and fire. Does this take a long time? This was the main goal of my measurements but this ended up being a little bit more complicated because of the next part.


Overscan has to do with the amount of the image that is actually displayed. On older TVs, especially CRTs, the whole image isn’t displayed on the TV. The TV will cut off some image at the top, bottom, left and right. This is because there were a lot of CRT manufacturers which made very different products, and so the NTSC signal was developed to accommodate most use cases. NTSC signal usually gives a larger image than you need for your media (TV or otherwise) and allows for some CRTs to chop off a bit here and there. So if you tell a CRT to display information on lines 0-479, some CRTs will start displaying the information of line 0 at the top of the screen, and some CRTs will display line 4 as the top of the screen.


It’s important to note that the information is displayed at the same rate and with the same speed, but that there is less of the information being displayed. For TVs that display line 15 as the top of the screen, this information on line 15 will reach the screen in the same time that it takes for a TV that has no overscan to display line 15. In essence the only difference between a TV with overscan and one without, is how much of the image do you see, not how fast do you see it. More overscan means you see less image.


So what was I able to measure when I went to the local? I was able to measure (mostly) overscan. I measured the time between the first signal that told the CRT to display an image (line 0) and when the photodiode recorded light from the CRT. If the first line displayed is line 0, then I can accurately measure the input lag associated with the TV. I look for the time on line 0 and then I measure the time it takes for line 0 to display. But because of overscan, that’s not quite how it looks. Instead what happens is I look for the time on line 0 and then I measure the time it takes for ANY line to display. If it’s a line other than line 0, then I am unable to measure the input lag directly. Now I am measuring the time between when line 0 is sent, and when line 15 is displayed (or whatever line). This is the result of overscan and will increase the measured “lag” by 63.55 us per line that is cut off by the CRT.

The lag that I measured is likely due to overscan. This is likely the case because of two factors. The first is that I was able to measure several TVs with no overscan (I now have measured 6 TVs with no overscan), and for those TVs, the time delay is always <10us. The second is that the lag measured on TVs with overscan is a multiple of 63.55us. This is because a full line (there are 480 visible lines per frame), takes 63.55 us to display. So when I measured a time delay of 127 us, this is unlikely to be a TV taking 127 us to display an image and more likely to be a TV skipping the first two lines, and displaying the third. If it were truly just input lag, it would be unlikely that for all of the TVs, each of the measured lag was a multiple of 63.55 (+/- 10 us). Furthermore, it is apparent from the images of the oscilloscope that the increase in photodiode signal come at the same interval and matches up in phase with the GC/Wii composite HSync. Even with measurements that I set the cursors closer to the middle of a HSync phase, the actual photo response signal is much closer to the correct phase than I measured (I was trying to measure from onset of light, but perhaps I should have just done first onset of strong light).

If the delay *is* caused by overscan, then the input lag can be measured by comparing the increase in photodiode signal to the signal from the Wii/GC that immediately precedes it. For the one TV that I did measure this value it was less than 10 us lag. If it is not caused by overscan (which I believe to be unlikely), then the maximum input lag that I measured was on the order of 1 ms. While long for a CRT, it is not long for monitors as a whole. And arguably, unnoticeable by human perception.

What does this mean for the input lag testing of CRTs?

For right now I think it’s a fair assumption to say that the CRTs that I measured are lag less. The maximum total lag (ignoring overscan as a factor) is less than 1ms. But it also means that in order to measure CRT input lags directly that overscan must be ruled out as a factor. I have a signal generator which will insert blank lines above the image of a screen (which in effect pushes the actual image down into the visible area). This can prevent overscan from being a factor in lag testing, but it is a large piece of equipment. I think eventually I would like to test the TVs via this method, but getting the time off required to go do this measurement will likely take a long time. This would be the only way to know for sure that the input lag comes from overscan and not a slow TV. But in the meantime, even in the worst case scenario it can be reasonably argued that all of the TVs that I tested have an unnoticeable amount of input lag.


So for the moment, I think that it is safe to say that the CRTs I measured (and likely, most CRTs) are unnoticeably lag less, and given retesting that they may be even more unnoticeably lag less.


Finally it’s important to thank the TO of my local event, and all of the people there who let me measure their TVs. The TO brought a whole bunch of his own TVs and those make up the bulk of these measurements. Because I am a private person, I am not naming my region or the TO, but it is important to give credit where credit is due. Below is the measurements of the TVs that I took at that local and a link to the imgur albums of pictures of the raw data. I have also included the photoresponse data from my last measurements of the VGA-CRTs in a separate imgur album.

Konka - K2098U: <2ms

Magnavox - 20MT1331-17: 656 us (10 lines)

Orion - TV1333: 389 us (6 lines)

Quasar - VV-1330SA: 661 us (10 lines)

Sanyo - 0813310: 187us (3 lines)

Sylvania - W-4913LT: 816 us (13 lines)

Sylvania - Blurry: 959 us (15 lines)

Sylvania- 6413TG: <4us

Sylvania - 6420FF (2): 790 us (12 lines)

Sylvania - 6420FF: 252 us (4 lines)

Toshiba - 24AF46: 255 us (4 lines)

Toshiba - 13A23: 767 us (12 lines)

Zenith - TVBR1342Z: 646 us (10 lines)


http://imgur.com/a/bY5Ue - CRT VGA album

http://imgur.com/a/s3hal - CRT Local Album

 

[jmlee337]

Long post incoming: Primarily about the difference between overscan and input lag


The method for evaluation that I used for input lag testing of the TVs involved three main components other than the TV. 1) The signal coming from the Wii/GC which was split off one going to the oscilloscope one going to the TV 2) The oscilloscope used to make the measurements of a change in voltage over time and 3) The photodiode which would detect light hitting the diode with a change in voltage.



What this method tests is the time it takes between a signal being sent from the Wii/GC and compares it to when the Photodiode first sees light. But what that time represents depends on two main factors: Overscan and Input lag.


Input lag is the answer to the question: just how long does it take the TV to display a given piece of information? It has to take a change in voltage, move an electron gun, and fire. Does this take a long time? This was the main goal of my measurements but this ended up being a little bit more complicated because of the next part.


Overscan has to do with the amount of the image that is actually displayed. On older TVs, especially CRTs, the whole image isn’t displayed on the TV. The TV will cut off some image at the top, bottom, left and right. This is because there were a lot of CRT manufacturers which made very different products, and so the NTSC signal was developed to accommodate most use cases. NTSC signal usually gives a larger image than you need for your media (TV or otherwise) and allows for some CRTs to chop off a bit here and there. So if you tell a CRT to display information on lines 0-479, some CRTs will start displaying the information of line 0 at the top of the screen, and some CRTs will display line 4 as the top of the screen.


It’s important to note that the information is displayed at the same rate and with the same speed, but that there is less of the information being displayed. For TVs that display line 15 as the top of the screen, this information on line 15 will reach the screen in the same time that it takes for a TV that has no overscan to display line 15. In essence the only difference between a TV with overscan and one without, is how much of the image do you see, not how fast do you see it. More overscan means you see less image.


So what was I able to measure when I went to the local? I was able to measure (mostly) overscan. I measured the time between the first signal that told the CRT to display an image (line 0) and when the photodiode recorded light from the CRT. If the first line displayed is line 0, then I can accurately measure the input lag associated with the TV. I look for the time on line 0 and then I measure the time it takes for line 0 to display. But because of overscan, that’s not quite how it looks. Instead what happens is I look for the time on line 0 and then I measure the time it takes for ANY line to display. If it’s a line other than line 0, then I am unable to measure the input lag directly. Now I am measuring the time between when line 0 is sent, and when line 15 is displayed (or whatever line). This is the result of overscan and will increase the measured “lag” by 63.55 us per line that is cut off by the CRT.

The lag that I measured is likely due to overscan. This is likely the case because of two factors. The first is that I was able to measure several TVs with no overscan (I now have measured 6 TVs with no overscan), and for those TVs, the time delay is always <10us. The second is that the lag measured on TVs with overscan is a multiple of 63.55us. This is because a full line (there are 480 visible lines per frame), takes 63.55 us to display. So when I measured a time delay of 127 us, this is unlikely to be a TV taking 127 us to display an image and more likely to be a TV skipping the first two lines, and displaying the third. If it were truly just input lag, it would be unlikely that for all of the TVs, each of the measured lag was a multiple of 63.55 (+/- 10 us). Furthermore, it is apparent from the images of the oscilloscope that the increase in photodiode signal come at the same interval and matches up in phase with the GC/Wii composite HSync. Even with measurements that I set the cursors closer to the middle of a HSync phase, the actual photo response signal is much closer to the correct phase than I measured (I was trying to measure from onset of light, but perhaps I should have just done first onset of strong light).

If the delay *is* caused by overscan, then the input lag can be measured by comparing the increase in photodiode signal to the signal from the Wii/GC that immediately precedes it. For the one TV that I did measure this value it was less than 10 us lag. If it is not caused by overscan (which I believe to be unlikely), then the maximum input lag that I measured was on the order of 1 ms. While long for a CRT, it is not long for monitors as a whole. And arguably, unnoticeable by human perception.

What does this mean for the input lag testing of CRTs?

For right now I think it’s a fair assumption to say that the CRTs that I measured are lag less. The maximum total lag (ignoring overscan as a factor) is less than 1ms. But it also means that in order to measure CRT input lags directly that overscan must be ruled out as a factor. I have a signal generator which will insert blank lines above the image of a screen (which in effect pushes the actual image down into the visible area). This can prevent overscan from being a factor in lag testing, but it is a large piece of equipment. I think eventually I would like to test the TVs via this method, but getting the time off required to go do this measurement will likely take a long time. This would be the only way to know for sure that the input lag comes from overscan and not a slow TV. But in the meantime, even in the worst case scenario it can be reasonably argued that all of the TVs that I tested have an unnoticeable amount of input lag.


So for the moment, I think that it is safe to say that the CRTs I measured (and likely, most CRTs) are unnoticeably lag less, and given retesting that they may be even more unnoticeably lag less.


Finally it’s important to thank the TO of my local event, and all of the people there who let me measure their TVs. The TO brought a whole bunch of his own TVs and those make up the bulk of these measurements. Because I am a private person, I am not naming my region or the TO, but it is important to give credit where credit is due. Below is the measurements of the TVs that I took at that local and a link to the imgur albums of pictures of the raw data. I have also included the photoresponse data from my last measurements of the VGA-CRTs in a separate imgur album.

Konka - K2098U: <2ms

Magnavox - 20MT1331-17: 656 us (10 lines)

Orion - TV1333: 389 us (6 lines)

Quasar - VV-1330SA: 661 us (10 lines)

Sanyo - 0813310: 187us (3 lines)

Sylvania - W-4913LT: 816 us (13 lines)

Sylvania - Blurry: 959 us (15 lines)

Sylvania- 6413TG: <4us

Sylvania - 6420FF (2): 790 us (12 lines)

Sylvania - 6420FF: 252 us (4 lines)

Toshiba - 24AF46: 255 us (4 lines)

Toshiba - 13A23: 767 us (12 lines)

Zenith - TVBR1342Z: 646 us (10 lines)


http://imgur.com/a/bY5Ue - CRT VGA album

http://imgur.com/a/s3hal - CRT Local Album

Are you accounting for even/odd line timing variations due to interlacing?

 

[StabbyMcKniferson]

Are you accounting for even/odd line timing variations due to interlacing?

That's a really good point. It wasn't something that I was explicitly thinking of at the time, but the way that I collected the data should have accounted for that. The triggering of my oscilloscope was based on the light source from the photodiode, and so I would manually trigger it and examine the signal. I would do each TV about 10 times and use the fastest consistent signal time. Because odd fields would give a longer time this would result in me only using the even fields.

Going back and looking at the photos I took, I can see that in the photos that show the first signal, none of the scans used are odd as the onset of the video signal for each TV starts at the beginning of the 63.55us phase as opposed to in the middle (or later) which would happen for an odd field. Because I had to choose which scans to keep, in the ones that don't show the first signal, it's unlikely that I would have used an odd scan for two reasons: 1) it would have looked weird to me with the actual signal starting in the middle of where I would have expected the video signal to start and 2) it would have resulted in a slower speed. At the maximum it would have resulted in a 40us additional delay (because I started measurements from the rise of the signal off from black in the active video area).

 

[Kadano]

You could use develop mode on Dream Land 64 or Yoshi's Story¹ and set the visibility toggle (X+↓) to black. This way, you can move the camera around freely (assuming you aren't using 20XX, which deleted non-pause develop camera controls) so that the characters are in the middle of the screen (or at the bottom even), with pure black above. This should allow for eliminating the error from the overscan variance, and also make the interlacing variation irrelevant.

The only problem might be telling which pixel signal on the oscilloscope is the first active one. But it should still be possible, I think.

¹At least BF, PS and FD have background animations that can't be disabled completely through develop toggles alone.

 

[StabbyMcKniferson]

I like that idea. That's a clever way of solving two problems. I could then hold the photodiode at the colored section. To be honest, the composite signal is quite easy to interpret on an oscilloscope and it's easy to tell large changes in intensity just by looking at the waveform.

For me, I think the easiest way for me would be to use the signal generator though since I already have one. That way I can also measure exactly the lines of overscan and doesn't require a modified ISO. It also has the added benefit of synced multiple outputs so that I can just trigger directly off of Vsync without having to worry about triggering off of the photodiode (which is a pain and requires changing the trigger level depending on the brightness of the TV I am examining). As for interlaced, as long as I am consistent with the measurements, I don't think it will matter very much. Especially when I get to the single us testing it will be very obvious whether I am measuring to the middle of a line or at the beginning.

 

[Phil Matic]

So I was fortunate enough to secure a CRT TV made by Toshiba that has 480p Progressive Scan and seems to be pretty good in terms of lag.

In all honesty, are PVMs/BVMs worth it? Is the quality better than CRT TVs that can do 480p as well? I just really like the TV I have right now because I can connect many more consoles to it. But of course, I want to hear what makes PVMs and BVMs so great.

 

[Kadano]

So I was fortunate enough to secure a CRT TV made by Toshiba that has 480p Progressive Scan and seems to be pretty good in terms of lag.

In all honesty, are PVMs/BVMs worth it? Is the quality better than CRT TVs that can do 480p as well? I just really like the TV I have right now because I can connect many more consoles to it. But of course, I want to hear what makes PVMs and BVMs so great.

From what I've been reading, 480p CRT TVs lag rather often – your TV seems to be an exception. Also, the tubes on PVMs and BVMs are most certainly of a higher quality with better calibration. But it won't be nearly as night and day as 480i CVBS vs 480p YPbPr.

Being able to adjust brightness, contrast and saturation with potentiometer knobs on the fly can be more useful than you'd think.

Whether they are worth their money entirely depends on your priorities.

 

[Kadano]

CRT lag
Introduction and history
Over the years, there have been quite a few reports of CRTs that do in fact lag. One somewhat prominent example was Armada's Genesis 1 pools set against WhatIsFear in 2009. The first match was played on a CRT TV that, according to @Armada, lagged. TOs and other players were consulted, but whether they confirmed the impression of lag or not is controversial.
According to @ajp_anton, a technical guru, yet expected to, as a fellow Swede, to be biased in Armada's favor, reported here on Smashboards that everyone agreed that the TV lagged.
On the other hand, @WhatIsFear told me in a Twitter direct message conversation that all TOs said that the TV was fine and did not lag at all.

Regardless of how the TOs really reacted, this anecdote tells us that CRT lag is a problem that should be seriously evaluated and addressed and needs a standardized way to be dealt with.

Technical setup
As a follow-up to StabbyMcKniferson 's recent post in this very thread, I used a similar set of tools to measure the delay between video signal and photon output.

Devices used:
1. Rigol DS1054Z oscilloscope (4-channel, ~400€)
2. Vishay BPW34 Silicon Photodiode (since sold out, cheapest other offer here. The photodiode was connected with its + pin to 5V (from Wii USB through a breadboard power adapter) and with its − pin to scope probe (through breadboard).

Spoiler: Photo of scope

Reference signal was a complete black-to-white scene change, which is very easy to set the oscilloscope to trigger for, since during the black scene, the video levels always stay below the point they immediately reach as soon as the first bright pixel is sent.
This is done by using a Melee iso with debug menu access and not 20XX (as camera control is deleted from 20XX, making it impossible to pan the camera properly). DBMODE is set to develop, stage to STORY (Yoshi's), environment visibility is set to black (with four presses of R+↓ on D-pad) and interface visibility is set to pure black (with one press of X+↓). The camera is shifted to the very top (with → on D-pad and C-stick ↑).
At this point, pressing X+↓ another time will immediately cause a scene change from pure black to pure white.

In my scope screenshots here, I used input 3 for the video input and trigger. Input 1 is the photodiode connected to 5V.

For the VGA CRT PC monitor tests, I used a Gamecube with a VGA DAC cable that was run through an Extron MVX 88 matrix switch (previously proven to be lagless (<10 nanoseconds) and synced (<5 ns). One VGA output was connected to a Sony GDM-F520 (reference class graphical CRT monitor) and a different output was connected with a VGA-5BNC cable to the scope (green signal was used).

For all CRT TV tests, I used a Wii's composite video cable that was connected to CRT and scope with a simple passive splitter.

The photodiode was put inside a small breadboard connected to the main breadboard with jumper wires. The small breadboard was put in front of the CRT at its northwest corner.
Doing so notably did not compensate for the overscan problem StabbyMcKniferson explained in his post here before. On the two CRT TVs that had a few lines delay, expected to stem from overscan, I also ran a second test, where I positioned the photodiode at the vertical middle of its left side, where I also showed a light gray platform (to be used as the first vertical bright color information to be picked up by the photodiode) that was toggled on with X+↓ too.

Spoiler: Two photos

Expectations and lag classes
Due to the imperfect positioning of the photodiode and possible overscan, it's expected that there will be some error range in when the photodiode first reads full white level. This delay is expected to be in the range of up to 100µs (three 480p lines).

In the table below, "min. amount of lag" will be the lowest amount of time after scope trigger after which there is a notable brightness increase in the photodiode levels. "Max. amount of lag" is the time it takes until the photodiode levels have reached 100%.
I expect the "true lag" to usually be much closer to the former than the latter, but with my current set of equipment and process, I can only prove that the true lag is not more than the "max. amount of lag" in the table.

Every amount up to 1 ms (1000 µs) is negligible and should be classified as "lagless". In fact, in CRTs, delays in that order of magnitude are most likely only due to overscan and inaccuracies of my process.
For some of the TVs, I re-did the test using a black-to-white scene change that only occurs at about the vertical middle of the screen, so that I can compare video signal levels to photon output without overscan interfering. For these, I added the respective screenshots and changed the max. amount of lag to the respective delay.

Delays from 2 ms to 5 ms should be fine for playing, but I think the terms "nearly lagless" or "low lag" are better to use for these.

Every amount of lag that exceeds 5 ms should not be considered free of lag. 5-10 ms should be classified as "medium lag" / "it lags a bit", and everything above 10 ms as "heavy lag" and downright unplayable.


Measurement results

CRT type|Brand / model|Photo of CRT|Lagless?|Min. amount of lag|Max. amount of lag|Scope screenshot|notes
PC monitor|Sony GDM-F520|

| Yes |1 µs|30 µs|

|
Broadcast monitor| Sony PVM20M7MDE|

| Yes (480p only, lags on 480i)|1 µs|50 µs|

|Lags 8 ms when fed 480i from frame rate doubling, no lag on 480p though, where no doubling happens
Flat late-era CRT TV|Panasonic TX-29E40D/M|

| No, heavy lag |25 ms|25 ms|

|Seems to do frame rate doubling
Late-era CRT TV|Samsung CW-28C75V|

| No, medium lag |8.3 ms|8.3 ms|

|Seems to do frame rate doubling
16:9 CRT TV|Sony KV-28WX1D|

| Yes |? µs|330 µs|

|Seems like 5 lines of overscan
4:3 CRT TV|Sony KV-X2101D|

| Yes |? µs|340 µs|

|Seems like 5 lines of overscan
Small 4:3 CRT TV|Toshiba 14N21DB|

| Yes |~10 µs|144 µs|

|Seems like 15 lines of overscan
4:3 CRT TV|Daewoo|

| Yes |~50 µs|364 µs|

|Seems like 6 lines of overscan

Interpretation
Most of the CRTs I tested have under a millisecond delay (1/16th of a frame) to display the first line of new frame video information, and that is only due to overscan delay. For the tests I did with mid-frame black-to-white scene change, the delay was much lower and easily below 100 µs.

The only CRTs that did lag are late-era ones that seem to have laggy post-processing; frame rate doubling, to be precise. I theorized before that this feature necessarily introduces a minimal amount of lag of 8.3 ms, which was confirmed by the Samsung CRT lagging exactly that amount (and the Panasonic even more).
The explanation for this is that to double the frame rate, the CRT needs to wait for half a full frame until it starts shooting its buffered data, so that it receives new video information just by the time it "runs out" of buffer lines.
Effectively, only the first line of the Samsung CRT has 8.3 ms of lag. In the middle of the vertical screen, I expect it to only be delayed by 4.15 ms, and at the bottom the delay would be less than 1 ms.

Very strange is why the Panasonic CRT TV adds an entire additional frame to the necessary 8.3 ms frame-doubling delay. I suppose it's possible that it also does different post-processing like comb filtering during that frame.

Conclusion
This test series proved that there are CRT TVs that do lag. So far, all of these have been late-era SD TVs, but I suppose it's not impossible for older TVs from the eighties and early nineties to lag too.

HD / ED TVs (those with YPbPr inputs that accept 480p) are, from reports I've read so far, expected to be even likelier to lag from post-processing, with the exception of PVMs and other reference monitors.

VGA monitors (intended to be used with PCs) are completely free of lag and can always be configured with the OSD controls to have no overscan too.

Recommendation
I highly recommend that, if you are in need of a screen to play Melee on, you go for a VGA CRT monitor. By doing so, you completely avoid the risk of buying a useless laggy CRT.
If that is not an option to you (for example because they are unavailable or above 50$ in your area, or because of the need to get extra speakers), at least avoid CRT TVs that are flat or look like they are rather new (1998 or later), since their chances of having severe lag seem to be much higher.

A simple VGA CRT setup consists of:
1. A Wii (~25$)
2. An SD card for Nintendont and Melee (~5$) (don't forget to enable Native Control in Nintendont! And perhaps "Unlock Read Speed", which decreases read times, but should only be used when you have the music off since it causes the in-game music to cut out about every third match)
3. Wii component cables + Mayflash VGA-005 converter box, see my post below (~20$ together). The converter's output will always output a black screen for 1-2 seconds after ending a match on a bright stage, which can be fixed by replacing a capacitor. There are no mid-match problems even without the capacitor changed, so it doesn't interfere with tournament play strictly. If the blacking out bothers you and you don't want to solder in a different cap yourself, you can also contact me, I plan to sell VGA-005 boxes with the cap exchanged together with my controller orders.
Alternatively, you could go for the cheap Wii VGA cables on AliExpress, which do not have the blanking problem, however their picture quality is worse and less sharp, so I don't think that's worth the trade.
Comparison pictures will soon be in the OP of this thread!
4. VGA monitor (0-10$ for low to mid-end / 15-50$ for high-end)

Possible upgrades:
5. Wii component cables (5$) + Extron CVC 200 (50-100$) for better picture quality and compatibility with distribution amplifiers and capture cards (no need for the Mayflash converter when going with this option)
6. Extron RGB interface (for example 109xi or 164xi; only needed when using the Mayflash VGA005) (~20-40$) (to make the VGA cables output compatible with dist amps and capture cards) (slightly worse picture quality than #5, but still pretty good)
7. Extron MVX matrix switch (50-150$) (helpful if you use a multitude of consoles / other VGA output devices and VGA monitors)
8. Brightness amplifier (30-50$) (useful if your CRT has low brightness / contrast and you want to improve that without opening the CRT and subjecting yourself to dangerous high voltage) (examples: Kramer VP-103, Extron PA 250)

 

[1ampercent]

Damn, my CRT looks very similar to the one that has reported 25ms of lag. It's a Panasonic tx76pw10a, late-era flat screen with up to 100Hz display. Only got it because of component.

 

[nickthename]

CRT lag

Can you give up the model numbers and more pictures of the laggy TVs?

 

[Minimu5e]

miom conspiracy

 

[imaginary]

Very strange is why the Panasonic CRT TV adds an entire additional frame to the necessary 8.3 ms frame-doubling delay. I suppose it's possible that it also does different post-processing like comb filtering during that frame.

This might be asking too much, but could you confirm this by testing the same CRT and not using composite? That's of course assuming it has other input options (I'm assuming since this is PAL that the only other option would be component?)

Great post yet again, Kadano, amazing work!

Finally, do you recommend any particular set of Wii to VGA cables?

 

[Kadano]

This might be asking too much, but could you confirm this by testing the same CRT and not using composite? That's of course assuming it has other input options (I'm assuming since this is PAL that the only other option would be component?)

Great post yet again, Kadano, amazing work!

Finally, do you recommend any particular set of Wii to VGA cables?

CRT TVs in Europe hardly ever have component inputs. Instead, we have RGB-SCART, which has nice colors, but doesn't do 480p unfortunately.

I will do a lag test of those two TVs with RGB-SCART too, however so far they've always been connected with that and I did perceive both to lag (the Panasonic one more so than the Samsung, which was now confirmed) so I expect that there won't be a difference between both input signals. But we'll see.

It just isn't that simple to set up because I can't easily hook my scope to a Wii with SCART cables connected. I'll have to break a cable open and solder one contact out to connect it or something.

Concerning Wii to VGA, these are your options from best quality to cheapest:
1. Any Wii component cables (cheapest on AliExpress, probably) + Extron CVC
2. Any Wii component cables + StarTech CPNT2VGAA (more expensive than CVC, smaller, probably uses less power, but not made as well)
3. Any Wii component cables + Mayflash VGA-005 (I've bought from that seller, they are genuine) (you need to exchange a capacitor on the PCB for it to not black out for one second after every match on a bright stage)
4. Any Wii component cables + Mayflash VGA 2:1 Box (Also requires the capacitor fix, more picky with its power supply that needs 6V instead of 5V for some strange reason and produces more noise, so option 3 is clearly better)
5. Mayflash Wii VGA cables (also need the capacitor fix like the converter boxes) (slightly lower contrast levels than the upper options since there is no amplifying circuitry, also much less sharp than option 3, see reference pictures in this thread's OP)
6. Knockoff Wii VGA cables (don't need the capacitor fix) AliExpress 20$ (sold out) 17€ Ebay / 22$ AliExpress (available as of 2017-03-25)(picture quality is roughly the same as option 5, see the reference pictures in the OP)

All options except #1 and #2 are still improved by the RGB interface (addition #6 in my last post here).

 

[MrGraves]

I have a Sony Trinitron KV36HS20. I use a wii with component cables and the TV says it is outputting in 480p when I start up 20XX melee. Is this a good set up or is there something I can easily do to improve it?

 

[Kadano]

As I mentioned in my two last posts here, all Mayflash VGA products require a capacitor replacement to work consistently. If this is not done, the video voltage levels will drop to 0 V for 4 frames and there will be about two seconds of the screen blacking out whenever a match on a bright scene transitions to the results screen (or any other instant bright to dark scene change, the mentioned one is just the only one I know in our setting).

(Purple / 3 is fixed with a 22 nF capacitor, light blue / 2 is original)

While this does not strictly speaking interfere with competitive tournament sets, it can still be somewhat bothersome, so here are the instructions on how to replace the capacitor:

Link in German for the Mayflash 2:1 YPbPr to VGA converter switch and the original Mayflash Wii VGA cables

The text in German explains that one capacitor has way too high capacity, which is the cause of the problem. Replacing it with a 10 nF rated one solves the issue. Make sure to solder the capacitor in the correct orientation (font reads the same way as that of the original capacitor), since that does matter for capacitors.
Markus (the creator of the webpage) does not cover the Mayflash VGA005 product, which is in my opinion maybe the best YPbPr→VGA converter to get for the price (outside of Extron CVC).

Here are photos I made of mine, left original condition and right post-fix:

Before modding|After modding

|

The text on the capacitor is a bit blurry. It says "223" on there (22 nF). 22 nF also works fine, I simply used one of these because I was out of 10 nF ones. For both, the standard rating of 50V is easily sufficient.

Oh, and here is a photo of the modded VGA004 cables:

The blue, yellow and red wires are there just for my own lag-testing purposes (so that I can hook them too my scope). They are not necessary at all for the capacitor fix.

Can you give up the model numbers and more pictures of the laggy TVs?

Panasonic TX-29E40D/M and Samsung CW-28C75V.

I have a Sony Trinitron KV36HS20. I use a wii with component cables and the TV says it is outputting in 480p when I start up 20XX melee. Is this a good set up or is there something I can easily do to improve it?

According to its specifications, it does line doubling, but no frame doubling. Line doubling shouldn't lag more than 50 µs or so. However, Fizzi tested a Sony CRT TV with very similar specifications to yours to have >30 ms lag, so I'm afraid that there's a somewhat large chance your TV is laggy. Your TV even has the same suffix ("HS", which might stand for "High Speed" video processing that seems to lag severely).

 

[MrGraves]

According to its specifications, it does line doubling, but no frame doubling. Line doubling shouldn't lag more than 50 µs or so. However, Fizzi tested a Sony CRT TV with very similar specifications to yours to have >30 ms lag, so I'm afraid that there's a somewhat large chance your TV is laggy. Your TV even has the same suffix ("HS", which might stand for "High Speed" video processing that seems to lag severely).

Thanks for the quick response. I wasn't really sure about it, but I guess I'll have to keep hunting for a better one.

One other question I have is that I am currently using an Acer XR341CK to play netplay on. Is this monitor up to par with other ones I've seen recommended or not really? I've done some digging and can't seem to find anything conclusive that I can comprehend. Thanks in advance.

 

[FSU_pawN]

So are all flat CRT's bad? Even Flat Sony Trinitrons?

 

[Kadano]

Thanks for the quick response. I wasn't really sure about it, but I guess I'll have to keep hunting for a better one.

One other question I have is that I am currently using an Acer XR341CK to play netplay on. Is this monitor up to par with other ones I've seen recommended or not really? I've done some digging and can't seem to find anything conclusive that I can comprehend. Thanks in advance.

Googling this monitor leads to a TFTCentral review, which lists about 8 ms in total for your monitor and 60hz. Some other monitors (BenQ RL2455HM, Asus VG248QE at 144hz for example) have about half of that.

So are all flat CRT's bad? Even Flat Sony Trinitrons?

No. There just seems to be some correlation. Flat Sony VGA CRT monitors, for example, never have lag.

 

[MrGraves]

Googling this monitor leads to a TFTCentral review, which lists about 8 ms in total for your monitor and 60hz. Some other monitors (BenQ RL2455HM, Asus VG248QE at 144hz for example) have about half of that.

Ok last question. Friend of mine has an RCA f32450. Would this be a good one? How can you tell? I'm just learning about the different features and what can effect the lag. Thanks again for your help Kadano.

 

[Phil Matic]

Kadano how does that first Sony PC monitor you listed perform? I think if I remember correctly PC monitors with those BNC inputs produce a green image? But I'd love to have a monitor that's completely lagless.

 

[MrGraves]

Does anyone know how to determine if a laptop has lag? Going to be doing some travelling and am in need of a new laptop. How can I figure out a laptop with low lag?

 

[Kadano]

Ok last question. Friend of mine has an RCA f32450. Would this be a good one? How can you tell? I'm just learning about the different features and what can effect the lag. Thanks again for your help Kadano.

How can I tell? By googling for that monitor / TV and looking up specifications and release sheets. 100 Hz or 120 Hz is most telling of lag, but they aren't always listed as features even though they are present unfortunately. The F32450 doesn't have them listed in its sheet at least. "Digital comb filter" is not a good sign though.

Kadano how does that first Sony PC monitor you listed perform? I think if I remember correctly PC monitors with those BNC inputs produce a green image? But I'd love to have a monitor that's completely lagless.

The Sony GDM-F520 are excellent monitors. You only get a green image with BNC inputs if either the monitor has gone bad or you tried to plug in YPbPr directly without converting to RGBHV.

This might be asking too much, but could you confirm this by testing the same CRT and not using composite? That's of course assuming it has other input options (I'm assuming since this is PAL that the only other option would be component?)

I did that today, by using an RGB-SCART Gamecube cable with composite breakout ports. There is no difference in lag, still 25 / 8.3 ms.

I've also went through all the TV menus on both laggy TVs, there are no options to disable the frame rate doubling feature at all.

 

[aerokarp]

Kadano Because I bought a CVC 200 that then broke, I have only been playing melee on my GDM-F520 without converting the output. Is that bad for the monitor (I would assume not, but it can't hurt to check)? Also, I've been getting the black screen as well, even without using a converter.

 

[Kadano]

Kadano Because I bought a CVC 200 that then broke, I have only been playing melee on my GDM-F520 without converting the output. Is that bad for the monitor (I would assume not, but it can't hurt to check)? Also, I've been getting the black screen as well, even without using a converter.

Your CVC 200 broke? Damn, that's bad. I thought that they'd last 5 years at the very least, being (when new) expensive professional video devices and all. Do you know which part of it broke (power supply / signal processing)?

As far as I know, RGBHV and YPbPr use similar voltage levels, so connecting the YPbPr RCA leads to the BNC connecters shouldn't be able to damage the CRT.

However, doing so gives you a greenly tinted image, right? I'd recommend buying one of the Mayflash VGA005 converters that are currently on Ebay for 15$.

Do you get the black screen at the same times as what I reported for the Mayflash products (whenever ending a match on a bright stage) or at other times too? And was this problem the same both with the CVC 200 (when it still worked) and when connecting to BNC directly?
I remember reading years ago that Wiis occasionally output 480i frames even when set to 480p, maybe this has something to do with it. I personally haven't had the problem on my Wiis yet, though (when using Mayflash products with the capacitor correctly replaced).

 

[hectohertz]

here's one for the wikis:

Sony PGM 200R1U

480p and 480i. looks beautiful :D

(not sure if itll do 480p over component (YUV), but it does over VGA or RGB)

 

[aerokarp]

Kadano I'm pretty sure it was the signal processing part that broke. The power light is on, but when I plug it into the monitor and try to play, it gives a black screen and does this two-tone beep thing (I can try to record it when I next am at home). I also took it apart and reseated all the components just to be sure.
I only get the black screen after matches, and I don't remember if it happened when the CVC 200 was still working.

 

[hectohertz]

going to mod a gamecube component cable to do 480p over VGA. this will make the PGM the perfect melee monitor. i don't know how to show pictures to compare, but anyone who's interested i can try and share