1
\$\begingroup\$

I am developing a board which converts DisplayPort to LVDS. The LVDS is put through a PCIe switch and then fed to an APIX transmitter, which connects to the display.

There's a second video path going to this PCIe switch. If this path is active, I get a perfect image in the display.

https://www.youtube.com/watch?v=b9cWaxLYY4M

That video shows what I just wrote, starting with a nice image it gets really bad when I change to the DP source.

I think I have two seperate problems here. One is responsible for the "fringing" or jittering lines, and the other is responsible for the DP image being a few centimeters to the left and cut off. My main concern is the jitter, I think the position of the image can be adjusted by playing with parameters like front and back porch.

Here's a detailed view of my issue:

https://www.youtube.com/watch?v=O6tb6PG9xOs

The position of a view pixels seem to "jump around". The lines are ok and at their correct positions, but sometimes a line is longer than it's supposed to be and fringes appear to the right of the image.

Where shoud I start debugging this problem?

The PTN3460 is set to single LVDS, single DP lane, the resolution is 1280x480 at 60Hz. I also used these parameters:

  • pixel clock 40500Hz
  • hor active 1280
  • ver active 480
  • hsync width 15
  • vsync width 1
  • hblank width 86
  • vblank width 14
  • hpol neg
  • vpol neg
  • htotal 1366
  • vtotal 494

I also have these:

  • hblank start 1350
  • vblank start 480

But I am not sure what to do with them, because I am using the "EDID Generator" from analog devices to generate an EDID file. That EDID Generator is asking for:

enter image description here

I am not sure what to do with hor/ver sync offset and hor/ver border, and the unused hor/ver blank parameters, though.

I got the values from the machine that creates the working video output, shown in my first video, the one with the huge tiles.

There's another (commercial) board available, using the exact same EDID I get a clean image. The major difference between their board and mine is: They use HDMI, I use DP.

Where would I start debugging this thing? I have an oscilloscope with 2GS/s and 200MHz max, and a multimeter available.

\$\endgroup\$
  • \$\begingroup\$ It appears to me as a CM (line ripple) noise problem aggravated by differential signal changes with visible high contrast.. What CMRR do you have on your transmission lines? Does you finger CM capacitance shunting the DM pairs affect the results? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jan 15 at 18:09
  • \$\begingroup\$ Do you have the datasheet of your display panel? From there you should be able to know if it even requires HS and VS, and what are their polarities if required. Some panels only need DE to operate. In general, e.g. the sync offset means how much after end of active line the HS starts in the blanking area, and generally these parameters are not 0, so that HS pulse happens somewhere during HBLANK area, but not at the same edge. The VS offset is similar, sync line almost never happens right after active line, or right before active line, but somewhere in the VBLANK area. \$\endgroup\$ – Justme Jan 15 at 18:13
  • \$\begingroup\$ @TonyStewartSunnyskyguyEE75: I don't know how to measure CMRR. Touching any parts of the transmission lines does not affect the image at all, concerning neither the working nor the faulty path. The line lengths are matched < 0.01mm per pair, and among the pairs differ from 62.85mm (shortest, LVDS clock pair) to 66.25mm (longest, LVDS0 pair). The pairs have a distance of 0.15mm between positive and negative, and there's at least 1mm distance between the respective pairs. Even if it were crosstalk, it would affect the working path as well. \$\endgroup\$ – PhreakShow Jan 15 at 18:54
  • \$\begingroup\$ @Justme: No datasheet. The only information I got is taken from the working system. That's an LQ088K9RA02 panel. \$\endgroup\$ – PhreakShow Jan 15 at 18:56
  • \$\begingroup\$ I have seen a similar issue on Asus MOBO with certain cables and found adding CM capacitance to gnd altered the results that were content sensitive but did not fix the problem. Using a better cable 1 out of 3 new different style shld. cables tried, worked but marginal.. Yours is more aliasing gnd jitter between sync,line & other noise sources \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jan 15 at 18:57

Your Answer

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

Browse other questions tagged or ask your own question.