My TVP5150AM1 application does not colour lock on NTSC, but does on PAL.
Luminance is always correctly decoded.
Sometimes Pr is correctly decoded, but in that case there is no Pb.
Some background information:
The device is clocked from the crystal output of a 3.3V 8051-family device, running with a 14.31818MHz crystal.
I do have anti-alias filters as described in the application data.
I do allow for SCL stretching (software IIC interface) and delay-before-stop.
NTSC is included in the Auto-switch.
Reading back from the chip I find that register 0x88, bits 3::1 are all 1 (Colour, VS and HS all locked).
Register 0x8C reads back as 0x81 for NTSC and 0x83 on PAL.
I've tried running the device from its own crystal, but there is no difference in performance. I am at a loss as to where to go from here.
Any assistance appreciated.
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.
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.
Please Verify Answer if you think it answers your question. Thank you
KevinAre you using this device with a YPbPr
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.
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"
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
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):
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 [i]supposed[/i] 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?
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.
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!
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.
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!)
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
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'.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.