3
\$\begingroup\$

I am currently trying to diagnose a VGA problem on hardware A. Hardware A has some trouble sending display to certain projectors (while it is able to send display on most LCD monitors).

Hardware B connects successfully on both projectors and monitors (Nvidia quadro 2000).

The question here is : could there be a link with the spikes I see on both horizontal and vertical sync pulses of Hardware A and the fact that Hardware A has more problems with certain projectors ? Hardware B seems to have a much clearer signal.

Also, does Horizontal and vertical sync pulse need to align (at both beginning and end of a vertical sync pulse). I see here that Hardware B aligns perfectly, but Hardware A shows a 800 nsec delay.

Vertical sync pulse and horizontal sync pulse - Hardware A Horizontal and vertical sync pulse on hardware A

Vertical sync pulse and horizontal sync pulse - Hardware B Horizontal and vertical sync pulse on hardware B

\$\endgroup\$
  • \$\begingroup\$ Update : Thanks for the suggestions. We will be trying to correct the delay of 850 ns. However, doing so with a circuit seems very tricky since the logical gate's internal delays must be accounted for. Also, we would need very small resistance/capacitance values. We will try to eliminate the delay from the source and see what happens. \$\endgroup\$ – rdavb May 29 '14 at 17:29
  • \$\begingroup\$ Update: I added a 75 ohm resistor on HSYNC line, and I have almost 95% success rate on sync. It reduced the negative HSYNC overshoot from 25% to 20%. However, some images still cause a problem (no sync). I'm still working on trying to remove that 850 ns delay, but it's a lot more complicated than the 75 ohm resistor. \$\endgroup\$ – rdavb Jun 2 '14 at 15:46
3
\$\begingroup\$

Overshoot or delay are not the cause of the problem. Overshoot should not be more than 30% of the logical pulse. Here, we don't see the exact measure but it is no more than 24 %.

As for the delay, it should not be that large, but internal loops in the design make it that way. However, it doesn't prevent the display to work.

What was causing the problem was color levels being 1V instead of 0.7 V (R, G, B) pins.

\$\endgroup\$
  • \$\begingroup\$ Good find. You can accept your own answer. \$\endgroup\$ – stanri Jun 9 '14 at 20:47
1
\$\begingroup\$

Different projector vendors use different approaches for determining which scan line should be considered the "first". I would not expect the spikes to be an issue; a bigger issue would likely be the relative timing of the horizontal and vertical sync pulses. If a projector uses the state of the vertical sync line on the falling edge of a horizontal sync pulse as its cue for whether a particular scan line is "the first", either waveform should work. If it samples vertical sync precisely on the rising edge of horizontal sync, the first would work but the second would be problematical (since the vertical sync could appear to happen before or after the horizontal). If it tries to avoid problems with the second by slightly delaying HSync internally, then the state of VSync should be well-established in either case well before it's sampled. If, however, if delays VSync, then it would be possible that in the first case it might sample VSync signal just as the change is propagating through the delay circuit. This could potentially cause one scan line of vertical positioning jitter.

In practice, I would expect most modern digital projectors to determine at what point within a scan line vertical sync seems to change (it should be consistent) and then select some other point in the scan line to sample it. On the other hand, I have certainly seen projectors which have more trouble than it would seem they should with sync signals that aren't exactly "perfect", so it's hard to guarantee that any deviation from the norm wouldn't cause problems with some equipment somewhere.

\$\endgroup\$
1
\$\begingroup\$

Upon redesigning VGA output for HSYNC and VSYNC to be in different process (enabling them to be simultaneous if they have to be) we found that the 850 ns is the cause. There was a color problem too (impedance mismatch) but the delay is what was causing the problem.

\$\endgroup\$
0
\$\begingroup\$

Suggestion: Regarding your hypothesis that the vertical sync pulse goes low "too early", you could make a very simple circuit to check this. With two gates, and an R-C delay in between, you can create a delayed version of VSync. Use a variable R to adjust the delay. Add a diode to delay just one edge. A 2/4 of a 4093 or 2/6 of a 74AC14 would be good candidates as they have Schmitt trigger inputs, so work more cleanly with analog-ish input from the R-C "analog" delay.

With minimal additional logic, you could compose your own VSync pulse that looks more like the one that works reliably.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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