DS90UB913A DS90UB914A Yield Issues

Hello,

What inductors are you using - the Coilcraft 100uH and 4.7uH in series as specified by our power over coax (PoC) app note on ti.com?

Depending upon the system application, typically the back channel errors that you are seeing can be improved by adding a ferrite bead to the PoC filter networks. The bead should be put in the same place as R38 in the below diagram. The bead should also be placed on both the 913A AND 914A PoC filter networks.

The ferrite bead that we recommend is the BLM18AG102SN1 by Murata. The app note on the website is currently being updated to include this bead.

Regards,

Sean

Hi Sean,

We have ordered the parts you recommended and will see how the system performs when they arrive.  We have no choice but to cut and jump in order to insert the ferrite bead.  Hopefully, the jump won't effect the 1.4GHz signal.

The parts we are using are:

• RXer Side
  • L9: 5.6uH, ABRACON, AISC-1210H-5R6N-T
  • L2: 100uH, ABRACON, ASPI-8040S-101M-T
• TXer Side
  • 4.7uH, Taiyo Yuden, BRC2012T4R7MD
  • 100uH,Taiyo Yuden, BRC2518T101K

Thank You,

Andrew

Hi Sean,

Another piece of useful information is that when we use longer cables, we are seeing the yields reduce further. Specifically, we are using 18" and 36" and 36" causes more issues.

It is really hard to imagine this working at 15ft. Any tips on signal amplification?

Thank You,
Andrew

Hi Andrew,

This setup does work at much longer cable lengths using the Coilcraft inductors mentioned in our app note.

Please take a look at the impedance (Z) vs. Frequency graphs of the Abracon and Taiyo Yuden inductors you are using in the power over coax networks. Make sure that these graphs follow the recommendations given in our app note on the web (this app note will also have minor updates to it in the next few weeks). Also, why do both networks have different inductors? Typically we recommend keeping the inductor networks identical on both the RX and TX side to minimize impedance matching issues.

The ferrite bead will help a lot with the I2C issues that you are seeing but having inductors that match our app note recommendations (impedance vs. frequency thresholds; specific margins for return loss characteristics) are also critical.

-Sean

Hi Sean,

We will move to the recommended inductors tomorrow when we get the shipment.  From the beginning we have been following a combination of reference design TIDA-00098 and the DS90UB913A-Q1 datasheet.  My team also had a reference design from somewhere, but it is clear the design is not perfect.

I can see from snlu135a.pdf that the TX and RX designs should be identical.

I will check in after the rework tomorrow.

Thank You,

Andrew

Hi Sean,

We noticed an inconsistency in the AppNote and the UG for the eval kit.  The AppNote shows 4.7uH and 100uH whereas the eval kit UG shows 100uH and 5.6uH.

Please see page 5 here:

http://www.ti.com/lit/an/snla224/snla224.pdf

Please see pages 21 and 24 here:

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

Our idea is to move our designs to 5.6uH and 100uH with PNs:

100uH: BRC2518T101K

5.6uH: BRC2012T5R6MD doesn't exist. 

So, we will try the Coilcraft parts in the eval kit:

100uH: MSS7341-104MLB

5.6uH: 1008PS-562KLB

We will also try:

100uH: BRC2518T101K

4.7uH: BRC2012T4R7MD

Thank You,

Andrew

Hi Sean,

First, we matched the 4.7uH and 100uH inductors on both sides. We saw marginal improvement. Then, we ordered the coilcraft parts, they will arrive today. Finally, we tried an even longer cable made from RG58 and it worked perfectly. After seeing this result, we returned to the unmodified boards with the longer RG58 cable and are seeing improved results.

I did a little research and found that at 1GHz RG174 has a transmission loss of about 30db/100ft whereas RG58 has a transmission loss of about 20db/100ft. Seeing as we were using RG174 cables of 18" and 36" and RG58 of 60" I'm not so sure that cable specs are real issue.

I did further research and learned that RG174, RG316, and similar tiny center conductor cables are harder to assemble properly and therefore, especially with less expensive suppliers, may not meet specifications. In fact, the cables we have, despite being RG174, are not specified to frequency. I wonder what the results could be with a properly specified "thin" cable (RG58 is notably larger).

Is there a recommended cable type? What cables do you use in the lab?

Thank You,
Andrew

Hi Andrew,

RG-174 as you found out, only specs certain things such as cable construction. What RG-174 DOES NOT SPEC is the thickness of the shielding (ground sheath) inside the cable. The thicker the shielding, the more robust the cable and the better chance that the cable won't be causing your system issues (i.e. signal reflections, attenuation, etc.). Many different manufacturers make RG-174 cables as this is a standard; we have used longer RG-174 cables from Pasternack and Delphi with success. However as stated above, some RG-174 cables will be a cut above the rest due to the thickness of the ground sheath.

Since 913A and 914A are automotive qualified devices, the type of cable that we recommend is also automotive grade (i.e. provides robust ground shielding inside the cable). The cable recommended is the Leoni-Dacar 462 coaxial cable with Rosenberger Water-Blue FAKRA jacks on each end.

-Sean

Hi Sean,

Thank you for your support over the summer.

We have more data to share with you and it seems we need more help. After experiencing good yields in prior runs, we went ahead and made 96 cameras (imager boards and serializer boards in a stack design, based off of this: www.ti.com/.../TIDA-00098). From 96, sets we have 72 good cameras systems. Of the 24 bad sets, the imager board is ok (we can mix and match boards).

So it seems we have 24 bad out of 96.

The issue we are seeing is that the I2C back channel is non functional. We have investigated the HW extensively and cannot find a difference between the functional and non functional SERDES pairs. We think that this has to do with SNR.

Questions:

1- Is the external clock and PLL needed to lock, sync, and communicate over I2C on the link? Could it be that on bad systems the external clock is out of spec which causes back channel issues?

2- We have found that the AGC always ends at 0x0 yet the range is 0x0f-0xff. Is 0x0 a valid AGC setting?

3- Since our HW is fixed, is it a reasonable idea turn AGC off and use a static setting?

4- It seems that even with bad boards, after a long, long, long time, we can configure the device and we find that the video is ok. So this is clearly a mid-ban issue. Is it possible to amplify the mid ban only?

Do you have any new ideas?

Thank You,
Andrew

Hello Andrew,

Please email me at s-thornton@ti.com.

-Sean

Hi Sean, TI Team,

We have created a new revision of the HW and are seeing a significant reduction in performance again. In this HW revision, we have followed the guidelines above.

Can you please redouble your efforts in helping us with this issue?

Thank You,
A