On Sony CRTs and D-sub-SCART cables

[Milsancho]

Hello,

I was wondering if anyone here is aware of the issue certain Sony RGB CRTs have with c-sync and sync on luma RGB sources. Basically, colors are severly wrong with the former and reds are darkened with the later on some late Trinitron chassis. Sync on composite solves it fortunately. I need to buy again cables for almost all the consoles, but my main concern is the cable from my PC for 15khz usage (RGBHV D-sub to RGB SCART). There’re several options out there especially now with Mister devices around but none seems to confirm it outputs sync on composite video while also being a good quality cable/combiner.

Do you have any suggestion?

Thank you.

 

 

 

 

[BuckoA51]

I’m not aware of that at all, I could certainly imagine it being the case with clean composite sync, but luma? I’m not sure how the television would even know the difference between a black and white composite video signal and the luma from S-video.

[Milsancho]

Yeah, you can read some people having color issues with this Sony chassis (FE2) yet never it’s properly diagnosed. I’m still to find it fully documented, at least. So I’m not really sure which are the intolerances exactly.

I’ve tested it with two different units though, both behaving the same:

· Japanese Sega Saturn with C-sync TTL cable: severely wrong colors, kind of greenish

· Japanese Sega Saturn with sync on CVBS RGB cable: accurate colors

· PAL PS2 slim with sync-on-luma cable from RGC: only red is darkened

· PAL PS2 slim with unexpensive RGB cable (I assume sync on CVBS): accurate colors

· Japanese DC with two different RGB cables (they were unexpensive so I assumed as well they were sync on CVBS): red is darkened, unsure if the rest are really fine

· RGBHV D-sub to RGBS SCART with a resistor to join syncs: only red is darkened

All these cables were already tested on different TV sets with no major issues detected.

Likely the major color issues I get with the SS C-sync cable are due to it not having attenuated electrical signals for consumer TVs, but inferring that this TV chassis only tolerates sync on CVBS is the only answer I can think of. I’m far from being an expert anyway, so maybe I’m missing something.

Do you know of a device which safely turns either RGBHV or RGBS into sync-on-CVBS RGB?

Also, could you confirm that sync-on-CVBS RGB uses pin 20 also for R-G-B and leaves pins 15, 11 and 7 withou any use?

(I’m a bit surprised that sync-on-CVBS RGB is so widely ignored by European cable makers, despite knowing that digital devices usually don’t support it.)

Thank you.

 

 

 

[Milsancho]

Also, could you confirm that sync-on-CVBS RGB uses pin 20 also for R-G-B and leaves pins 15, 11 and 7 withou any use?

I’ll address this myself, though it’s still a guess – sync-on-CVBS RGB does “use” pin 20 for R-G-B as well as combined sync, but also uses pins 15, 11 and 7 for R/G/B, otherwise it would display a composite video signal. So colors are carried over in two simultaneous ways with this RGB mode.

If anyone here happens to have any idea who could I ask to make a RGBHV/RGBS to CVBS-as-sync RGB adapter or even just to discuss which circuit could be used for that, please let me know. I thought it would be more common than it is as the opposite is a well-documented process, and it’d be a real shame if this TV set could only be used for consoles.

 

 

[BuckoA51]

Do you know of a device which safely turns either RGBHV or RGBS into sync-on-CVBS RGB?

I think such a thing would be pretty much impossible since there’s no composite video signal left, it’s been stripped out, literally all there is is sync so where would you get the composite video from? I suppose you could transcode it on the fly from RGBS, but since we’re only talking about a handful of peculiar TVs here I doubt that anyone would want to make such a device.

I’ll address this myself, though it’s still a guess – sync-on-CVBS RGB does “use” pin 20 for R-G-B as well as combined sync, but also uses pins 15, 11 and 7 for R/G/B, otherwise it would display a composite video signal. So colors are carried over in two simultaneous ways with this RGB mode.

I’m not quite sure what you’re getting at here, pins 15, 11 and 7 are used for RGB. For an RGB signal you also need sync, this is taken from the composite video feed usually, on pin 20.

So, if you had composite video on pin 20 and no signals on pins 15, 11 and 7 you could get a composite video picture. If you had RGB on pins 15, 11 and 7 but no composite video signal, you couldn’t get anything because you need snyc for RGB.

When using RGB the composite video is ONLY used for sync, it is not used to extrapolate any colour information, something is clearly wrong with the sync processing circuit in the TV to cause this behaviour.

• This reply was modified 1 month, 1 week ago by BuckoA51.

[Milsancho]

Yep. I was confused about ‘CVBS-as-sync RGB’ because of the terminology used, I guess. Somehow I didn’t expect R-G-B being carried over two simultaneous ways, and didn’t know that the difference between CVBS signal and ‘CVBS RGB’ was just that. I think the explanations I had read placed too much emphasis on the sync signal and never mentioned that R-G-B are doubled. That, and ‘C-sync’ (which should be ‘clean/raw sync’ instead for better clarity – CVBS is technically also ‘C-sync’, you know.

 

I think such a thing would be pretty much impossible since there’s no composite video signal left, it’s been stripped out, literally all there is is sync so where would you get the composite video from? I suppose you could transcode it on the fly from RGBS, but since we’re only talking about a handful of peculiar TVs here I doubt that anyone would want to make such a device.

Yeah, ever since I asked, some stuff is more clear to me. I’ve been advised to try with an RGB-to-CVBS encoder, but making sure it features RGB passthrough. At least one person made them in the US, but sadly not anymore. Other current Chinese samples may help or may not, nobody knows as indeed not many people have faced the issue or bothered enough. At any rate, it’d require custom cables and the chain would be weird.

Fortunately, I’ve also learned that this FE2 chassis do have a setting to basically recover reds’ integrity – ‘TT34’ when entering service menu. It’s not absolutely perfect, but almost. The TV has now a really nice picture, even if colour saturation and brightness should be tweaked a bit when going from a C-sync/sync on luma source to a CVBS RGB source. Moreover, some people claim to have found an ultimate solution for this particular problem:

Well, I have finally found the definitive solution to this problem without the need for any hardware modification, the problem was a pulse in the horizontal syncronism too high, this in some TVs generates a flattened color scale, can be corrected by lowering the “H Pulse” field in the hdmi_timings, it is possible that by lowering it timings with frequencies below 60Hz, they will suffer vertical desynchronization, so the “V sync” would also have to be lowered.

https://github.com/mortaca/RGB-Pi/issues/12

As I don’t know how much reduction should be that though (not an RGB Pi user myself, and the author isn’t sharing too many details), I’m going to order a cable with 280 ohm resistors for pins 7, 11, and 15, which a guy says worked flawlessly for him as well. So well, just wish me luck, even though I’m quite happy with how the colours are right now.

 

 

 

 

• This reply was modified 1 month, 1 week ago by Milsancho.
• This reply was modified 1 month, 1 week ago by Milsancho.

[Author]

Posts