.

[Pasky]

.

[flynwill]

Are those ends of the grid lines suppose to be blue?

First problem I see is that it looks like the sub-carrier is not locked to the line rate.  I didn't entirely follow your description, is the color sub-carrier coming from a different clock source than the actual video generation?   Really old TVs were quite tolerant of the is and you probably wouldn't notice the effect there, but more newer one incorporate comb filters in the color decode circuits that attempt to suppress the "zippers" as we used to call them, but depend on everything in the video running from the same clock.

If those bits of line are supposed to be white, then I'd suggest putting up a simpler test pattern -- maybe an all white raster, and then look at what is happening with your scope.  Is it possible that the R&G video inputs are being clamped where but blue stays high? Or put up traditional color bars and see if all of the colors are there.  Make sure that your sync input to the chip is properly timed with respect to the video as the chip uses that to derive the color burst pulse.

[Pasky]

.

[flynwill]

The question you didn't answer:  Is the problem just the "dot crawl" when you display a color?  Or are you getting color where there should only be Black and White?  (Ie should the areas with the blue crawl in your video be solid blue or solid white?).

Either way a less-complicated test pattern (in particular one that only changes in the horizontal dimension) is a lot easier to diagnose with your 'scope.

The "crawl" is inherent in the design of NTSC.  Having the sub-carrier locked to the video helps to minimize it's appearance but it it always there. Given a free running RGB source the "right" way is to use a phase-locked loop to lock your sub-carrier oscillator to the 277.5 times the line rate.  But of course your source has to match the specified NTSC timing to within 10 ppm to be able to do this.  The main point of this trick is that ".5" which means that the sub-carrier is 180 degrees out of phase on the next scan line.  When the phase only shifts a little bit with each line you get the crawling diagonal lines.

Do you have the means to measure your RGB source to see if it actually conforms to NTSC timing? 

[Pasky]

.

[flynwill]

It's possible to lock it down, but only if your RGB source is accurate enough (or can be adjusted to be accurate enough).  What is the signal source?   Even if you can't lock it down if you can make some small adjustments to it's rate to get closer to the correct ratio you might significantly improve the picture.

From your movie it looks like you are displaying the pattern on a fairly modern LCD display -- who's circuits may well be making the problem a lot worse than an old CRT would have done.

Instead of using a packaged oscillator you would need to build a Voltage-controlled Xtal oscillator.  At one time every color television had such a circuit so a bit of web searching should get you ideas.  It usually easier to design if you start with 4x the sub-carrier frequency (14.31818 MHz) for your oscillator instead of 3.579545 MHz.  And then with that build a phase-locked loop, locking the 4x clock divided by 910 with the horizontal sync.  However as I mentioned before your source's line rate needs to be correct to within about 10 ppm. (0.001%) as that is the normal tolerance on the sub-carrier frequency in the decoders.

If it isn't possible to control the source that accurately the only fix is to buy or build a frame-synchronizer -- a device that digitizes the incoming video and stores it in a frame buffer, then plays out the frame buffer at the correct rates inserting or deleting single fields as necessary to make up for the difference in the frame rate.  Might be a fun project as I'll bet you could do it with just and FPGA, the A/D and D/A converters and a bit of RAM, but probably way more than you were planning to get into.

[Pasky]

.

[flynwill]

Unfortunately, no I don't think it has any circuitry to lock it's sub-carrier oscillator to the horizontal rate.  It does have a PLL, but is only setup to generate 4xFsc (14.31818 MHz) from the Fsc input to drive it's quadrature modulator.  It does have an oscillator as part of it's circuitry so that would save you the external oscillator part (but you still need a crystal), but in that mode the sub-carrier oscillator is free running and not phase locked to the supplied video.

In fact the data sheet discusses what they refer to as "asynchronous operation" and some of the possible side-effects of the sub-carrier not being synchronized to the video.

And before you went very far down this road I would carefully check out the video coming from your source, if it doesn't match the NTSC timing then you will not be able to lock the sub-carrier oscillator to it even if you do find or build circuits to do so.

How accurate is the horizontal timebase in your Rigol 'scope?  if it is accurate enough you might be able to just measure Fh directly (or you might quickly discover that it is way off...)  If you have a source of NTSC video (old vcr or DVD player perhaps) then you could feed that signal into your 'scope, trigger off it, and then connect the composite sync from your RGB source to the other channel and observe how quickly one drifts with respect to the other -- which will also give you some idea if there's a chance it can work.