It's a NTSC color question

[Takashio]

Hello all! I'm hitting a snag on a personal project and I was hoping someone with a fresher head or a better understanding can help.

I'm doing an LPC810-based video circuit that is mostly generic (just a resistor network as DAC), but uses a lot of the built-in technology to save on pincount. By this I mean that the line timing is interrupt driven, the clock line is via the internal IRC, and the color subcarrier is managed by an integrated PWM block.

This is really not optimal, so I went to great care to make sure the timing was accurate (before you ask, I never turn the PWM off, I just disable the output at pin level to make sure phase coherence is kept):

So, this is the colorburst (top is source PWM, bottom is generated signal):




The H-sync is also up to standard and doesn't seem to shift at all:
~

So, when all it's said and done, why does the video signal normally looks like this (sorry about the squashed video, I only captured half a frame)?
https://www.youtube.com/embed/XzwraHwkl_Q

Here's a frame capture with some apparent color but quick flickers are more the norm:


My living room LCD proves to be more lenient and gives a bit more faithful reproduction, so I'm adding a shot as a comparison (but it will also flicker quite a bit and go BW every now and then):

I've tried:

- changing the colorburst amplitude
- changing the colorburst phase relative to signal color
- leaving it on all the time
- more variations on the subcarrier pulse than I can remember
- changing the V-Sync timings (they might not still be spec accurate, but are enough to ensure carrier is not drifting across fields/frames)

but nothing ever seems to never be enough to give color 100% of the time.

I know the simpler answer is "use a crystal/dedicated encoder IC" but I'd rather know _why_ does this implementation doesn't work. I feel like I'm missing an important factor here about how color is detected/regenerated.

[Richard Crowley]

I'm not sure I am understanding the "source PWM" vs. the "generated signal".
Why doesn't the "generated signal" look more like the PWM?

The min "high" voltage of the "generated signal" is almost as low as the max "low" signal level.
That could be very confusing to old analog circuits that are expecting a much cleaner burst waveform.
And especially as your full-line scope photo shows that your color-burst signal is significantly offset positive.
It should be essentially symmetrical with the "back porch" (the DC level just after the color-burst).

Note also that some displays are more forgiving than others for strict NTSC waveform standards.

[IconicPCB]

Never
The
Same
Colour

Switch to PAL

[edavid]

1. Let's see your resistor network schematic.

2. Interrupt driven video timing usually doesn't work well, because there's too much variation in the interrupt latency, which translates to jitter.
(It's OK with very simple CPUs like PICs.)

[vk6zgo]

Your colour burst is horrible--it should look like the one in Richard's posting.
The burst detector may be just on the verge of operating,but drops straight out again.

Your video seems to imply that your video & horizontal syncs aren't locked to each other.

Ignoring the luma being all over the place,the colour effect looks like when we tested  PAL stuff with a 4.433MHz signal generator,prior to getting real PAL sources,back in the very early '70s.

You did remember to use 3.58MHz?

[Takashio]

hanks for all the answers!

About the resistor ladder (Vd = 3.3V):


A o-|910|+
         |
B o-|620|+
         |
C o-|330|+
         |
         o
        50 Ohm
         o
         |
        GND


A handles the chroma subcarrier. When the subcarrier is disabled, A is put high and set to an open-drain mode. Otherwise it's in pull-up mode. This sounded like a good idea as it could let me set three states, in practice the difference between "high-impedance" open drain mode and just setting the pin to low and letting the 910 Ohm resistor be grounded is not significant (as you can see in the color burst). Suggestions on improving this tri-state setting are appreciated, as I've run out of pins . I can reduce the value of the 910 resistor (the overshoot-like behavior in that case remains the same amplitude), but I didn't got any improvements as regards color sync.

B and C handle the other 4 possible signal levels in the expected way.

For reference, the measurements taken were with the video capture/load on. I'm guessing the passive nature of the DAC has something to do with these overshoots in the colorburst?

Good point about the interrupts. The LPC810's ARM has a minimum IRQ latency period register, set at 15 cycles with a system clock of ~36Mhz. Considering the ARM is idling, all interrupts should start servicing reliably at the 15th cycle. I'll play around with it and see if the sync improves (15 wait cycles, the subcarrier is 10 cycles long so maybe...)

As far as the subcarrier frequency goes, it's pretty close to 3.57Mhz, as far as I can measure it. Am I just missing the goalpost there with the missing ~9Khz? It seems to line up with vk6zgo's PAL signal experience.

[Ian.M]

The colour burst needs to be a clean sinewave and it is locked to the line and frame rates.
See: http://antiqueradio.org/art/NTSC%20Signal%20Specifications.pdf
The colour subcarrier is required to be 3.579545 MHz +/- 0.0003% (3ppm) for a broadcast spec signal.  As it is common to use a crystal or ceramic resonator for the chroma local oscillator that is PLLed to the colour burst (as its phase must remain stable for a whole scanline), even equipment generating non-broadcast spec signals should stay within 30ppm (typical crystal tolerance) of the nominal frequency to get reliable chroma lock with the majority of receivers.

You will need to get the system clock frequency spot-on (usually by using a crystal that's an exact multiple of the colour subcarrier frequency) so that you can generate the correct chroma subcarrier, and you will need a tuned series RLC network replacing the 910R resistor for signal A to couple in the colour subcarier without excessive harmonics or any DC shift.