FHM Calibration Resolution

ahelak said:

What I am looking to understand better is:

1. What calibrations are performed during FHM calibrations?
   1. Are they the same calibrations that are run in normal mode, but just in a batch mode per-frequency?
   2. If so, are they dependent on the other bits in the calibration bit mask?
   3. For example, if you want RX_PHASE_CORRECTION (bit 15) to happen during FHM calibration, do you need to set that bit in addition to bit 23 prior to calibrating, or is setting bit 15 unnecessary for FHM mode?
2. Is there a frequency resolution (number of calibration points) that FHM calibrations are performed at, regardless of the fhmMinHz and fhmMaxHz values from UG1295 Table 47?
   1. For example, if fast frequency hopping is needed from 1-5 GHz, if the FHM bounds were set to the full range, would the frequency resolution of the calibration be the same as if a subset of the range, such as 1-2 GHz were used?
   2. The reason I'm interested in this is I have an application that may require fast hopping over a limited bandwidth, with allowable reconfiguration gaps between bandwidth ranges, and I'm trying to figure out if there is any reason to ever set the FHM bounds smaller than the total frequency range of the RF path

FHM Cal (0x23) should be used only for FHM mode.

In FHM mode all the calibrations enabled in the Init cal mask will be run for only for the middle frequency (between Minimum and Maximum frequency specified in FHMConfig).

And few other selected calibrations are run at the middle of all LO divider transition frequencies which are part of the scanning range. User doesn't have any control on these calibrations.

All tracking calibrations are disabled during FHM mode of operation.

ahelak said:

What I am looking to understand better is:

1. What calibrations are performed during FHM calibrations?
   1. Are they the same calibrations that are run in normal mode, but just in a batch mode per-frequency?
   2. If so, are they dependent on the other bits in the calibration bit mask?
   3. For example, if you want RX_PHASE_CORRECTION (bit 15) to happen during FHM calibration, do you need to set that bit in addition to bit 23 prior to calibrating, or is setting bit 15 unnecessary for FHM mode?
2. Is there a frequency resolution (number of calibration points) that FHM calibrations are performed at, regardless of the fhmMinHz and fhmMaxHz values from UG1295 Table 47?
   1. For example, if fast frequency hopping is needed from 1-5 GHz, if the FHM bounds were set to the full range, would the frequency resolution of the calibration be the same as if a subset of the range, such as 1-2 GHz were used?
   2. The reason I'm interested in this is I have an application that may require fast hopping over a limited bandwidth, with allowable reconfiguration gaps between bandwidth ranges, and I'm trying to figure out if there is any reason to ever set the FHM bounds smaller than the total frequency range of the RF path

FHM Cal (0x23) should be used only for FHM mode.

In FHM mode all the calibrations enabled in the Init cal mask will be run for only for the middle frequency (between Minimum and Maximum frequency specified in FHMConfig).

And few other selected calibrations are run at the middle of all LO divider transition frequencies which are part of the scanning range. User doesn't have any control on these calibrations.

All tracking calibrations are disabled during FHM mode of operation.

Thanks for the information -- most appreciated.

I have a related follow up question. Some previous parts that we have worked with, for example the ADF5355, have the ability to apply a calibration, then read out the calibration and save it so that it can be applied rapidly at a later point in time.  

Is there anything specific about the ADRV9009 that would prevent this from being done here?

For example, if a user wanted to calibrate in advance at 20 frequency points instead of just the middle point, and were willing to wait the time to collect the calibration data at each point. Then once the calibrations had completed and the data was stored off, the user could load the calibration data for the next hop over SPI prior to the next frequency tune. 

I understand there's nothing in the API right now to support this, I'm just wondering if 

1. If it's possible, or if there is something with the ADRV9009 calibrations that would prevent this? 
   1. (since a wideband transceiver is much more complex than an ADF5355 synthesizer) 
2.  If this type of load and readback approach is feasible, if it would be possible to add to a roadmap, even the implementation was months from now?

ahelak said:

If it's possible, or if there is something with the ADRV9009 calibrations that would prevent this? 

1. (since a wideband transceiver is much more complex than an ADF5355 synthesizer) 

We don't have this option to store and recall calibration data by the user.

ahelak said:

 If this type of load and readback approach is feasible, if it would be possible to add to a roadmap, even the implementation was months from now?

We don't have any plans/roadmap to add this feature in the future.

We have verified even with a limited frequency  point calibration we could achieve the required init calibration performance,

Could you please let us know more about your requirements and whats is the limitation with the current method of FHM implementation?

Thanks for continuing to follow up. Some additional questions come to mind.

1. Is there a reason that the tracking calibrations need to be disabled during FHM mode? 
2. Are tracking calibrations resumed on both a quick and a full exit, or just a full exit?
   1. The language in Table 48 of UG1295 seems to indicate tracking calibrations always resume, but is a little ambiguous so would like to confirm. 

Our application tends to stay on a particular transceiver LO frequency for some time -- several times the 500 us time period for tracking calibrations to make a successful measurement as described in Table 92 of UG1295. However we do change frequency regularly, and sometimes by GHz at a time. We would like to minimize downtime during frequency changes.  

This motivated our interest in FHM mode, but we have a calibrated multi-channel RF front-end ahead of the transceivers that has a frequency and temperature dependent calibration, which made us nervous about FHM running for long periods of time without updates on a single point. 

There is also this quote from the RF PLL Frequency Change section of UG1295, stating that init cals need to be re-run when changing > 100 MHz, which seems to contradict your comment above about a single calibration frequency point being sufficient? 


-----------------

With all this said, we have more measurements to make so it might work out ok. 

