|
From: | Marcus D. Leech |
Subject: | Re: Spurs in UBX-160 Daughterboard with USRP X310 |
Date: | Thu, 2 Mar 2023 14:55:23 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
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 byHey,
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
בתאריך יום ד׳, 1 במרץ 2023 ב-21:10 מאת Marcus D. Leech <patchvonbraun@gmail.com>:
On 01/03/2023 13:14, Dor Ratz wrote:
Note that only works if the underlying RF PLL has enough "resolution" to make that work--particularly in integer-N mode.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 theDevice 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
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.
בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת Dor Ratz <dorratz12@gmail.com>:
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.
ThanksDor
בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת Marcus Müller <marcus.mueller@ettus.com>:
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
[Prev in Thread] | Current Thread | [Next in Thread] |