Prototype set is here

[Penthode]

Originally Posted by tubesrule

Hi Terry,
Certainly obtaining the video directly from a digital source is preferable but not practical for this level of converters. In my professional design work, everything is SDI, quickly becoming 3G SDI but that is unheard of outside the broadcast industry. Consumer level HDMI is hampered by HDCP making it useless unless you want to try to obtain a license which would be cost prohibitive for these low volume converters.

For my low cost converters I use a video front end with a 4 line adaptive comb filter, so while not quite as good as component, it has proven to be more than adequate for the capabilities of these early sets. These parts have the capability to support S-Vid, so this input can be added to these converters. My broadcast WC converter has CVBS, S, and component YUV/RGB inputs but is overkill for this purpose. It uses 10 bit ADC/DAC's with 14 bit minimum internal processing which considerably raises the cost.



I don't think it would be quite this easy in analog using baseband component. You need to generate the 3.8MHz carrier, preferably correctly locked to the Hsync (assuming the Hsync from the source is even stable enough although you could free run like consumer vcr's), bandwidth limit and quadrature modulate the R-Y and B-Y and then add back into Y. Potentially an off the shelf part might be able to do at least a portion of this, but it's still a fairly involved design.

The nice thing with an fpga design is you are not limited to the physical hardware. If you want to add a filter, change the carrier frequency or phase, etc. it's just a respin of the vhdl. I have added stuff to clients designs that were not even in the original spec all without touching the hardware.

Darryl

Hi Darryl,

I certainly see your points. But the issue at the time was for CPA to optimize luma and chroma resolution. For one to first hand understand whether the abandonment CPA was justified requires a signal with at least the chroma resolution the early NTSC was trying to achieve. CPA was initially intended to convery full bandwidth chroma for both color differ signals of 1.5 MHz. NTSC constricted the Q channel to 500kHz. Secondly the use of a four line adaptive decoder compromises the diagonal luma resolution as well as reducing the vertical chroma resolution. In other words concatenating the two codecs will not give a proper representation of CPA. However, this will only be worth the bother if the display CRT focus and bandwidth to the CRT are up to the job of showing the extra resolution that was intended by the use of CPA.

I also believe the thought of the NTSC at the time was if putting the subcarrier at 3.89MHz, would the subcarrier into luma interference pattern less obvious and allow the luma bandwidth to be somewhat greater? The IQ NTSC standard with the subcarrier at 3.58MHz meant that the luma trap limited luma bandwidth to only about 3.0MHz and with the subcarrier at 3.89MHz, the luma response was effectively extended another 400kHz.

Component video from a DVD player will have reasonable stable sync. I agree that locking the subcarrier to the sync will be a challenge. VHS tape as a source will be totally out of the question since VHS does not fulfil the mathematical subcarrier to Hsync relationship and VHS simply does not have the bandwidth. DVD playback does and is stable.

I would think the reason I would persue CPA encoder without the IQ concatenation would be to see how well CPA would work. I think we would all agree that component 525 video looks very decent. (In fact playback of a good quality component DVD authored from 35mm film looks better than much (if not most) broadcast video purported to be HD).

I agree that a dozen transistors will not account for even the sync divider. But I think a few ASICs may be adapted to work in a CPA encoder. I trust the restoration of this set (if it is indeed a CPA Prototype) will come to fruition and the opportunity presents itself to compare CPA encoding schemes. Besides I would like to see how well an FPGA solution will work.

All the best,

Terry