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‬‏
 <‪patchvonbraun@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‬‏
     <‪patchvonbraun@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‬‏
         <‪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.

             Thanks
             Dor

             ‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת ‪Marcus
             Müller‬‏ <‪marcus.mueller@ettus.com‬‏>:‬

                 Hi Dor,

                 Should I just type "mode_n=integer" in the

                 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]

                 mode(integer of fractional) of the NCO is? Can
                 I print

                 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

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‬‏ > <‪patchvonbraun@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‬‏ >> <‪patchvonbraun@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‬‏ >>> <‪patchvonbraun@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‬‏ >>>> <‪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. >>>> >>>> Thanks >>>> Dor >>>> >>>> ‫בתאריך יום ב׳, 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 >>>> >>> >> >

 Device Address parameter of the UHD: USRP Sink block in the grc?

 its status/get it somehow?

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 <patchvonbraun@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‬‏ <‪ > patchvonbraun@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‬‏ <‪ >> patchvonbraun@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‬‏ <‪ >>> patchvonbraun@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‬‏ <‪ >>>> 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. >>>>> >>>>> Thanks >>>>> Dor >>>>> >>>>> ‫בתאריך יום ב׳, 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 >>>>>> >>>>> >>>> >>> >> >