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