SN65LV1224B: Sync Lock

Hello,

Are you using a serializer (SN65LV1023A) to serialize the parallel data from the image sensor? A simple block diagram of your system would be helpful. Also, are you seeing the issue only on some units? How may devices had the issue and how many in total were tested?

Regards,
Yaser

Hello Yaser,

thanks for replay.

Total I have ~10 issue chip from few thousand :)

I using SN65LV1224BRHBT deserializer  without a SN65LV1224A. The sensor itself work as serializer

Below my schematic diagram:

Hello Yasser,

Both clocks are MEMS type and the same P/N: ASEM1-27.000MHZ-LC-T with 50ppm.

Remigijus

Hello Remigijus,

Can you please check LOCK signal on SN65LV1224B? Does it get deasserted when the issue happens? Are you connecting LOCK output of SN65LV1224B to SYNC input of sensor to send sync patterns?

Regards,
Yaser

Hello Yaser,

 I checked received LVDS signal noise margin time on scope eye - 1.425ns. That isn't near the limit. 

In previous days i was able to catch loss of sync lock, but on LVDS signal i didn't see anything strange.

The system know when LOCK is lost, but there isn't enough time to send over I2C line to image sensor to initiate sync pattern send.

Remigijus

Hello again,

Today I rechecked the condition on receiver LVDS line when sync is lost:

Hello Remigijus,

Have you tried to swap units on the platform that exhibits the issue? If not, please try that. Basically, swap a unit that works fine with a unit that has the issue to see if the issue follows the unit.

Regards,
Yaser

Hi Yaser,

Thank For your Time!

Two more time of resoldering will not affect the unit inside? I can try, but the heat can add one more unknown "x" to the problem. 

The problem came from after last batch of ordered deserializers (it begins from 2018 spring). The system is so simple not to work: power, clock, few resistors and LVDS. 

Now I have lot of similarly behaving unit. And more time I sped on looking to them or waiting, more unit I can throw as bad unit.

Just replace them all would be very great and easy. But this preferable for few unit and still it can't lead to final answer - where is the problem: poor design, poor component selection of just simple component failure (maybe counterfeit).

Thanks!

Hi Remigijus,

That's what I am trying to find out - if it is a quality issue with specific devices. Please try the swap. Thanks.

Regards,
Yaser

Hello Yaser,

I didn't change the deserializer, but make swap with clock source of deserializer (not for the image sensor). Simply take few shots:

1. take new unit of 10ppm clock -  the problem was gone, the sync was always locked;
2. bring back the same clock - the problem came back too;
3. Take one from very old unit - the problem was gone as with better one.

In the datasheet there isn't much information about REFCLK clock of deserrializer. What jitter must be? How hard I care of Cycle-to-Cycle jitter?

I tried to measure some timing statistics information on both clock.

When compare 10ppm(C3 in first plot) to 50ppm(C3 in second plot), the difference for  cycle to cycle jitter (the distance between to cycle period was 100 period) is:

• lower stdev fo 10ppm (C3 in f)
• lower range of deviation for 10ppm to (C3)

First plot:

second plot 

Hello,

That's interesting. Good progress. However, I am not sure I follow your comparison. The 2 plots seem to show different frequencies.
At any rate, I don't have a specific jitter requirement for the REF_CLK, but I believe it should be similar to TCLK. Can you please verify that the clock actually meets all the requirements in the table?

Regards,
Yaser

Hi Remigijus,

I haven't heard back from you for a while. Any update? I will close the post, but please feel free to reply to open it again.

Regards,
Yaser

Yes, this can be closed.
First of all, I wand to collect more statistical data of jitter and other variatinmg parameter over the time