Post Go back to editing

Frequency offset between input clock and generated signal on FMCOMMS3

Thread Summary

The user encountered issues with frequency locking a 2.45 GHz carrier to a 40 MHz reference clock on a ZCU105 with FMCOMMS3 daughterboard. The final solution involved bypassing the MMCM for the AD9361 reference clock and using a low-phase-noise external source or jitter-cleaning PLL. The AD9361's internal PLL cannot compensate for reference clock jitter, which was confirmed through additional tests and measurements.
AI Generated Content
Category: Hardware

Hello,

I am developing a system that uses as a prototype a ZCU105 with a FMCOMMS3 daughterboard. For my application, I need the generated carrier to be frequency-locked to the reference clock fed into the FMCOMMS3.
If I take an Ettus B210 board and feed it an external 10 MHz reference, I can observe on the oscilloscope that a sinusoid with a 2.45 GHz carrier and the 10 MHz input are perfectly locked in frequency. However, this does not seem to be the case with my FMCOMMS3 setup.
I first noticed this issue when transmitting a sinusoid at a frequency exactly equal to one quarter of the sampling rate (i.e., 4 IQ points per period when I sample it) from one FMCOMMS3 and receiving it on another. In a wired loopback (not digital), I observe four point clusters --- somewhat messy, but fixed in position. However, when using two boards with an external 40 MHz reference clock, I see a big circle.
Again, the same test with two B210 boards gives four (significantly smaller) point clouds.
Interestingly, if I reduce the carrier frequency from 2.45 GHz to 245 MHz, the FMCOMMS3 constellation again shows four large, somewhat distorted point clusters instead of a circle.

What am I missing?

Thanks a lot in advance!

Best regards,
Rob

  • HI  

    Thanks for your post.

    It would be helpful. if you can post with spectrum plots to understand the issue clearly.

    Regards,

    SJ

  • Hello,


    Thanks for your reply!
    Here's what I plot from the retrieved data.

    (I have a sampling rate of 10 MHz, so the sinusoid is at 2.5 MHz).

    Best,

    Rob

  • Dear SJagini,

    After quite a lot of investigations, it seems that the issue derives from the jitter on the 40 MHz reference clock. We generate the 40 MHz using an FPGA which is fed with a 10 MHz reference clock, and if we pass the generated 40 MHz into an external jitter cleaner, then everything works as expected, while feeding it directly makes the 4 points corresponding to the samples sinusoid move so much that they look like a circle when acquired.

    My question: is there a way to configure (using the NO-OS driver) the internal PLL to compensate for the increased jitter on the reference clock?

    Thanks a lot for any help!

    Best regards,
    Rob

  • HI  

    Unfortunately, the AD9361’s internal PLL cannot compensate for reference clock jitter—it assumes a reasonably clean input. The BBPLL and RF PLLs multiply the reference frequency, so any jitter on the 40 MHz input is amplified, which explains why your constellation collapses when the reference is noisy. This explains at lower freq it works and goes worse at higher freq.
    AD9361 expects a reference clock with low phase noise and jitter. Jitter on the reference clock translates directly into LO phase noise and sampling clock instability, degrading EVM and SNR.

    You may have to use external jitter cleaner or clock synthesizer. alternatively, in most application they yse low-jitter reference clock like External XO or TCXO with better jitter spec.

    Regards,

    SJ

  • Dear SJagini,

    Thanks for your quick reply!
    Actually, from the latest measurements, it seems that the jitter of the "non-working clock" is better than the "working" one. So we're totally puzzled... We keep investigating but we're running out of options... Disappointed

    I'll keep you posted. Thanks again and have a nice week-end!

    Best,
    Rob

  • Dear SJagini,

    As mentioned above, we continued performing our tests. We compared the results we obtain when using a clock generator (in which case everything works fine) with the case in which the reference clock is generated by a MMCM inside the FPGA (in which case nothing works as expected). However, when we compare the reference clocks in the two situations, no true difference emerges in terms of jitter, voltage levels, etc.

    We figured out that the rotation we observe is not proportional to the carrier frequency --- we measured the jitter of the generated sinusoid at the carrier frequency and it is equal --- of course, if we plot the points, the period gets shorter for higher carrier frequency, and therefore the same amount of jitter makes the points visually "complete the circle". Filtering the reference clock (to have it sinusoidal), changing its frequency, etc. had no real impact.

    Is there anything we are overlooking?

    Thanks in advance and wishing you a great start to the new year!

    Best,
    Rob

  • Hi  

    Please bypass the MMCM for AD9361’s reference. And feed AD9361 XTALN from a low‑phase‑noise external source or a jitter‑cleaning PLL (e.g., AD9548) locked to your master reference. Keep the internal MMCM for fabric clocks, but do not use an MMCM output as the AD9361 reference. ADI explicitly recommends a high‑quality external oscillator/VCTCXO plus synchronizing PLL for master‑locked systems. [wiki.analog.com]
    To isolate the culprit and check the following:
    1. LO phase persistence test (divider effect):

      • Keep the same external reference.
      • Run with RF enable held (MCS RF enable), without turning off dividers, measure constellation stability. Then power‑cycle / re‑enable and re‑measure. If the rotation changes only across runs, that’s LO divider phase ambiguity. [ez.analog.com]
    2. Reference source swap at constant routing:

      • Route XTALN exactly the same way.
      • Source A: external low‑phase‑noise generator at a frequency that scales to ≈ 80 MHz internally.
      • Source B: MMCM output matched in amplitude/swing.
      • Capture baseband phase over time (short windows), and FFT the instantaneous phase to reveal close‑in noise/spurs. Expect more close‑in content with the MMCM. [analog.com]

    Regards,

    SJ

  • Hello SJagini,

    We finally gave up and modified the hardware to bypass the FPGA. Thanks again for your help!

    Best,

    Rob