Hi Dor, There are 2 arguments that can control the integer-N step size: the int_n_step tune arg and the dboard_clock_rate device arg. The int_n_step tune arg will explicitly change the step size by changing the R divider value, which will break phase coherency between channels. The 'dboard_clock_rate' value in the device args controls the reference clock rate, which will keep the R divider set to 1 and support phase coherency between channels. Both will change the PFD frequency for the PLL. The UBX was designed for a PFD frequency of 50 MHz, which is why 50 MHz is the default reference clock rate and the default R value is 1. Reducing the PFD frequency will result in more phase noise. My recommendation is to set the 'mode_n=integer' in the tune args, let the DSP tuning take care of the offset by leaving the DSP tuning policy to the default (POLICY_AUTO), and use the highest dboard_clock_rate possible (up to 50 MHz). The highest 'dboard_clock_rate' can be achieved based on the required bandwidth of the application by using the formula:
dbaord_clock_rate = (160 MHz - bandwidth) / 2 I hope this helps. Best regards, Michael E. West On Mon, Mar 6, 2023 at 3:07 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 06/03/2023 17:13, Dor Ratz wrote: > > Hey, > > Thanks a lot. > > *Several questions after thinking about it:* > > > 1. Do you mean R&D of Ettus or GNURadio? Can you address me to the > relevant email address? > > This thread really belongs on the usrp-users mailing list now, rather than > discuss-gnuradio, i have copied usrp-users, and > removed discuss-gnuradio. > > > > > > 2. Let me see if I get it right for USRP X310 with UBX-160: > > > - Motherboard clock = MCR =master_clock_rate = main clock rate = > default value is 200MHz. The 10MHz REFCLK is used to set it. > - Daughterboard Clock Rate in Hz = dboard_clock_rate = default value > is 50MHz, need to change it to 20MHz for center frequencies under 1GHz do > decrease spurs. > This is actually the clock that the motherboard injects into the > daughterboard , i.e it is the reference clock of the MAX2871 PLL which is > on the daughterboard. > - According to this link > <http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html>, > if I set "mode_n=integer","int_n_step=100e3", in Device Address parameter > in USRP Sink block, then the frequency resolution on the PLL is: > frequency resolution [Hz] = int_n_step [Hz] = dboard_clock_rate [Hz] / > (R divider [-]) > > For example: > 100e3 [Hz] = 50e6 [Hz] / 500 > > So ->* the frequency resolution of the PLL is set by the "int_n_step" > parameter* -> it calculates the R divider [-] in the PLL relating to > dboard_clock_rate and desired int_n__step. > I guess that the result must be in the range of allowed PLL's R > divider values from 1 to 1023. > > 3. Do I must set the "int_n_step" parameter as follows? > > 4. Does the frequency resolution range from 50MHz when R divider= 1[-] up > to 0.05[MHz] when R divider = 1000[-] ? > > Referring to this sentence in max2871 PLL datasheet > <https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf> > : > ""The minimum R counter divide ratio is 1, and the maximum divide ratio is > 1023" > > > 5. Where can I find the relevant source code? I've looked here > <https://github.com/EttusResearch/uhd> but I'm not sure where the > daughterboard code/relevant code is. > > Thanks > Dor > > > בתאריך יום ב׳, 6 במרץ 2023 ב-19:10 מאת Marcus D. Leech < > patchvonbr...@gmail.com>: > >> On 06/03/2023 08:54, Dor Ratz wrote: >> >> Hey Marcus, >> >> Thanks a lot. >> >> I'm using external 10 MHz reference clock (REFCLK) with 1e-12[Hz] >> frequency resolution -> it feeds my PLL in the UBX-160 daughterboard in the >> X310 USRP. >> >> The REFCLCK input to the X310 is used to control the master-clock(s) on >> the motherboard, which, in turn produce clocks for >> the daughtercards--but the daughtercards never see your external clock >> directly. >> >> >> So, *when defining "mode_n=integer"* in the Device Address parameter of >> the UHD: USRP Sink block in GNURadio to set PLL in integer-N mode, *what >> is exactly R-DIVIDER= reference divider of the PLL*? >> >> I've looked in the PLL (max2871) datasheet: >> >> https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf >> >> According to it: >> "The minimum R counter divide ratio is 1, and the maximum divide ratio is >> 1023" >> >> I understand that if for example, the R counter=(R-DIVIDER)=1000 -> the >> frequency resolution is 10MHz/1000 = 0.01MHz= 10KHz, correct? >> >> But I don't know what is the R-DIVIDER chosen in the PLL with the >> settings in gnuradio. >> >> Thanks, >> >> Dor >> >> You'd have to go looking through the source code. Unless someone from >> R&D happens to know off the top of their heads. >> 10 years ago, I kept all of this in my head--when there were FAR fewer >> products to keep track of and the codebase was >> more modest. >> >> >> >> >> >> >> >> >> בתאריך יום ה׳, 2 במרץ 2023 ב-21:55 מאת Marcus D. Leech < >> patchvonbr...@gmail.com>: >> >>> 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. >>> >>> https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf >>> >>> 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. >>> >>> >>> >>> >>> >>> בתאריך יום ד׳, 1 במרץ 2023 ב-21:10 מאת Marcus D. Leech < >>> patchvonbr...@gmail.com>: >>> >>>> 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: >>>> >>>> >>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת Dor Ratz < >>>> dorrat...@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. >>>>> >>>>> Thanks >>>>> Dor >>>>> >>>>> בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת Marcus Müller < >>>>> marcus.muel...@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 >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
