On 02/03/2023 13:09, Dor Ratz wrote:
Hey,
Do you know how to assess the RF PLL resolution
in integer-N mode?
I've looked in ANALOG max2871 PLL datasheet - not
sure I found the answer there.
The Ettus team is CC here too - it will be
helpful to know what you suggest.
Thanks,
Dor
It will depend on the REFCLK that is being used by that board (I do
not happen to know off the top of my head), and by
whatever flexibility in reference divider the PLL has.
In an Integer-N PLL (and you can spend quite a bit of time learning
how PLL synthesizers work online), the "step size" is
dependent on the REFCLK, which itself may have a divider on it.
So, let's say your REFCLK is 10MHz and there's a divider
that can divide the reference clock by up to 10000, then your
minimum step size is 1kHz. This is in tension with the
fact that having a high ratio between the desired frequency and
the reference frequency tends to create signal-quality issues,
like, as I recall, phase noise. But I'd research the datasheet
and the overall concept of PLL synthesis.
My recollection on the X310 is that the reference-clock frequency is
100MHz, but that's just a hazy memory.
On 01/03/2023 13:14, Dor Ratz wrote:
Hey Marcus, How are you?
Not sure if you got my email.
Do you know anyway I can change
transmitted frequency using PMT message when doing
your solution?
In addition, something that seemed to
help me:
I used this:
In the USRP Sinc block, in center
frequency parameter, I've put this:
uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
With this, the transmitted 1003MHz
signal is cleaner and the spur is now further away
at 16KHz offset with amplitude of 60dBc below the
signal.
This alone cleans the spectrum!
In addition, I type "mode_n=integer" in
the
Device Address parameter of the UHD:
USRP Sink block, but it doesn't seem to affect. The
tuning without DSP correction in the FPGA seems to
just be sufficient to clean the spectrum.
Why is that? Do you recommend using
something else?
Thanks
Dor
Note that only works if the underlying RF PLL has enough
"resolution" to make that work--particularly in integer-N
mode.
I'm surprised that the DDC/DUC have such significant "close
in" spurs. I don't know if there's anyone from the
R&D team
on here who can authoritatively comment, but this is a bit
of a surprise.
Hi Marcus,
Can I pass the desired center
frequency with a PMT message?
I want to dynamically change the
transmitted center frequency of UHD: USRP Sink
block.
So static frequency in the block is
not sufficient.
Thanks
Dor
Hi Dor,
> 1. How to change the to integer_n
tuning? Should I just type "mode_n=integer" in
the
> Device Address parameter of the UHD:
USRP Sink block in the grc?
yes. Or, better, instead of just tuning to the
target frequency, you can pass a
uhd.tune_request_t to
uhd_usrp_{sink,source}.set_center_frequency,
like this:
my_uhd_block.set_center_frequency(uhd.tune_request_t(
target_freq = 2.4e9,
args="mode_n=integer"))
(you can also use a uhd.tune_request_t in the
RF frequency fields of the GRC block)
Note that you're probably best off using
tune_request_t anyway, as it allows you to
tune
your LO far away from your band of interest,
given the analog bandwidth allows for that,
using `target_freq=` and `rf_freq` or
`dsp_freq`.
For more information on tuning, see the UHD
manual [1]
> 2. How to know for sure what the
mode(integer of fractional) of the NCO is? Can
I print
> its status/get it somehow?
looking at the UHD source code: the routines
responsible for tuning just themselves check
for "mode_n" being set to "integer" in the
device or tune request arguments.
Best regards,
Marcus
[1] https://files.ettus.com/manual/page_general.html#general_tuning