Post Go back to editing

Effect of REF_CLK_IN frequency on RF PLL phase settling time when frequency hopping

Category: Hardware
Product Number: ADRV9009

Hello

We are measuring phase accuracy across three ADRV9009 devices (6 channels) while operating in frequency hopping mode. We are seeing similar results to those reported here:

ez.analog.com/.../508152

Specifically, we see up to 30ms for the RF PLL phase to settle to a stable value when operating in frequency hopping mode at 5.8GHz. We are also using GPIO for the frequency hopping trigger.

As detailed by Vanitha in the post above, this is because the RF PLL phase synchronisation is a slow loop and therefore takes time to settle:

"It is not possible to achieve phase sync in fast hop mode, with only 2msec of convergence time. RFPLL phase sync is a slow loop and hence the algorithm will not converge within 2msec of time. We have verified the phase sync in FHM using SPI mode trigger to hop to frequencies  in JESD024FSM framework. SPI mode, takes 30msec or more time for reads and writes and hence we were seeing phase synchronization. Using FHM in pin mode, hoping should be faster but we don't have data on phase synchronization time."

According to UG-1295 page 114, the phase synchronisation happens across multiple REF_CLK_IN cycles to ensure that the RF PLL does not become unlocked.

We would like to find out if there is any way to reduce the RF PLL phase settling time when running in frequency hopping mode.

My questions are as follows:

1) If REF_CLK_IN is used as the time scale in performing the RF PLL phase adjustment, is it possible to speed the process up by running at a higher REF_CLK_IN frequency? For example, we are currently using a 245.76MHz REF_CLK_IN. According to the ADRV9009 datasheet, the REF_CLK_IN frequency can go up to 1GHz, so would we see any reduction in the RF PLL phase synchronisation settling time by using a 983.04MHz (245.76MHz x 4) REF_CLK_IN frequency instead?

2) In frequency hopping, the RF PLL loop bandwidth is set to 600kHz. According to the ADRV9009 Talise Linux driver, I can see that this can be set to 750kHz maximum. Would we see any reduction in the RF PLL phase synchronisation settling time by increasing the RF PLL loop bandwidth to 750kHz when frequency hopping?

Note that we are currently configuring the ADRV9009 devices for TAL_RFPLLMCS_INIT_AND_CONTTRACK mode. We tried TAL_RFPLLMCS_INIT_AND_SYNC and TAL_RFPLLMCS_INIT_AND_1TRACK modes but unfortunately we didn't see much difference in the time taken for the RF PLL phase synchronisation to stabilise across the multiple devices.


Any other recommendations or suggestions would be greatly appreciated.

Thank you.
Gavin

  • o would we see any reduction in the RF PLL phase synchronisation settling time by using a 983.04MHz (245.76MHz x 4) REF_CLK_IN frequency instead?

    Yes this might help in reducing the RF PLL phase synchronization settling time .

    Can you please share us the setup diagram of how you are testing ?

    Are you able to achieve the phase synchronization with 2 ADRV9009 devices ?

     RE: ADRV9008_1 multichip phase  sync lost after frequency hopping 

  • Hello Vanitha

    Thank you for responding to my questions.

    To confirm, I am using the JESD204B FSM. If we slow down the frequency hopping, we can see that the relative phase does stabilise. Also, if we do not perform frequency hopping then the phases are stable and repeatable across power cycles. I think this shows that the JESD204B FSM and multi-chip phase synchronisation is working as expected.

    Here is a block diagram of our test setup:

    The first ADRV9009 device generates an output tone to a splitter. This is the calibration tone. The splitter then sends this tone to all the RX inputs of the three ADRV9009 devices. The FPGA captures multiple blocks of data from each RX. An FFT is performed. At a specific bin in the FFT (corresponding to the location of the calibration tone), the phases of the channels are compared relative to ADRV9009 1 RX1 across the multiple block captures.

    This is plotted below:

    The green plot is ADRV9009 1 RX2 compared to ADRV9009 1 RX1. As you can see, within an ADRV9009 device, relative changes in the LO phase are not picked up because the same LO is used for both RX1 and RX2. The other plots show how the phases of the other ADRV9009 devices settle relative to ADRV9009 1. The total period across all these block captures is 25 ms. In this specific test case you can see that the LO multisync phase stabilises within roughly 10 ms. The total phase variation is 4 degrees at 5.8GHz LO frequency.

    I will test if increasing the REF_CLK_IN frequency will reduce the time taken for the multisync phase alignment to stabilise.

    Thank you.

    Gavin

  • Try with increasing the REF CLK frequency and see if it reduces the RF PLL phase synchronization settling time.

  • I can now confirm that increasing the REF_CLK_IN frequency has no major impact on the time taken for the phases to stabilise across the three ADRV9009 devices.

    I wasn't able to test with 983.04MHz (245.76MHz x 4) REF_CLK_IN because the ADRV9009 devices would fail a calibration step during the Linux boot up. But I was able to test with 491.52MHz (245.76MHz x 2) REF_CLK_IN. 

    Although this is only two times higher frequency, it should have at least cut the phase settling time in half if the ADRV9009 multi-chip phase synchronisation depended solely on the REF_CLK_IN frequency. But since it made no noticeable impact, I can only think that the ADRV9009 ARM software takes the frequency of REF_CLK_IN into account.

    Would you expect any difference by setting the RF PLL loop bandwidth to the maximum (750kHz)? What would be the drawback of making this change?

    Any other ideas or suggestions would be greatly appreciated.

    Thank you.