Hi there,
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.
Cheers,
Dave
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.
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 Chalmers
Please Verify Answer if you think it answers your question. Thank you
KevinAre 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?
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
[IMG]http://i29.tinypic.com/281d6i0.jpg[/IMG]
Just Y and Pb:
[IMG]http://i29.tinypic.com/2qwhpvc.jpg[/IMG]
and Y and Pr:
[IMG]http://i26.tinypic.com/e05uh0.jpg[/IMG]
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?
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???
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:
[IMG]http://i34.tinypic.com/2eo8lra.jpg[/IMG]
and here's Pr:
[IMG]http://i36.tinypic.com/kao4za.jpg[/IMG]
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.
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'.