DS92LV0412SQE, DS92LV0411SQE and DS15BA101SDE, DS15EA101SDE

Hi Erik,

If you switch transmitters does the problem go away?

Here are a few things which I think can be simplified.

The LV0411 VOS spec aligns with the BA101 input common mode specification.  I would remove R30, R31, R162, and R181. Change C74 and C98 to 0 ohm resistors.  RVO pin on the BA101 should be 953 ohm resistor.

R121 and R123 are not needed for 100 ohm twisted pair cables.

You have 1uF caps on the receive side of the cable.  I do not know what type of scrambling is being used, but usually the caps on the Tx side would be the same value.  Your schematic has 100nF on C132 and C96.

Regards,

Lee

Hi Lee

thanx for prompt reply.

I have the following comments etc.

" I would remove R30, R31, R162, and R181. Change C74 and C98 to 0 ohm " Agree, R30, R31, R162, R181 are not mounted.

We have changed C74 and C98 as you state.

All AC transfer caps are 1uF.

R192 was not mounted on the PCB (trasmitter), we have mounted this, and it has improved overall performance.

R121 and R123 are also removed.

As for the boosters...it seems that C74 and C98 on the transmitter side have positive effect on the signal quality. BUt..we wonder why C65 and C62 are needed on the receiver end. ( we have tried without..bad result nothing worked)

Also C55 and C64 are still mounted. If we read the spec. correct..it seems that running 8 bit, 10 bit or 18 bit (which we do) we can run the chipsets in DC mode = no need for AC transfer capasitors. Running 24 bit however will require this. Can you confirm this.

So right now we are running the signal as: LV0411 =>DC=> BA101 => AC=> EA101=>AC=> LV0412.

Best reg 

Erik

Hi Eric,

C65 and C62 are needed because the LV0412 RIN pins are biased to 1.2V, the EA101 output common mode is ~ 2.9V.  The caps are needed to keep these parts isolated from one another.

I would keep C55 and C64 installed to ensure any GND differences between the boards are isolated via the caps.  Otherwise the protection diodes could forward bias and cause problems with the EA101 receiver.

Regards,

Lee

Hi Lee

We have made the changes and it has improved overall signal quality = no flicker on the 7" 800x480 /18 bit color TFT.

However we still have a minor issue that we would like you to comment on.

As explained our "transmitter" is based on Intel based graphic controller and the TI chipset w. booster.(aka the "controller") At the other end (receiver) we use the TI chipset and a Innolux 7" 800x480 WVGA TFT. This part is our "HMI"

We have noticed that one HMI can work flawless on one controller, picture is perfect no flicker. Then if we change HMI we sometimes get the flicker problem again. Flicker = when the lock signal is lost. (LOCK pin 27, )

More less..we have to "marry" the controller and the HMI and test them together to be sure we have flawless picture on the TFT (which in real life is not a option we can use..)

So can you recommend some adjustments we can try out ? it's like small variations on the HMI (component tolerances etc) makes them less tolerant to what they receive from the controller.

We use up to 30 mtr of CAT6S (double shielded) cable but problems are found on even 5 mtr. cables.

current settings on the receiver: SCC0,1,2 , CONFIG 0,1 and LFMODE all low. VODSEL and MAPSEL = high.

We have to admit..that in our current setup DE-EMPH is left floating, we will try out the suggested values to learn if this could remove our flicker problem.

Again..any suggestions to what we should try out are welcome.

Best reg

Erik

Hi Erik,

I am not sure that increasing de-emphasis will improve the signal, since the DS15BA101 is placed right after the DS92LV0411 on the transmitter side, and therefore the DS15BA101 will "cancel out" the de-emphasis effect of the DS92LV0411 at the DS15BA101 CML output.

Have you tried increasing the EQ gain? You can try out setting EQ = 1 for the long cable case to see if a higher amount of gain is more helpful. Alternatively, if you have SMBus access, you can access the Deserializer Reg 0x03[7:5] for more granular EQ level control to try improving the quality of the input signal. It may be possible that your current system is passing with marginal eye quality on some units and an extra bit of boost in the deserializer may help.

Regards,

Michael

Hi Michael

We are still troubleshooting our design. We have just made 6 x Rx pcb's (HMI side) and we still have variations problems as decribed ealier.

You mention we could try to set the EQ = 1, I only find EQ mentioned on the Rx side (DS92LV0412 pin 28) 

Control and Configuration — STRAP PIN
EQ 28 [PASS] STRAP EQ Gain Control of Channel Link II Serial Input
I, LVCMOS EQ = 1, EQ gain is enabled (~13 dB)
w/ pull-down EQ = 0, EQ gain is disabled (~ 1.625 dB)

In the reference design found here:

http://www.ti.com/lit/ug/snlu069/snlu069.pdf 

Hi Erik,

Yes, I was referring to the EQ on the DS92LV0412. My thought process is that any de-emphasis that you may have added from the DS92LV0411 could be nullified by limiting output of the DS15BA101 cable driver. My thought therefore was to use the DS92LV0412 Rx to help with restoring signal integrity over the loss that the cable causes.

By setting EQ = 1, I was referring to EQ = 001'b in deserializer Reg 0x03, via SMBus communication for more EQ gain granularity as opposed to setting the pin strap:

Are you able to get SMBus access to the device? This way, you could experiment with different amounts of EQ gain on the deserializer to see if this helps with eliminating bit errors.

Thanks,

Michael