TVP5150AM1 no NTSC colour lock

Anybody have any comments on this one at all?

Need more information?

TI, can you confirm it's a problem, or can't reproduce it?

Anything at all?

Any and all assistance appreciated.

Cheers,

Dave.

Dave,

Are you using this device with a YPbPr input?  If so, that may be your issue.  The TVP5150 is a composite, Svideo analog video decoder.  It does not support component or YPbPr video inputs.  You will need a TVP7002 video triple ADC to digitize Y/Pb/Pr.  Hope this helps. 

Regards,

Kevin

Kevin said:

Are you using this device with a YPbPr input?

No that's fine Kevin, I'm not insulted. I'm sure you must come across a lot of people that don't know composite from component, but I'm not one of them.

I've put a THS8200 on the bus from the TVP5150AM1 to reconstruct my decoded signal as component, running it in 8-bit (2 LSBs of input set to 0) BT.656 8:4:4 with embedded synchs. All works fine with PAL inputs but NTSC colours (PrPb) are not decoded correctly although the luminance signal is fine. I'm beginning to wonder if it's a decode issue at the THS8200 rather than an encode issue with the TVP5150.

Thoughts?

Dave,

Are you using a nominal NTSC input with color burst present at all times?

Regarding potential TVP5150AM1issues:

- When an external clock or oscillator is used, 1.8V logic levels should be used.  You are seeing the same issue when a crystal is used, so this may not be causing this particular problem.

- The frequency and stablilty of the crystal, or external clock, used should be within +/- 50 PPM.

- If  the INTREQ/GPCL Pin27 is left floating, color lock issues can result, if this pin is not configured as an output.  Refer to the REG 03h desicription in the datasheet.

Here are the THS8200 settings that should work for ITU BT656 to YPbPr decode:

BEGIN_DATASET  // Added by WinVCC4 v4.31

DATASET_NAME,"THS8200 bt.656 NTSC in, 480i60 YPbPr out"

//THS8200

WR_REG,THS8200,0x01,0x03,0x11 // chip_ctl           

WR_REG,THS8200,0x01,0x1C,0x04 // dman_cntl          
WR_REG,THS8200,0x01,0x1D,0x00 // dtg_y_sync1        
WR_REG,THS8200,0x01,0x1E,0x49 // dtg_y_sync2        
WR_REG,THS8200,0x01,0x1F,0x00 // dtg_y_sync3        
WR_REG,THS8200,0x01,0x20,0x00 // dtg_cbcr_sync1     
WR_REG,THS8200,0x01,0x21,0x00 // dtg_cbcr_sync2     
WR_REG,THS8200,0x01,0x22,0x00 // dtg_cbcr_sync3     
WR_REG,THS8200,0x01,0x23,0x22 // dtg_y_sync_upper   
WR_REG,THS8200,0x01,0x24,0x2A // dtg_cbcr_sync_upper
WR_REG,THS8200,0x01,0x25,0x3E // dtg_spec_a         
WR_REG,THS8200,0x01,0x26,0x14 // dtg_spec_b         
WR_REG,THS8200,0x01,0x27,0x1E // dtg_spec_c         
WR_REG,THS8200,0x01,0x28,0x79 // dtg_spec_d         
WR_REG,THS8200,0x01,0x29,0x00 // dtg_spec_d1        
WR_REG,THS8200,0x01,0x2A,0x00 // dtg_spec_e         
WR_REG,THS8200,0x01,0x2B,0x01 // dtg_spec_h_msb     
WR_REG,THS8200,0x01,0x2C,0x6B // dtg_spec_h_lsb     
WR_REG,THS8200,0x01,0x2D,0x03 // dtg_spec_i_msb     
WR_REG,THS8200,0x01,0x2E,0x1B // dtg_spec_i_lsb     
WR_REG,THS8200,0x01,0x2F,0x11 // dtg_spec_k_lsb     
WR_REG,THS8200,0x01,0x30,0x00 // dtg_spec_k_msb     
WR_REG,THS8200,0x01,0x31,0x0A // dtg_spec_k1        
WR_REG,THS8200,0x01,0x32,0xAD // dtg_speg_g_lsb     
WR_REG,THS8200,0x01,0x33,0x01 // dtg_speg_g_msb     
WR_REG,THS8200,0x01,0x34,0x03 // dtg_total_pixel_msb
WR_REG,THS8200,0x01,0x35,0x5A // dtg_total_pixel_lsb
WR_REG,THS8200,0x01,0x36,0x00 // dtg_linecnt_msb    
WR_REG,THS8200,0x01,0x37,0x01 // dtg_linecnt_lsb    
WR_REG,THS8200,0x01,0x38,0x84 // dtg_mode           
WR_REG,THS8200,0x01,0x39,0x21 // dtg_frame_field_msb
WR_REG,THS8200,0x01,0x3A,0x0D // dtg_frame_size_lsb 
WR_REG,THS8200,0x01,0x3B,0x07 // dtg_field_size_lsb 
WR_REG,THS8200,0x01,0x3C,0x80 // dtg_vesa_cbar_size 

