OSSC Pro Gain Voltage / ISL51002

[M3Patterns]

I just got the OSSC Pro plus the Extra AV Out. I am using it in passthrough mode to go from component video into my VGA 240p monitor.

I’m trying to figure out what the component gain units are in actual volts. (The default gain unit is 324 in the OSSC Pro.)

I also see that the picture is not as bright as what I normally see when using either a component to RGB adapter (LMH1251) or the Retrotink2x Pro in passthrough.

Looking at the ISL51002 spec sheet, it lists the gain as spanning from +/-6dB (just about 50% to 200%) and again says specifically that the nominal gain voltage range goes from 0.5V to 2.0V.

The transfer function is stated to be 0.5V + (GainCode / 170). For 1.0V (which is 0.7V Peak to Peak) it’s stated that the GainCode value should be 85.

In 8-bit, 85 / 255 = 1/3

1/3 of 1.5V = 0.5V

So, 0.5V + 0.5V = 1.0V

That means that a GainCode value of 0 is 0.5V and the rest of the 1.5V is added in a proportion of 1.5V / 255.

That’s appears to match what I see on the OSSC Pro: a gain value of 0 is dim, but not zero contrast.

However, I think that also means that the default Y / R-Y / B-Y gain values of 324 in the OSSC Pro may be wrong.

If I want 1.0V of output (0.7 p-p) in the 10-bit numbers that are listed in the menu, that would mean I would want a gain value of 341. (341/1023 = 1/3.)

The math would be 0.5V + (341/1023)*1.5V = 1.0V (0.7p-p).

If this is not correct, does anyone know what the actual gain value units are in volts?

[marqs]

The way I interpret the manual is that gain is adjustable from 0.5 to 2 (V/V or no unit!) which matches the +/-6dB spec. Assuming that ADC reference voltage is set to 0.7V and back porch clamping is used, unity gain of 1 should be configured using value 340 (which is the register reset value btw). However, I recall seeing some clipping in my setup all those years ago when the ADC was evaluated and ended up using slightly lower default value in the firmware. Maybe I should redo gain tests if others are seeing some headroom in the upper end.

[M3Patterns]

After testing, I’m pretty sure I’m seeing clipping as well, so the lower gain values make sense. For my purposes, though, it’s super helpful to know the exact voltage values, so thank you for confirming that.

Is there anyway to determine clipping using any current controls in the OSSC Pro? If not (and I can add this to the Feature Requests section) it would be helpful to have something like zebras or false color (video / photo terms) to show exactly when clipping occurs.

Also (and again I can put this in the Feature Request section) a related option for PC CRT users that I think would be extremely helpful, if it was possible, would be to not let the Extra AV Out clip at all, but instead just pass higher voltages.

PC CRTs will work with higher signal voltage just fine and it can actually help them to appear very close to TV CRTs:

https://www.facebook.com/groups/444560212348840/posts/3158011424337025/

Making 480p on a VGA monitor to look identical to 240p on a 15kHz monitor
byu/ninjaurbano incrtgaming

I haven’t yet looked into the ADV7125KSTZ140 to see if it’s possible, though.

[M3Patterns]

I just looked at the ADV7125. While it does offer the ability to output higher voltage with a variable resistor (which would be helpful in analog-land) it does not appear to handle anything beyond exact 8-bit input, which means no superwhite accommodation (which is basically what I meant by not letting the Extra AV Out clip at all, but instead just pass higher voltages.)

That means that you really have to dial in the gain so as not lose 8-bit precision. In digital-land, that’s understandable, but the Extra AV Out could have more flexibility, since analog signals can accommodate voltages over 100IRE.

That also means that certain consoles that generate superwhites over 100IRE (like the NES) are going to be clipped unless the ISL51002 gain is lowered below unity. But if you do that, you do lose 8-bit precision in analog-land. The more the gain needs to be lowered to compensate, the more that reduces the availability of 8-bit values.

For instance, if you had an 120IRE signal that needed gain reduced by a factor of 1.2x, the 255 values of 8-bit would also be reduced by 1.2x to about 212.

That wouldn’t really be an issue with something like the ADV7123, which is 10-bit. Could a future revision use that chip or another higher bit option?

 

Right now the best current option for pure passthrough that handles superwhites would be to:

1. lower input gain, either before input into the ISL51002 or using the adjustable gain in the menu.

2. Increase gain after the ADV7125, using an external VGA to VGA amp.

 

Any thoughts on this?

[marqs]

Even with ADV7123, the video processing inside Pro starting from ISL51002 (or ADV7610 in case of HDMI) is 8bit. That was a practical choice to reduce pin, RAM and logic usage, i.e. cost in the end. Having an adjustable Rset would be low-barrier improvement if a new revision of extra_av_out board is made at some point.

[M3Patterns]

That makes sense. I did not know the processing was being done as 8 bit.

I am currently running both of my OSSC Pros out to a VGA amp, so avoiding that step (and extra box) by having a voltage amp on a future revision of the Extra AV Out would be nice. If that was implemented, it would also be helpful, if feasible, to have the output voltage measured and displayed on the OSSC.

 

Would it be possible to preserve 10 bit data just in passthough modes? (Or have a fork of the firmware that has [potentially greatly] reduced functions, but be fully 10 bit?)

Alternatively, if it’s possible to have just a few initial steps be 10bit, I was thinking that there could be a color correction stage that is fully 10bit before being quantized down to 8bit. That may preserve the signal a bit better (and fit within the ADV7125) without the overhead of everything being 10bit. The existing Component to Rec.601 / Rec.709 conversion could be done as 10bit, and then there could be an option for individual RGB gain controls (since the Y / R-Y / B-Y / Y gain values do not have the ability to directly control the RGB values.) Additionally, there could also be the ability for a full 3×3 matrix of color conversion.

 

An RGB gain option and 3×3 color matrix option I would love to see implemented regardless.

 

All that being said, I still need to test if I can even see the difference on a CRT between 255 worth of values and 212 values (120 IRE) or less. I am actually currently running an OSSC Pro with over 40IRE of headroom (178 values) and I don’t see anything objectionable / noticeable after a few hours of SNES games.

[Author]

Posts