adrv9002 LO change is very slow

In Vivado the ARM SPI clock is set to 187.5MHz, so this should be fast.
I am not sure if the driver sets the clock to a slower frequency?

Thanks

You are not bound by SPI here. When changing the LO by 100 MHz from an original point the part must be recalibrated. This can take some time. See page 86 of the user guide.

-Travis

You cannot disable this calibration since the PLL driving the mixer will not lock.

The only alternative is to use fast hopping but this is not supported in the Linux driver yet.

-Travis

Thanks Travis,

Is there an estimated time when fast hopping will be supported in the driver?

Changing LOs can indeed take some time.. On top of having to re-lock the PLL, the port also has to be moved to the calibrated state and then back to rf_enabled. Moving it back to rf_enabled can also take some time but way less than the 200ms (+/- 5ms; can also depend on the loaded profile). As Travis said, the only alternative is fast hoping but unfortunately, I still don't have an estimation on when it will be supported...

- Nuno Sá

Hello Nuno,

When you stated the PLL port has to be moved to the calibrated state, are you referring to in_voltage0_ensm_mode?

If not, what should I be changing when changing the LOs?

Is it fine just to change the RX1_LO and not the others, since I am just receiving?

As for the profile, I have set up 40M bandwidth and tried different sample rates ranging from 40.96M to 62,5M.

Is there a profile configuration that has a 40MHz bandwidth, that would tune faster, without the hopping?

Thanks very much

swie said:

When you stated the PLL port has to be moved to the calibrated state, are you referring to in_voltage0_ensm_mode?

Yes, but that is done by the driver under the hood so no need for you to do anything...

swie said:

Is it fine just to change the RX1_LO and not the others, since I am just receiving?

That's a tricky question as LOs are not obvious. Although in theory (assuming that you are only changing RX1_LOs and no other controls) only changing RX1_LO is fine. However, If you are using a FDD profile, it's best practice that you also change RX2_LO together with RX1_LO... If you prefer not to do it, then you should move in_voltage1_ensm_mode to calibrated before starting the RX1_LOs settings.

If the profile is TDD, for safety, you should TX1_LO to be the same as RX1_LO although this will only matter if you change a tracking calibration in RX1. Alternatively, on a TDD profile, you can just disable the TXs as you just want to receive.

This commit description explains the reasons behind this...

swie said:

Is there a profile configuration that has a 40MHz bandwidth, that would tune faster, without the hopping?

Don't think so...

- Nuno Sá

one more question...

Will TDD or TDM_FDD modes tune faster than FDD mode?

Not really sure as I never measured it. You can always try it

- Nuno Sá

The frequency hopping works on the TES software.
Since this is not supported in the driver yet, how does this work?

Is there different code on the Zynq Arm?

Is this code not using the meta-adi driver?

Thanks

There are API functions related to fast hopping modes that are specific to the transceiver. This API is used by the driver but the top level IIO driver does not expose them yet. You cannot access the API directly in Linux, but this can be done in No-OS where you only get the API not the driver.

The source API is available here: https://www.analog.com/en/design-center/landing-pages/001/transceiver-evaluation-software.html

When using the API directly you will need to manage state on your own.

TES also has specialized HDL to help demonstrate fast hopping, but you will need to ask in the TES forums about this IP and related software.

-Travis

I found that if I set the in_voltage0_ensm_mode to calibrated

Then tune the RX1_LO

The tune time is quite fast.

However, setting  in_voltage0_ensm_mode back to rf_enabled takes a long time.

Is there a parameter maybe in /sys/kernel/debug/iio that I can set to speed this up?

Also, I noticed that the pll_status is in the unlocked stated until I switch the ensm_mode back to rf_enabled. After that it reports locked.

Thanks again

I found that if I set the in_voltage0_ensm_mode to calibrated

Then tune the RX1_LO

The tune time is quite fast.

However, setting  in_voltage0_ensm_mode back to rf_enabled takes a long time.

Is there a parameter maybe in /sys/kernel/debug/iio that I can set to speed this up?

Also, I noticed that the pll_status is in the unlocked stated until I switch the ensm_mode back to rf_enabled. After that it reports locked.

Thanks again

Is there possibly a way to change the RX1_LO loop filter parameters via /sys/kernel/debug ?

or enable/disable calibration after changing the RX1_LO? Via sys/kernel/debug?

swie said:

However, setting  in_voltage0_ensm_mode back to rf_enabled takes a long time.

In this case, I believe the PLL will only retune when you move the port to rf_enabled which will add more time to an operation that already takes some time...

swie said:

Is there a parameter maybe in /sys/kernel/debug/iio that I can set to speed this up?

No, if we had that we would already have pointed you to that paramater instead of saying that fast hopping is the way to go .

swie said:

Is there possibly a way to change the RX1_LO loop filter parameters via /sys/kernel/debug ?

Currently no...

swie said:

or enable/disable calibration after changing the RX1_LO? Via sys/kernel/debug?

Not sure I'm following this question... What do you mean by enable/disable calibration? Don't think that there's anything you can do to speed up LOs other than fast hopping

- Nuno Sá

Hi Nuno,

I put some code in adrv9002.c and adi_adrv9001_radio.c to see what was taking the most time.

The call to adi_adrv9001_channel_to_state is what takes 90+% of the time in the function adrv9002_phy_lo_write. Both calls take a long time (that is taking out of rf_enable state and putting it back in this state).

Since I am only receiving and have the device configured so that only RX1 is set up, can I comment out the adi_adrv9001_channel_to_state function calls in the function adrv9002_phy_lo_write. And also comment out the check for the state being either calibrated or standby in the function adi_adrv9001_Radio_Carrier_Configure_Validate ?

I just want to make sure that I would not damage the radio if I do this.

Thanks again for the help

Hi Guys any thoughts about the previous post, regarding eliminating the calls to adi_adrv9001_channel_to_state ?

Thanks