AD9361 External Reference Issue

Did you generate the profile with these required clock frequencies and then tried loading the same profile and initialize the chip?

Also have you run the  interface tuning successfully? Refer to the below link:

https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/interface_timing_validation 

Yes the device tree has been modified as follow : 

clocks {

                              ad9361_clkin: clock@0 {

                                            compatible = "fixed-clock";

                                            clock-frequency = <0x3B9ACA0>;

                                            clock-output-names = "ad9361_ext_refclk";

                                            #clock-cells = <0>;

                              };

               };

/*                                                       BBPLL     ADC        R2CLK     R1CLK    CLKRF    RSAMPL  */

adi,rx-path-clock-frequencies = <768000000 48000000 24000000 1200000 1200000 1200000>;

So the chip is initialized with this configuration.

The interface tuning as also been run with no default. But what we see on a scope is that the 62.5 MHz Ref signal and the AD9361 output data clock are not syncronous. Are you able to reproduce this behavior on your side ?

Thanks

We first noticed this problem few months ago and the person who did the measurement is not available to make some plots in the next weeks. But I can confirm that on the plots you would see for a 40 MHz REF_CLK  a synchronous trace with DATA_CLK and one trace sliding in time from the other with a 62.5 MHz REF_CLK. It would be great if you could try  the two configurations with the FMCOMMS3 EVB in your lab and see the phenomenon in live.

Yes we are able to receive with the chip even with this default but we really need to understand what's going on for a synchronous multi chips - multi channels application.

Hi Srimoyi,

You will waiting for some plots to continue the support of our problem or are you able to confirm the phenomenom with a experimentation in your lab ?

Best Regards

We are trying to reproduce this on our bench. Will get back to you

Thanks a lot ! We are looking forward to get your feedback...

Have a nice day !

How are you measuring the delay between REF_CLK and the DATA_CLK when they are non integer multiples of each other?  When the REF_CLK and DATA_CLK are integer multiples, the delay difference between them remains constant over time. For integer multiple frequency signals, one signal will complete n*full cycles within one full cycle of the other signal. We measured and confirmed the same on our eval board. But when they are non integer multiples, the starting point of the two signals will never align w.r.t each other, which will lead to incorrect delay measurements.

It would be good if we can get some plots and steps on how this measurement is done, so that we can reproduce the same on our eval boards.

Hello,

I describe our settings : A signal generator delivering the REF_CLK is connected to both the FMCOMMS3 board and one channel of a scope. Another channel of the scope is connected to the DATA_CLK signal. The scope is in the trigger mode on the REF_CLK signal. The REF_CLK frequency is either 40 MHz or 62.5 MHz (the clock- frequency parameter is modified as required for each case in the device tree).The DATA_CLK frequency stays at 12 MHz as define in the clock path. The chip is initialized in each case and we look at both channels on the scope. What we see is that for a 40 MHz REF_CLK, the two traces are stable on the scope. For 62.5 MHz, the REF_CLK displayed on the scope is stable because this is the trigger signal, and the 12 MHz DATA_CLK signal is sliding in time.
We are not trying to measure a delay between the two traces but just want to see if they are synchronous, which is not the case for REF_CLK = 62.5 MHz.

You indicates that REF_CLK and DATA_CLK must be integer multiple for a good measurement but it is never true in our two cases.

The ratios are 40/12 = 3.33 or 62.5/12 = 5.21. For the first ratio the two traces are stable on the scope but not for the second as if the BBPLL chain that deliver the DATA_CLK was not locked. We expect to see two stable traces for both measurement. Do you agree with that ?

I try to send you a small vids of what we see as soon as possible.

Best Regards

Instead of vids, I send you two screen plot of the scope.
On the first image you can see on the upper trace the 48 MHz DATA_CLK signal (4 x RSAMPL in 2R/2T LVDS Mode) which is the trigger signal and on the lower trace, a 80 MHz REF_CLK. As you can see in this case, the traces are synchronous.
On second image, we use a 62.5 MHz REF_CLK. In this case, the lower trace (REF_CLK) is impossible to be clearly displayed because it is asynchronous with DATA_CLK.
Normally we should see the same kind of trace than the first plot for REF_CLK with just less period.
This is why we conclued that for a 62.5 MHz REF_CLK, there is a problem of locking in the BBPLL path.
Do you confirm on your side ?

We tested the same on our eval board and was able to see the same behavior. The DATA_CLK is sweeping in time with respect to the REF_CLK signal, when they are not integer multiples of each other.

We have not seen customers facing any issue because of non integer multiples as the PLL's are fractional PLL's. Are you facing any issues with data demodulation when they are not integer multiples?

No, we do not have problem in a single channel configuration. Recently we have been able to do some measurments on our own board equiped with 2 x AD 9361 drived by the same REF_CLK. We do not see any asynchronism between the two DATA_CLK signals ! 

It seems we were misled by the measurement method on the FMCOMMS3 board.

At any rate, thanks for your support ! 

Ran_63 said:

We do not see any asynchronism between the two DATA_CLK signals ! 

Yes, DATA_CLK 's between multiple boards will be synced w.r.t each other after the SYNC signal turns high because of the baseband multichip sync feature.

Ran_63 said:

We do not see any asynchronism between the two DATA_CLK signals ! 

Yes, DATA_CLK 's between multiple boards will be synced w.r.t each other after the SYNC signal turns high because of the baseband multichip sync feature.