Post Go back to editing

AD9361 External Reference Issue

Category: Hardware

We are using the FMCOMMS3 board with an external reference frequency of 62.5 MHz. All the modifications on the hardware and the device tree have been done as required.
At power up the path clock frequencies is as follow :
BBPLL 768 MHz, ADC 48 MHz, R2CLK 24 MHz, R1CLK 12 MHz, CLKRF 12 MHz, RSAMPL 12 MHz.
When we display the external reference and the DATA_CLK signals on a scope we observe that the two signals are not synchronous. One is shifting in time regarding the other. The register of the BBPLL indicates that the PLL is locked.
May we have some support to understand where the problem come from ?
Thanks a lot for replie !

  • 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: 

  • 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 ?


  • Are you setting the TX and the RX path rates same?

    If you change the ref_clk to say 40MHz and then initialize the chip with the same path rates, are you still seeing the same shift between DATA_CLK and the REF_CLK?

  • Yes, RX and TX path are set the same.

    When we change the REF_CLK to 40 MHz and initialize the chip with the same path rate, there is no shifting between DATA_CLK and REF_CLK.

    This is why what we see is puzzling us a lot.

    Please help us to understand.

    Thanks for support.

  • Sorry for the confusion in my previous reply.

    Can you share with me a plot a of the REF_CLK w.r.t the DATA_CLK when the issue is seen vs when the issue is not seen? Also, are you able to transmit and receive successfully using the chip?

  • 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.