Clean sync RGB to CVBS-as-sync RGB help

[vol.2]

This is supposedly the software solution by the author of RGB Pi, in case it adds to the discussion:

It is interesting. If what the author says is true, then you may be able to fix the issue by reducing the voltage of the H sync pulse. In the case of the RGB Pi discussion, the author corrected it by changing the voltage level of the H sync pulse in the video mode. You probably can't do that from a PC. AFAIK, CRU doesn't have any way of doing that, and I've never seen anything in normal video drivers that allows you to do that.

The only way you could do it would be to manually reduce the amplitude of the H sync pulse with either a resistive divider or some IC. I can't imagine trying to do it without an oscilloscope though. I would want to be able to see the voltage level and then probably stick a potentiometer in there between the signal path and ground and dial it in.

In either case (software or hardware) you would need some method of checking to see what the pulse looks like.

[Bassa-Bassa]

I actually use CRT Emu Driver, maybe asking the author is worth it. You can change stuff like sync polarity from the driver currently, so who knows. But I don't know, the sub-60hz modes possibly losing V sync with it sounds like the issue would be getting too many facets. Maybe I should try getting me a cable with additional resistors as a first measure. Worst case scenario, the resistors could be desoldered and the cable is not wasted.

[vol.2]

I actually use CRT Emu Driver, maybe asking the author is worth it. You can change stuff like sync polarity from the driver currently, so who knows. But I don't know, the sub-60hz modes possibly losing V sync with it sounds like the issue would be getting too many facets. Maybe I should try getting me a cable with additional resistors as a first measure. Worst case scenario, the resistors could be desoldered and the cable is not wasted.

Sync polarity is a common setting for video modes. The voltage level of the output is dictated by the video mode and is not something that you would normally be able to adjust. Whatever is going on with you specific TV, if this is the problem, has something to do with the TV being particularly sensitive to out of spec signals. Most TVs are pretty tolerant of stuff like that, which is why you don't see the complaint outside of a handful of sets.

It's also only an issue for non standard sources, such as a PC video card outputting NTSC SD video, which they were never intended to do. PC EMU is just "faking it" because it usually "just works."

Your challenge is, assuming this is the issue, to lower the voltage level of the horizontal sync.

[Bassa-Bassa]

So forgive my ignorance once again - just by lowering the voltage of the H sync (which can be done with a resistor?) you "lower the H Pulse field in the hdmi timings"? Is it just a matter of knowing of much should it be to pick the proper resistor?

As for non standard sources, it happens with sync on luma as well, for what it's worth. I guess it's still non standard for European makers, but given how Sony favoured this RGB signal type (which was still present on their PAL consoles from the same era than this TV set), one would think they would not take that as out of spec.

If I have to be honest though, I don't think I would have noticed any colour issue at all if the Cdec setting had been in its "proper" position from the beginning and if I had known nothing about it - the picture is really good thanks to the saturation setting. It's a good question why it isn't set as default on these models and it's quite unfortunate other chassis with similar issues don't seem to feature it.

[vol.2]

So forgive my ignorance once again - just by lowering the voltage of the H sync (which can be done with a resistor?) you "lower the H Pulse field in the hdmi timings"? Is it just a matter of knowing of much should it be to pick the proper resistor?

If we assume that the post you linked to is correct, and the problem is a non standard sync voltage level, then it will work. You would use two resistors; one between the horizontal signal and the TV's sync input, and the other between the first resistor (and also the output) and ground. This creates a resistive divider. You can easily calculate the voltage drop with an online calculator. If we assume it's a little too high, say maybe 1.2V as some VGA signals are, then you would need possibly a 750ohm resistor between signal and source, and a 1050ohm resistor between output and ground. https://ohmslawcalculator.com/voltage-d ... calculator

That should give you around 0.7V, closer to regular TV sync.

The voltage calculation will change when under a resistive load, so it's generally preferrable to do this while things are on and measure it, but it might just be okay as is. Not sure. If it doesn't work, you can adjust the values a bit and see if it gets any better. But this is definitely better to have a scope for.

As for non standard sources, it happens with sync on luma as well, for what it's worth. I guess it's still non standard for European makers, but given how Sony favoured this RGB signal type (which was still present on their PAL consoles from the same era than this TV set), one would think they would not take that as out of spec.

Sony is know to have picky sync for a number of their pro monitors actually. A lot of PVMs have issues with non clean sync. You have to take into account that all these things were never meant to be hooked up together. If I wanted to connect a PC to a regular TV in the 90s, I would use an Extron unit, because that's just what you did, and it always works. It might not be up to the standards of a video game CRT fan in 2025, but it was perfectly fine in 1995

[Bassa-Bassa]

OK, thanks.

[Syntax]

What is the purpose of the 27pf on FSC IN?
I thought the only 27pf would be on YTRAP if used.

[viletim]

What is the purpose of the 27pf on FSC IN?
I thought the only 27pf would be on YTRAP if used.

R15, C32 is a low pass filter. Performance is better when the subcarrier signal is smaller and less square. It uses the same capacitor value as the luma trap because I just copy/pasted this from NESRGB and that circuit's been BOM optimised.