I am trying to capture pixel data going to a small B&W CRT display. The signals I have to work with are the TTL-level pixel data signal, HSYNC, and VSYNC. I know the pixel clock frequency (~16 MHz) but for my application, I have no access to the pixel clock signal.

I want to sample the pixel signal at the appropriate time (during the middle of the bit period, not during the transition), so I figured I need to generate a new 16 MHz clock with some phase relationship to an edge of the HSYNC signal and use that to sample the pixel signal.

I know how to use a PLL to multiply a clock signal and maintain a certain phase relationship between the input and output, but how do I maintain a similar relationship between a new 16 MHz clock and a signal that only occasionally has an edge (HSYNC)?

Or is there a better way to solve this problem?

  • \$\begingroup\$ You probably want an algorithm- or software-locked loop - with a low loop bandwidth you could tune the VCO in software. Or run a faster fixed clock, initialize a counter at the sync and then sample calculated count intervals thereafter (possibly with accumulated fractional counts). You may find digital monitors with VGA inputs have fancy schemes that look at the actual data changes for clock recovery more than the syncs. Your source probably has a low bandwidth, so If your sampling system and its destination can handle it, you could also oversample and cleanup the results in software. \$\endgroup\$ Jan 15, 2017 at 20:01
  • \$\begingroup\$ Also you might see if you could just use an existing PCI or USB video capture solution - if it is versatile enough to handle the timing, the analog level remapping would be easy to work out. \$\endgroup\$ Jan 15, 2017 at 20:01
  • \$\begingroup\$ two questions: a) does "TTL-level" imply "binary" as in "Black OR White", or does it imply "grayscale, somewhere between 0 V and 5V"? b) is it certain that there's a fixed relation between the HSYNC/VSYNC period and the pixel clock? Thinking about the whole NTSC frame rate == 24.97verymanydigits Hz business, I'd assume pixel clock might be recovered independently. \$\endgroup\$ Jan 15, 2017 at 20:09
  • \$\begingroup\$ If Hsync is very stable then a VCXO can be made stable multiple of Hsync to make a pixel clock. But to align LCD pixels the phase may need be adjusted. My TV uses the actual video signal to Sync create the Pixel clock and then computes the Hsize and V size and offset or origin to minimize the phase error on all pixels and locks on in second. 99% of the time on power up with a blank digital screen it locks correctly with no pixel aliasing. My Question is how accurate do you want Pixel clock frequency/phase and how small jitter and do you want lock detect to activate search/freeze clock. \$\endgroup\$ Jan 15, 2017 at 20:15
  • 1
    \$\begingroup\$ By the way, this is totally on-topic here, but if you want to make this question about how to recover the pixel clock, it would be an excellent question for signals.stackexchange.com \$\endgroup\$ Jan 15, 2017 at 20:28

3 Answers 3


One way to approach this would be to use your PLL (referenced to HSYNC) to generate a master clock at 3× or 4× the pixel clock, and then use a Johnson counter to generate new pixel clocks with 3 or 4 different phase values. You can then select the phase that has the desired timing, either manually with a jumper, or electronically with a multiplexer.

There are ways to lock a PLL directly to an intermittent reference (i.e., the video signal itself), but since you already know the nominal dot rate, this shouldn't be necessary. However, you could use the phase detector from such a system to help you automatically select the best phase of the Johnson counter for sampling.

  • 2
    \$\begingroup\$ What would you reference the PLL to? If you mean you'd have a local clock that runs at a multiple of the expected pixel clock, then I'd expect it would work, but the difference between that and the actual source clock frequency would cause occasional jumps between your various phase choices. If this happens rarely, fine, if multiple times per screen, perhaps the phase increments need to be finer?. With a higher multiple it seems okay - and I expect the original pixel clock is fairly slow, so 10x or more may be possible inside an FPGA. \$\endgroup\$ Jan 15, 2017 at 20:41
  • \$\begingroup\$ @ChrisStratton well, a 160 MHz sampling rate does put a non-trivial requirement for board layout and ADC as well FPGA speed on the system; so I think the question really is, in a signal with little reliable state transitions, how to reference a PLL \$\endgroup\$ Jan 15, 2017 at 20:47
  • 1
    \$\begingroup\$ @MarcusMüller - the 160 MHz (or potentially faster) clock would be internal to the FPGA, as it's only needed to digitally phase the actual sample clock. The clock routed on the board to the ADC need be no faster than the actual pixel clock, unless oversampling for post-processing is desired. These clock rates are relatively supportable for simple logic in an FPGA, however trying to leverage an FPGA's PLL/DLL/whatever blocks might be better. \$\endgroup\$ Jan 15, 2017 at 20:49
  • \$\begingroup\$ ah, so I misunderstood you, @ChrisStratton. Yeah, that sounds feasible – and as line rate multiplication actually seems to be the way that commercial ICs do it, yep, that might be the way to go. On the other hand: Meh. I was hoping for pixel rate estimation from the pixel signal alone. \$\endgroup\$ Jan 15, 2017 at 20:52

This sounds like a one-off project (most just trash B&W CRT technology).
Even with such old technology, it was common to derive all timing from one master clock. If so, HSYNC is likely synchronous with pixel edges - easing your PLL design considerably.
A 'scope triggered on HSYNC while looking at TTL video would tell you if HSYNC is synchronous with pixel clock? If it is, you also get some idea of jitter that your PLL will have to deal with. And synchronous HSYNC eases your PLL design considerably. Even in this easy scenario, you must contend with having no PLL input during vertical retrace.

In the case of non-synchronous HSYNC, VSYNC, your pixel clock reconstruction will be very difficult. You might just have to over-sample pixels, and re-construct the output video from a frame buffer, introducing a one-frame delay.

  • \$\begingroup\$ It's worth considering that even with a synchronous source, there's probably an unknown phase delay from the sync to the ideal time to sample a pixel, both as a detail of design, and due to rise times after various cables and drive/receive networks. \$\endgroup\$ Jan 15, 2017 at 22:16

This is (in principle) fairly easy. You don't try to lock on your 16MHz clock. Instead, you build a divider which has an output the same frequency as your sync. For instance, if your horizontal period is 63.5 usec, this is 1,016 cycles of 16 MHz. So you would feed the 16 MHz into a divide by 1016 chain, then sync the output of the chain to Hsync.

This is, "in principle" fairly straightforward, but the devil is in the details. You must know EXACTLY how the clock is related to the sync, or the new 16 MHz will not be locked to the pixel positions. You'll need to use a VCXO for an oscillator, or the large dividing factor will produce phase jitter on the VCO which may make the system unusable. Finally, you'll need to experimentally determine the phase shift between the pixels and the 16 MHz, which may or may not give you problems.

Note that you cannot do this with a fixed-frequency 16 MHz oscillator. The oscillator frequency MUST be controllable, and should preferably be tunable over a very small range, like 100 ppm. Hence the need for a VCXO.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.