I would like to build a SIMPLE circuit that generates PAL sync signals with no MCUs, because they don't make any ICs of these kind anymore. I have already tried a solution, but I think it is overcomplicated. Basically, I have a 18-bit counter, that is incremented every 10th μsec. A half-frame is divided into 4 sections: presync, picture sync, postsync, and line data signals. Checking the counter is what makes the modes cycle. In these modes, there are sub-modes, which change the voltage when the delta-timer reached a specific point. The delta-timer is a timer that is "frozen" at a given signal, and outputs the difference between the actual timer and the value of the actual timer when the frost signal was handed out. I believe there is a much simpler way to achieve this.
-
5\$\begingroup\$ The simplest circuit will be a MCU (and scarcely anything else). So, is "no MCU" a hard requirement? If so, what are other "forbidden" components? Because if you don't allow an MCU, it's unlikely any of the devices that do exist and are usually used for this purpose would be allowed (they're all complex logic devices). \$\endgroup\$– Marcus MüllerCommented Aug 2 at 18:52
-
\$\begingroup\$ There is the ZNA234E, you might find stock of it from various sources. \$\endgroup\$– Lior BiliaCommented Aug 2 at 18:56
-
3\$\begingroup\$ By the way, please read tag infos before using the tag: tvs is not about television, but about transient voltage suppression :) \$\endgroup\$– Marcus MüllerCommented Aug 2 at 19:00
-
\$\begingroup\$ Or use something like this electronique.marcel.free.fr/Video_Television/Docs/… \$\endgroup\$– Antonio51Commented Aug 2 at 20:29
-
\$\begingroup\$ SPG625 \$\endgroup\$– StainlessSteelRatCommented Aug 3 at 0:48
4 Answers
So, the good news is that if you read ITU-R BT.1700, which is the actual standard specifying the PAL signal, its timings and timing tolerances, the world is easier to implement than if you read the numerous copies of copies of book and web articles that do not state timing tolerances!
So, get that ZIP, open the 1700-e.pdf inside, and jump to page 6 for Figure 1, and compare that to Table 2 on page 7.
Now, instead of saying "oh, these numbers are given with one decimal number after the dot, e.g. as 1.2 µs", you'll see that they have tolerances. For example, "d Duration of synchronizing pulse" is given as 4.7 µs \$\pm\$ 0.2µs. And you know what, 4.75 µs is within 0.2 µs of 4.7 µs, and would therefore also be OK, if it's easier to generate. And:
You'll notice that you can round all these times to multiples of 0.25 µs – so instead of 10 MHz counter, you only need a 4 MHz counter.
That makes a microcontroller implementation relatively possible – if you'd like to reconsider that. A mid- to higher-end microcontroller with a DMA engine could definitely shuffle data to a DAC at a rate of 4 MS/s (or just be the DAC itself – you don't need many levels, so combining output pins with resistors is an option).
Other than that, as Justme notices, this is something were you just need to wire some logic up. FPGAs, sure, would be the standard approach here, as you'd rarely need something that outputs video without a system controller microcontroller that could also manage the bringup of the FPGA, making the things you need to implement on the FPGA fewer (I personally would rather write software than FPGA "gateware").
But because your state machine is so smol, an integrated hybrid analog/digital configurable device might be the way to go. Renesas bought Dialog Semiconductor (which I think bought Silego), which havee the "GreenPAK" mixed signal chips; and "pattern generator" is definitely on the front page of their product brochure
-
1\$\begingroup\$ The last time I looked at PAL tolerances (over 4 decades ago) to make a TTL frame sync generator, I used a 0.8 us timebase, making the line sync pulse 4.8 us, no recollection of the other times though. \$\endgroup\$– Neil_UKCommented Aug 3 at 7:33
-
\$\begingroup\$ oh, that seems to work consistently! Even lower a clock! \$\endgroup\$ Commented Aug 3 at 9:14
If no MCUs are allowed, there are a handful of options. In fact an MCU might not be the preferred option, unless you use a large enough MCU that can output the waveform using DMA with no jitter of even one clock cycle.
Buy a chip that exists.
FPGA. Sure beats writing software, as it replaces a box full of discrete logic ICs.
CPLD. These tend to be smaller and simpler than FPGAs.
PALs and PLAs. At least some integration.
The box of discrete logic ICs wired corretly to implement the logic which is what you seem to be doing now.
-
1\$\begingroup\$ Of course, a Real Man would use a few 555s for the job hackaday.com/2022/05/30/… \$\endgroup\$ Commented Aug 4 at 7:34
-
\$\begingroup\$ @MarkMorganLloyd Sure but it requires a lot of manual calibration and it will drift a lot. It depends how stable you want it to be. The colour burst frequency accuracy is few ppm. \$\endgroup\$– JustmeCommented Aug 4 at 17:09
Building on the PLA / PAL / CPLD approach . . .
In the mid-70's we got a stand-alone digital timebase corrector to make U-Matic decks FCC compliant. This was a 2nd gen device with a cute sync generator. It used a single high-speed counter and a pair of EPROMs to produce a bunch timing signals with perfectly aligned edges. H and V sync, blanking, and drive; a burst gate, a chroma field flag, plus some internal signals.
Today I would put all of it in a single CPLD.
A counter and an old-fashioned parallel EPROM can do the job. If you use a 256Kx8-bit EPROM, you can clock it up to 6.4 MHz and still store a full frame (2 fields).
Use one bit of the output to reset the counter at the end of the frame, and that leaves you up to 7 to set the signal level with a simple R-2R DAC.