WR_REG,THS8200,0x01,0x41,0x40 // csm_clip_gy_low    
WR_REG,THS8200,0x01,0x42,0x40 // csm_clip_bcb_low   
WR_REG,THS8200,0x01,0x43,0x40 // csm_clip_rcr_low   
WR_REG,THS8200,0x01,0x44,0x53 // csm_clip_gy_high   
WR_REG,THS8200,0x01,0x45,0x3F // csm_clip_bcb_high  
WR_REG,THS8200,0x01,0x46,0x3F // csm_clip_rcr_high  
WR_REG,THS8200,0x01,0x47,0x40 // csm_shift_gy       
WR_REG,THS8200,0x01,0x48,0x40 // csm_shift_bcb      
WR_REG,THS8200,0x01,0x49,0x40 // csm_shift_rcr      
WR_REG,THS8200,0x01,0x4A,0xFC // csm_mult_gy_msb    
WR_REG,THS8200,0x01,0x4B,0x44 // csm_mult_bcb_rcr_msb
WR_REG,THS8200,0x01,0x4C,0xAC // csm_mult_gy_lsb    
WR_REG,THS8200,0x01,0x4D,0x91 // csm_mult_bcb_lsb   
WR_REG,THS8200,0x01,0x4E,0x91 // csm_mult_rcr_lsb   
WR_REG,THS8200,0x01,0x4F,0xFF // csm_mode           
          
WR_REG,THS8200,0x01,0x70,0x40 // dtg_hlength_lsb    
WR_REG,THS8200,0x01,0x71,0x03 // dtg_hdly_msb       
WR_REG,THS8200,0x01,0x72,0x59 // dtg_hdly_lsb       
WR_REG,THS8200,0x01,0x73,0x04 // dtg_vlength_lsb    
WR_REG,THS8200,0x01,0x74,0x00 // dtg_vdly_msb       
WR_REG,THS8200,0x01,0x75,0x04 // dtg_vdly_lsb       
WR_REG,THS8200,0x01,0x76,0x04 // dtg_vlength2_lsb   
WR_REG,THS8200,0x01,0x77,0x01 // dtg_vdly2_msb      
WR_REG,THS8200,0x01,0x78,0x0B // dtg_vdly2_lsb      
WR_REG,THS8200,0x01,0x79,0x00 // dtg_hs_in_dly_msb  
WR_REG,THS8200,0x01,0x7A,0x44 // dtg_hs_in_dly_lsb  
WR_REG,THS8200,0x01,0x7B,0x00 // dtg_vs_in_dly_msb  
WR_REG,THS8200,0x01,0x7C,0x00 // dtg_vs_in_dly_lsb  
WR_REG,THS8200,0x01,0x82,0x27 // pol_cntl           

END_DATASET

Hi Larry,

thanks for getting back to me. My responses to yours as follows:

Yes, the burst is present at all times. Last night I burned a DVD with SMPTE-75 colour bars in NTSC format and here are some pics of the mighty Bravia hanging off the component out of the 8200 (hope this works):

YPrPb

Just Y and Pb:

and Y and Pr:

