Hi, Would it be possible to elaborate on what setting bit 23 of the table in UG1295 does in the ARM firmware? Although it does not appear to be documented in the user guide, from reading on the forums and the wiki I understand that it initiates FHM calibrations.What I am looking to understand better is:
ahelak said:What I am looking to understand better is:
What calibrations are performed during FHM calibrations?
Are they the same calibrations that are run in normal mode, but just in a batch mode per-frequency?
If so, are they dependent on the other bits in the calibration bit mask?
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?
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?
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?
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
What I am looking to understand better is:
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
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.
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.