TVP5150AM1 VITC slicing errors

My comments are as following:

1. Checksum calculation is wrong. It should not be xoring but uses G(X) = X8 + 1.
2. Hours data is near to the end of horizontal line. VITC slicer is not adapted to VITC data skewed of line data.
3. I guess there is VITC signal skewed sometimes and C5151AM1 slicer cannot slice it correctly.
4. Recommendation: Recalculate checksum and updates time when the checksum is correct.

Thanks for the reply Juan,

1. Yes, you are correct about that. I see that it is a CRC value. I did implement the CRC calculation earlier today. I found that the entire CRC byte was shifted over by one bit. For example the VITC data input to the chip had the ninth CRC byte = 0x27, whereas what was detected by the TVP5150AM1 was 0x4E. So it seems the bit sampling rate of the slicer is faster than the VITC bit rate.

2. It seems now that the sampling rate of the TVP5150AM1 does not match the VITC data rate of the source. If the data is not lined up at the beginning of the block it would contribute to make the error worse. The fact that the first bytes are always read correctly leads me to conclude there is a clock difference.

3. Possibly the signal is skewed, however the VITC source should be a good one as it is made for broadcast studios. I'll check that the VITC bit rate is within spec, and the clock rate of the TVP5150AM1.

4. That was something I considered as well, to throw away bad blocks, and I will ultimately do that. Unfortunately the checksum is almost never read correctly, and even when it does the rest of the VITC block is not correct. So I have to figure out the source of the error.

Some other ideas:

For VITC there is a pair of sync bits (1,0) sent prior to each byte of data. It would be desirable to use that to resync the bit sampling time along the block. Is it possible that could be implemented in the slicer to make it less prone to drift?

So far my checks of the VITC rate and the clocks do not show a problem. Can you tell me how is the VITC bit sampling rate accomplished (how is it derived from the clock input or Hsync) and how that is reflected in the VITC line data programmed into the VDP RAM?

Are the bit sampling rate values different for NTSC and PAL in the slicer and what are those rates?

Cheers,

Craig.

My associate has tested the timing of the VITC source and it is within spec according to the VITC requirements.

So there is something else causing the problem, or the TVP5150AM1 does not slice the data according to the spec.

Details of the VITC source timing:

I have checked out the general timing of the VITC. Page 28 of the SMPTE 12-1-2008 spec item 10.5.1 quotes:

The half-amplitude point of bit 0 shall occur no earlier than 10.0 µs following the half-amplitude point of the leading edge of the line synchronizing pulse. Measured 10.2 µs.

The half-amplitude point of the trailing edge of bit 89 (logical one) shall occur no later than 2.1 µs before the half-amplitude point of the leading edge of the following line synchronizing pulse. Measured 3.04 µs.

Bit timing should be 1/(115*F horiz) ±2%

1/(115*15734.27) = 552.657 ns (541.604 to 563.71 ns) Measured 560 ns.

So, all measurements appear to be within tolerance.

Horizontal period should be 63.55 µs. Measured 63.60 µs.

Juan, after checking the timing of the VITC source we have determined that the bit stream sent to the TVP5150AM1 is within spec, although the bit duration is on the high side.

The total error over the VITC block is sufficient to traverse a bit time towards the end of the block, even though the timing of the source is within spec.

The VITC generator is a commercial unit and the TVP ought to be able to decode its signal correctly.

As I mentioned in another post I suspect the VDP slicer is not taking advantage of the sync bits embedded in the VITC stream to maintain sync.

Please let me know if that is the case, and see if it is possible to get a patch that will correct the problem.

Thanks, Craig.

After checking into this further I see that above I have been quoting the spec values for PAL, whereas I am currently diagnosing an NTSC setup.

I understand the duration of the VITC bit field for NTSC 525 line timing is nominally 50.286uS.

We measured 50.24uS coming out of the generator so that should be ok if the TVP5051AM1 is slicing at the correct bit rate.

There is still something incorrect in the TVP5150AM1 as I have programmed it for NTSC/VITC slicing.

If the TVP5150AM1 were slicing at the PAL bit rate while NTSC is coming in, then I expect it would cause exaclty the problem I am having.

So please let me know the sampling rate that is used for the NTSC/VITC timing. Once we know that, then we're on our way to finding a solution.

Craig.

After further tesing I have found evidence that the VBI slicer documentation has mixed up the C-RAM programming values for VITC-PAL and VITC-NTSC.

When I first put in an NTSC signal with VITC at the appropriate NTSC rate it appeared that the final 2 bytes of VITC data was read incorrectly. It appeared that it was reading the VITC data at the PAL data rate.

So I tried programming the C-RAM with the 16 bytes of data for PAL. Now the same NTSC VITC signal is decoded correctly including the CRC byte.

Specifically I have programmed the C-RAM with the following (I replaced the NTSC values with the PAL values):

VITC, PAL/SECAM 140:  00 00 00 00 00 8F 6D 49 A4 85 08 00 00 00 4C 00

VITC, PAL/SECAM 150:  00 00 00 00 00 8F 6D 49 A4 85 08 00 00 00 4C 00

VITC, NTSC 160:  00 00 00 00 00 8F 6D 49 A4 85 08 00 00 00 4C 00

VITC, NTSC 170:  00 00 00 00 00 8F 6D 49 A4 85 08 00 00 00 4C 00

The TVP5150AM1 is detecting the video as NTSC according to the status register 5. The line select registers are programmed with 0x1B to select VITC-NTSC with error correction.

I do not have a source that can generate VITC at the PAL rate yet, but plan to test that as soon as possible.

This product needs to be able to reliably decode both NTSC and PAL so I want to verify why this is happening and take appropriate corrective measures.

Please verify that the C-RAM programming information is correct. I would also like to know how the line select register contents are used to reference the C-RAM data.

Thanks, Craig

Hi Craig.

I wonder if you solved the problem since I have the same.

I've tested VITC PAL with the above C-RAM code and it works just fine.

In order to get at least some VITC from a NTSC signal I need to use the same C-RAM code as for PAL.

Then I'm getting VITC but not all frames are captured.

Any ideas?

Thanks, Tommy

Hi Tommy,

I haven't done much more on the VITC reading problem since my last post. Exchanging the documented RAM configuration values for PAL and NTSC seems to have fixed the problem for me. I deduced that the decoding was mixed up by looking at the pattern of where the errors appeared in the data stream. That might tell you something as well. I also apply the firmware patch that is described in the TI information but I don't think that had much effect.

As for missing frames I assume that you have taken drop frame in to consideration. That is, in drop-frame video the frame count will miss 2 counts each minute, but not on each 10th minute.

Foy my application I am not all that concerned about the frame value, other than to determine whether the 'transport' is in forward, reverse or stopped. I just use the hh:mm:ss values so can accept some missed frames.

In the next few weeks I expect that I'll be going back to do some cleanup on the VITC detection, as I have seen that some video sources are not decoded correctly (Ones that I know are not to spec). If I find anything that might help you then I'll let you know.

Please let me know if you come across anything, too.

Craig

Craig,

Thanks for your reply. I've worked for hours trying to solve this issue without luck. Exchanging the NTSC and PAL in the config RAM helped a lot, but I still experience flipping bits in VITC hours decoding. Surely we need a patch to fix this.

Tommy.