I was driving the 5150 with xtal out from the micro which is running on 3v3, but padded this down to 1v8 levels by series resistor at the source (micro) and shunt  termination at the sink (5150) as per a proper transmission line. Made no difference - not surprising as running the 5150 on its own rock gave the same results.

The crystals are supposed to be 50ppm, but just in case, I've ordered some 30ppm which will arrive tomorrow.

I've got pin 27 configured for PALI output, so it's not floating.

Thanks for the 8200 data set, mine's pretty well identical, but I leave the BT656 bus hi-Z. I recompiled using yours anyway, but no difference.

Any new ideas?

Brad,

Pb looks OK, so YC separation in the TVP5150AM1 and the crystal are most likely not the issue.  Cb and Cr use the same digital data path, so this appears to be ouput DAC or cable related.  Does PAL work well consistently?  If this were a DAC channel issue, I would suspect both PAL and NTSC to be affected.  You have probably checked this already, but we have had issues with intermittent cables and connectors.

It's still possible that the THS8200 is not being set up properly.  If enabled and not set up correctly, the digital multipliers and color space converter in the THS8200 could cause this.

Brad???

Hi Larry,

the 20ppm xtal made no difference whatsoever. Yep, PAL is consistently perfect. I am at a loss as to where to go from here.

Is it possible that there is some issue associated with the timing of the 4:2:2 decode? That is, when the THS8200 samples the parallel bus, that would be different between PAL and NTSC?

Should have done this earlier. I'm guilty of postulating causes when I didn't understand the fault. (Where do I hand in my degree?)

Here's Pb on the little 'scope:

and here's Pr:

You can see the Pr signal polarity alternates with every line, effectively cancelling out the signal.

Now that the question of what is wrong is actually defined, the answer may come easier!

David,

Other than turning on the TVP outputs, are you using default TVP5150 settings with the THS8200 settings that were sent?  I am having trouble figuring out what could be causing Pr to invert every other line.  Are you still using a direct connection from the TVP5150  to the THS8200?  Are you seeing the same behavior with multiple parts?

There are over-flow protection bits in the THS8200 for the CSC and CSM blocks (see I2C REG 0x19 an 0x4A).  Over-flow can occur if these are used with protection turned off.  I am not sure why this would occur every other line, however.

Do you see color issues with all NTSC sources that you have tried? You could try forcing the TVP5150 to NTSC (REG 28h) to see if this makes a difference.

Hi Larry,

Yep, I've tried the default settings as well as my own custom settings to force the 5150 into just NTSC mode by loading #00000010B (0x02) into reg 0x28.

As you can see from the above CRO shots, the problem has nothing to do with the THS8200. As the R-Y signal is reversed on alternate lines in PAL (the B-Y is not), it would appear that the decoder still thinks the signal is PAL and is "undoing" this reversal.

Finally got a few moments where I decided to follow this one through (or die in the attempt!)

I measured the colour burst frequency and what do you know - it's 4.433MHz - the source is being recoded from NTSC to PAL (NTSC is 3.579MHz), although still as 480i60. I had assumed (fairly I think) it was being output as NTSC as it was 480i60 not 576i50. I tried a couple of other players - they completely recode the 480i60 NTSC as 576i50 PAL, NTSC output is just not possible. I finally found a player with a switch that allows the output to be the native 480i60 NTSC disc format or recoded to 576i50 PAL. The 5150 decodes both correctly, my software reads the standard and reconfigs the THS8200 correctly and all is good.

Thanks for all your help in getting to the solution TI - much appreciated, I should have had more faith in the chip!

There's a catch though...

I need to be able to configure the 5150 to accept 480i60 PAL and, I s'pose, 576i50 NTSC. These are hybrids, but I've shown they can exist.

Interrogating Status Register #1 (0x88) for the Line Alternating Status and Field Rate Status together with the Vertical Line Count Registers (0x84::0x85) provides a indication of what the signal format really is.

I think that then it would be possible to load the Horizontal Sync Start Register (0x16) and Vertical Blanking Start Register (0x18) and Vertical Blanking Stop Register (0x19) to accommodate these 'standards'.

Thoughts?