AD724 Luma/Chroma outputs do not meet SMPTE standard for NTSC

Hi,

  Please find below comment for your queries,

• Is the AD724 meant to adhere to the SMPTE spec for NTSC ?

              I believe AD724 adhere to the SMPTE170M (i.e AD724 outputs NTSC signals that conform to SMPTE 170M). As per specification Most of the more common variants of NTSC and PAL are supported. There are, however, two known specific standards not supported. These are NTSC 4.43 and M-PAL.

              Kindly note that, AD723/4/5 requires interlaced RGB on its inputs & it do not perform any advanced video processing, So it's interlaced to interlaced.

          Please make sure with your input.

             AD725 can be used to convert the analog RGB output from a personal computer’s VGA card to the NTSC or PAL television standards.
             To accomplish this it is important to understand that the AD725 requires interlaced RGB video and clock rates that are consistent with those required by the television standards.
              In most computers the default output is a non-interlaced RGB signal at a frame rate higher than used by either NTSC or PAL.

• Is the increased jitter as a result of asynchronous operation referenced in the "Synchronous vs. Asynchronous Operation" section of the datasheet noise directly from the subcarrier frequency ?

                 Yes, AD724 datasheet states that phase drift between luminance and chroma paths in async mode leads to modulation jitter and visible chroma distortion.

                 Also inorder to Avoid Asynchronous Operation Jitter in AD724,
                      Try to use an External Clock (CLKIN) instead of Internal Crystal Oscillator and don’t use the XTAL1/XTAL2 pins (this puts you in asynchronous mode).Instead, drive the CLKIN pin with a 3.579545 MHz (NTSC) subcarrier clock.

                 Please check this AD724 operating instructions https://www.analog.com/media/en/technical-documentation/evaluation-documentation/AD724_eval_board_instructions.pdf

• The specifications of the AD724 are noted to be for a "FSC synchronous clock". Is there information about performance of the AD724 with asynchronous information? I don't know how much "worse" asynchronous operation is compared to synchronous operation and nothing in the datasheet gives a quantitative depiction of that.

               Please refer this FAQ  AD724: FAQ ,  AD725: FAQ 

Thanks,

Poornima

Hi Poornima - thank you for the response. There isn't anything in the AD724 or AD725 FAQs which tells me anything more about the performance of the AD724 during asynchronous operation.

I am getting an output NTSC video. My inputs and outputs of the AD724 look good. I'm able to see the S-Video/composite outputs on monitors. I'm not struggling to get a video output. I am struggling to get the AD724 to put out correct chroma values when giving it a SMPTE 75% colorbars test pattern.

I tuned my external clock and used a frequency/clock counter to confirm my FIN/Fsc clock was getting 14.31818 MHz while SELECT was pulled high and also tested with 3.579545 MHz with SELECT pulled low. In both operations it seems like my chroma values are still somewhat substantially off.

At this point I don't know if the chroma values put out by the AD724 that do not match the 75% colorbars SMPTE test pattern expected luma/chroma values are because the asynchronous operations results in substantially worse chroma, if there is something for me to tweak on the board, or if the AD724 simply does not adhere to the SMPTE specification well enough. Any information that I can get which gives me a clear indication of the AD724's reduced performance as a result of asynchronous operation would be helpful since it does not seem like this information has been documented in any quantitative fashion in either the FAQs or the datasheet.

The closest thing I have to something quantitative is this from the datasheet: "However, in asynchronous systems the sync to burst position can change line to line by as much as 140 ns (the period of a 2FSC clock cycle) due to the fact that the burst flag is generated from a clocked CSYNC while the sync is injected unclocked. This phenomenon may or may not create visual artifacts in some highend video systems."

I have seen the variability of the sync to burst using my VM700T, but I don't have an idea of what the end result of this variability may be on my chroma outputs. That's what I need to know.

Hi

   Please refer to this thread  RE: The color burst from AD723 seems to move on AD723 Eval Board.  Here expert given some suggestion for a similar reported issue.

Thanks,

Poornima

Poornima, do you have any information on how the synchronization signals and RGB outputs are generated such that they are synchronous to the 3.579545 MHz clock? The pixel clock for NTSC is 13.5 MHz. I might be able to get away with using the 4xFsc of 14.31818 MHz as my RGB pixel clock, but that will result in a somewhat non-standard NTSC output.

Hi,

Please check with below response and let us know,

 I might be able to get away with using the 4xFsc of 14.31818 MHz as my RGB pixel clock, but that will result in a somewhat non-standard NTSC output.

  As per expert comment, The accuracy of the external crystal oscillator reference at 4FSC will be better than +/- 100 ppm, so the ambiguity due to this tolerance will also be negligible.

Also, As per specification Fsc frequency for NTSC is 3.579545 MHz for and 4.433618 MHz for PAL.

Do you have any information on how the synchronization signals and RGB outputs are generated such that they are synchronous to the 3.579545 MHz clock? 

Please refer below for generating the synchronization signals and RGB output,

 - Using a pixel clock (e.g., 14.31818 MHz) to drive timing.
 - Counting clock cycles to determine position in a scanline (horizontal timing) and which scanline you're on (vertical timing) 
 - Generating HSYNC and VSYNC based on known timing values (Correct intervals)
 - Enable RGB output only during the active region of the screen.
 - Keep everything synchronized with the base clock.

Thanks,

Poornima

Hi Poornima, it's been a while!

I am now working with a system that:

• Uses a externally driven, 0ppb error 14.31818 MHz clock that functions as both my pixel clock as well as my subcarrier frequency input
• Generates timing signals based on known timing values
• Keeps RGB output only during the active region of the screen
• Keeps everything synchronized with the base clock.

Unfortunately, my IRE values are not within the SMPTE standard still (measured using a VM700T). I get:

SMPTE colorbars (75%) are meant to have the following values:

It looks to me like in the ideal conditions, the AD724 is falling short of being within reasonable range of the SMPTE standard.

Is there any way to amend this in code or electronics? Am I missing something?

I'd like a response if possible so that I can know what I may be able to do to get the AD724 to output in a way that aligns with the SMPTE standard. Otherwise, I will verify that the answer is simply that the AD724 does not actually properly adhere to the SMPTE standard.

Hi,

  Apologies for the delayed response. I have been attending internal training.

 It's better to confirm by evaluating the same IRE with our AD724 evaluation board.

Thanks,

Poornima

Hi Poornima, that's a great idea! What are the IRE values that are read off of the AD724 evaluation board?

Hi,

  When using the AD724 Evaluation Board, the IRE values that can be read off from the AD724 video output will depend on the input RGB signals and how the board is configured. 

 Kindly refer below snap, This table shows the associated current,voltage and IRE relationships for the various video standards at https://www.analog.com/media/en/technical-documentation/application-notes/478955693AN205.pdf

  Also refer AD724 board instructions details at https://www.analog.com/media/en/technical-documentation/evaluation-documentation/AD724_eval_board_instructions.pdf

  https://www.analog.com/media/en/evaluation-boards-kits/evaluation-software/357707021AD72x_EVB.zip

Thanks,

Poornima