Perhaps the best course of action here is to enable FHM prior to each frequency change, hop, then disable FHM to allow tracking calibrations to return. I haven't measured the time to move in and out of FHM mode, although I can do that shortly. Presumably it is shorter than the time to retune (~ 300 ms) and re-run init cal (~ 400 ms). 

From all this it is very unclear what calibrations are run at which time, and when the FHM calibration is actually done. We are sitting a a similar situation, where we want to use FHM mode to hop at a rate of ~1000hops/s.

I would very much like to see the result of the FHM mode enter/exit timing as mentioned above, as we might have to try this as well to get clean spectrum out.

When I enable FHM mode, the output samples contain weird discontinuities, which is clearly visible when inserting a signal close to the LO frequency. This goes away completely when using "normal mode". Here is a image captured on the IIO oscilloscope of what I am seeing:

As opposed to a very nice sinusoid, with FHM disabled:

This tells me it's not the digital downstream path that's causing this, but something in FHM mode is periodically messing with the signal.

RE: when the calibrations are run.
When he says all the calibrations in the init mask are run when bit 23 is set above, he means when when TALISE_runInitCals() is called, from talise_cals.h. Or equivalently when the Calibrate button is pressed in the iio-oscilloscope.  

In other words, calibrations are not run by default when entering FHM Mode, but only if the user manually runs them. And tracking calibrations are disabled (though perhaps could be enabled -- the subject of the previous question). 

PVALAVAN, please correct me if I'm off there. 

RE: the discontinuity. 
I have not seen the discontinuity you mention, but I have not attempted to hop as fast as you are in my testing so far. I will keep an eye out for it. At first glance, to me, it looks like it might be a sample buffer error where the PL DMA implementation that feeds the GUI is dropping samples in between hops (though the raw data off JESD204B might be fine)

RE: the enter/exit measurements
Will update you when I have more confidence in FHM enter/exit measurements. Initial measurements were high, but upon inspection the function adrv9009_phy_lo_write` from adrv9009.c shows that both fhm_config and fhm_mode are set in the same function. Setting fhm_config requires a radio off, but fhm_mode does not so the two are coupled right now and adding additional delay -- perhaps unnecessarily. 

I might take this up with the linux driver folks in the other forum, but for the moment want to get an answer on whether it is possible for tracking calibrations to run in FHM mode first before going further. 

RE: when the calibrations are run.

Thanks, makes some sense to me. However, what I am seeing on my side, is whenever I hit calibrate in iio-oscilloscope (with only CAL FHM enabled), the device automatically exits FHM mode. (This is not clearly visible in iio-oscilloscope, since the FHM enable checkbox is not automatically updated, but it can be seen by reading the attribute in the debug interface)

Since it exits FHM mode, is the calibration done for FHM still valid? Why does it exit FHM mode?

This might have something to do with the radio on/off state change that happens along with the calibration (as in adrv9009.c adrv9009_phy_store() for ADRV9009_INIT_CAL).

RE: the discontinuity. 

This is only visible very close to the LO frequency (within 30kHz of LO). I am currently testing with a 200MHz LO freq, but I have tested with other random LO frequencies and saw the same thing.

I don't think it's a sample buffer issue though, since it happens even when I am not changing frequency. There is thus no "in-between hops" since I am keeping the frequency static. The above images was captured with the FHM Enable checked and un-checked in iio-oscilloscope,

If you don't see this at all, then there might be something else wrong in my profile configuration.

RE: the enter/exit measurements

I have in the meantime quickly tested with entering and exiting FHM mode with each hop. I can get about 80 hops/s doing this.

I will try and test this again with some panelbeating to the Linux driver to decouple the fhm_config from the mode and get back to you.

RE: the enter/exit measurements

I did the decoupling, as well as changed the FHM exit mode to quick exit, and I can now do well in excess of 1000 hops/s (currently capping out at 1850 hops/s).

This also "fixes" the discontinuity issue. I would be very much interested to know why keeping the device in FHM mode causes the discontinuities.

In case of quick exit the RF PLL loop bandwidth will be left unchanged, only AUX PLL will be calibrated and then tracking calibrations resumed. In case of full exit the RF PLL loop bandwidth will be restored to the bandwidth prior to FHM, RF and AUX PLLs recalibrated and tracking calibrations resumed. The MCS phase synchronization mode will be restored as well. The quick exit can be used if the host needs to get in and out of frequency hopping quickly. 

Vinod thanks for adding detail -- I realize this is a long thread.  

One last question -- can you comment on the MCS phase synchronization mode that is used during FHM mode, and the performance relative to that used in normal mode after a full exit?

For example, in Figure 70 of UG1295 there is a photo showing a relative channel to channel phase distribution of ~ 1-2 degrees (estimated off the chart). Realizing this may be frequency dependent and the chart is just one measurement -- I assume this is near the best possible performance using something like TAL_RFPLLMCS_INIT_AND_CONTTRACK. 

In FHM mode, is something like TAL_RFPLLMCS_INIT_AND_SYNC used to lock quickly with no further adjustments, so performance may approach Figure 70 initially but no guarantees are made about performance over time? 

That is the heart of the question I am trying to answer, as I have requirements in degrees of channel to channel phase variance for my application that I need to ensure I can meet, and it sounds like they may require a full exit. 

ahelak said:

In FHM mode, is something like TAL_RFPLLMCS_INIT_AND_SYNC used to lock quickly with no further adjustments, so performance may approach Figure 70 initially but no guarantees are made about performance over time? 

Yes. FHM mode is meant for frequency hopping applications (where dwell time is less). If you are concerned about performance over time please normal mode of operation.

ahelak said:

That is the heart of the question I am trying to answer, as I have requirements in degrees of channel to channel phase variance for my application that I need to ensure I can meet, and it sounds like they may require a full exit. 

Please use the full exit mode to return back the normal mode operation.