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.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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 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.
Five years later: Another solution to this problem is to use the MC1378P chip, which is a color sync/overlay generator chip especially for this use case. The drawback is that it's not in stock with "normal" distributors and needs to come from various chip merchants, and I doubt anyone's making any new stock of this. Analog video is kind-of on the way out, even for 5.8 GHz FPV displays (the last remaining use case I can think of.)
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.