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
ahelak said:If it's possible, or if there is something with the ADRV9009 calibrations that would prevent this?
(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.
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 measurementsWill 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.