# Synchronising to a colour burst

Does anyone know of a chip which can extract the colour burst from a PAL or NTSC video signal? Then, I would need to start an oscillator of the right frequency (4.43361875 MHz for PAL, and 3.579545 MHz for NTSC) and keep it oscillating once this frequency is established. If the signal is PAL, I would also need to phase shift this oscillator on every other line. Ideally, I would use just one crystal for both but I don't think the two frequencies could be derived from one crystal. It is required that the module support both PAL and NTSC; I'd like to avoid producing two types for different systems. In other words, I need some way to synchronise to a colour burst. I'm sure such devices must exist; most broadcast PAL/NTSC TVs would use one, but I'm having no luck.

-
What is the end goal of this? Meaning, what are you going to do with the 4.43 or 3.57 MHz clock? I'm just thinking that what you're asking is rather difficult and knowing a bit more can give us insight into what's important and what isn't. –  user3624 May 17 '11 at 15:06
@David The end goal is a colour video overlay. I need to separate the colour burst from the video signal to generate the chroma signals. –  Thomas O May 17 '11 at 16:43

I would guess you're trying to upgrade your video overlay projects for color? A tough job. One difficulty you're apt to encounter is that while a 100ns jitter on a luminance signal is annoying but tolerable, and 50ns would be barely noticeable, even a 25ns jitter on your chroma signal will be clearly visible (it's about the difference between red and orange). For luminance, it's fine to derive your dot clock by passing a free-running clock running at 24+ MHz through a counter that's held in reset during HSync, thus keeping all of your timing in the digital domain. Chroma timing is sufficiently tight that such an approach will only yield good results if you have a really fast clock.

I can't think of any consumer-electronics product I've ever seen which could overlay a color image onto a composite video signal which they did not either generate or decode internally. There's probably a reason.

Edit If you really want to forge ahead, your best bet may be to clock some logic with a precise multiple of the chroma frequency (e.g. 57.272727MHz if you can get it--chroma * 16), and then have fine-pitched variable delay using something like:

Out0 = MyRef
Out1 = Out0 | (MyRef & (PhaseDelay == 14))
Out2 = Out1 | (MyRef & (PhaseDelay == 13))
Out3 = Out2 | (MyRef & (PhaseDelay == 12))
...
Out14 = Out13 | (MyRef & (PhaseDelay == 1))
Out15 = Out14 | (MyRef & (PhaseDelay == 0))


Ideally, each stage should delay by about 2.5ns, so the total delay would be 40ns, or a fair bit longer than the period of your clock. On each scan line, determine whether you're lagging or leading the chroma signal. If you're lagging, use a lower PhaseDelay value next line; if you're leading, use a higher one. If you fall off the end, add or delete a clock cycle and adjust PhaseDelay by a self-tuning amount; use the lagging or leading phase next line to determine whether to increase or decrease that amount.

The logic could perhaps be simplified slightly if your reference chroma were guaranteed to be a tiny bit slower than the original, even with both signals at the ends of their tolerance regions. I'm not sure what the exact tolerance ranges are, though.

PS--Another simplification might be to say that if before you sample the first chroma pulse of a scan-line you're close to the end of your delay line, add/drop a cycle and adjust PhaseDelay by a suitable amount; don't add/drop a cycle at any other time. There are probably about 4 "trustworthy" chroma samples per line (the front end end of the chroma burst are sometimes a little wonky), so if your initial estimate of how much to adjust your delay time is even close, you'll be able to adjust it by +/- 4.

PPS: A further simplification if you figure there will always be (at least) five nice chroma cycles would be to drop the length of your delay line so it's just a smidgen over your fast clock cycle, then use the first chroma cycle to get within a fast clock of the right position, the second to select between two delay taps that are about half a cycle apart, the next to select between taps that are about a quarter cycle apart, etc.

-
I know that there is at least one OSD chip out there which does colour and certainly doesn't have enough memory for storing an entire frame (only about 1 Mbit.) So I think it's possible, but out of the realms of ASICs... it might be tricky. Thanks for the tips. –  Thomas O May 17 '11 at 16:44
I was considering some kind of FPGA to do this if needs be. –  Thomas O May 17 '11 at 17:01
@Thomas O: I think using a pseudo-delay-line approach (a series of gates feeding each other) might be good if you're using a chip where the delays work out to something reasonable. Not so fast that you need to waste oodles of gates to get your delay, but not so slow that you have no real resolution. See PPS above. –  supercat May 17 '11 at 17:12

A phase-locked loop (PLL) is the standard way to do that. A 74HC4046 is often used in that situation, and should work with both frequencies.

-
I don't think a 4046 will work for color synchronization, since one only gets a about 2.5us of chroma reference every ~64us, and will thus have to 'coast' for about 60us while having a wave which is accurate to within a fraction of a microsecond at the end of that time. One would either need to use a crystal-controlled PLL, or else have a crystal-controlled reference signal which one can phase-shift by very small amounts. I'll extend my answer to cover the latter approach. –  supercat May 17 '11 at 15:56

I know this is a year old but I came across someone with a similar issue who solved it differently. He was doing capture of NTSC colour images.

He threw out the notion of genlocking to the NTSC colour burst at all. He used a synchronous detector to sample the color burst at the beginning of each line at the chroma frequency (3.579545 MHz) and then again for each pixel in the line.

In other words he determined the IQ of the chroma burst relative to his own reference clock and then determined the IQ of each pixel, again relative to his own clock. Then he could calculate pixel relative to the chroma.

"To sense the i and q components of each color burst and each pixel, I created two clock outputs at the chroma frequency, that are 90° out of phase. Each is combined XOR fashion in a logic mode counter that serves as a mixer/demodulator and sums the response over the programmed integration time."

Not sure if this helps anyone but I found it real interesting.

-