Re: [Discuss-gnuradio] Retune Request Time

[Martin Braun]

Or try this:

tr = uhd.tune_request(900e6, 0)
tb.usrp.set_center_freq(tr)
tr = uhd.tune_request(901e6, -1e6)
tb.usrp.set_center_freq(tr)

M


On 06/14/2016 07:47 PM, Marcus D. Leech wrote:
> On 06/14/2016 09:39 PM, Richard Bell wrote:
>> I think I have a misunderstanding about the DSP tune, because it's not
>> behaving the way I expect it to. Let me describe my experiment.
>> Suppose I want to hop between two frequencies, 900e6 and 901e6, using
>> a sample rate of 500e3 and a usrp as a sink (transmitter).
>>
>> 1) If I use set_center_freq(900e6) and set_center_freq(901e6) in a
>> loop to hop between the two frequencies, it works just as you would
>> expect. I verified this by using a second USRP as a spectrum analyzer.
>>
>> 2) Now, If I use the following to make the same hop, I see a strong
>> static tone coming out at 900e6, and a small baby tone popping up and
>> down at 901e6. The baby tones are about 40 dB down from the static
>> tone. There are also even smaller image tones popping up and down at
>> the hop rate around 901e6.
>>
>> tr = uhd.tune_request(900e6, 1e6)
>> successful_hop = tb.usrp.set_center_freq(tr)
>>
>> and then on the next iteration
>>
>> tr = uhd.tune_request(900e6, 0)
>> successful_hop = tb.usrp.set_center_freq(tr)
>>
>> I'm expecting to see the exact same behavior as I did when using
>> set_center_freq in the first approach above, but I'm not. Am I
>> understanding the dsp_tune incorrectly?
>>
>> Rich
>>
> You should spend some time looking through this:
>
> http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>
> In the example, you gave the Fc is still 900Mhz, but with the FPGA
> providing an offset tuning.  That's not what you want.
>
> What you want is to set the target frequency to 901MHz, use POLICY_NONE
> on the RF side, and provide a 1e6 DSP_FREQ, with POLICY_MANUAL.
>
> POLICY_NONE means that it won't touch the already-tuned analog RF
frequency.
>
>
>>
>> On Tue, Jun 14, 2016 at 1:20 PM, Marcus D. Leech <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>     On 06/14/2016 03:13 PM, Richard Bell wrote:
>>>     Martin,
>>>
>>>     If I create a USRP object
>>>
>>>     self.usrp = uhd.usrp_sink(device_addr=options.args,
>>>     stream_args=uhd.stream_args('fc32'))
>>>
>>>     and initialize the USRP center frequency to 900e6
>>>
>>>     self.usrp.set_center_freq(900e6)
>>>
>>>     and then do
>>>
>>>     tr = uhd.tune_request(901e6, 1e3)
>>>
>>>     followed by
>>>
>>>     uhd.usrp_sink.get_center_freq()
>>>
>>>     it returns the original center freq of 900e6. My question is what
>>>     is the tune_request doing?
>>>
>>>     Rich
>>     uhd.tune_request() is just a constructor for a tune_request_t
>>     object, it doesn't actually touch the hardware at all.  So, you
>>     take that tr, and
>>       hand it to a uhd.usrp_sink.set_center_freq(tr).
>>
>>
>>
>>>
>>>     On Mon, Jun 13, 2016 at 4:47 PM, Richard Bell
>>>     <address@hidden <mailto:address@hidden>> wrote:
>>>
>>>         I can call the C++ functions from Python? Why is there a
>>>         separate python API, I'm confused.
>>>
>>>         Lets say I set an initial center frequency of 900 MHz to
>>>         start the script off. You're saying that if the next
>>>         frequency I want to hop to is within the ADC sampling rate,
>>>         which in my case for the N210 is 100 MHz, I should manually
>>>         tell the USRP to set the DSP_FREQ and leave the RF_FREQ alone
>>>         for the fastest hop, and that the USRP automatic settings are
>>>         not smart enough to figure this out?
>>>
>>>         If the above is true, it seems I should do something like this:
>>>         1) Ask the USRP what the current RF_FREQ is
>>>         2) Find the difference between RF_FREQ and the new center freq
>>>         3) If the difference is greater then 100 MHz, change the RF
>>>         Freq, otherwise change the DSP freq
>>>
>>>         Is this correct?
>>>
>>>         On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun
>>>         <address@hidden <mailto:address@hidden>> wrote:
>>>
>>>             Richard,
>>>
>>>             "use DSP tuning when possible" is not a valid policy.
>>>
>>>             In Python:
>>>
>>>             from gnuradio import uhd
>>>
>>>             rf_freq = 900e6
>>>             dsp_freq = 1e3
>>>             TR = uhd.tune_request(rf_freq, dsp_freq)
>>>             # Oh look it worked:
>>>             print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
>>>
>>>
>>>             So, in a nutshell, rf_freq and dsp_freq are used
>>>             depending on the
>>>             respective policies, but there's no 'figure out smart
>>>             tunes based on
>>>             state' policy.
>>>
>>>             -- M
>>>
>>>
>>>             On 06/13/2016 03:49 PM, Richard Bell wrote:
>>>             > Derek,
>>>             >
>>>             > that manual is the C++ API. How would I format the tune
>>>             policy
>>>             > information in python? It's not clear to me looking at
>>>             the C++ API and
>>>             > the Python API for the set_center_freq python function.
>>>             Could you give
>>>             > an example of how you would call
>>>             >
>>>             > C++:
>>>
http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>>>             > Python:
>>>             >
>>>
http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink
>>>             >
>>>             > set_center_freq(center_freq,
>>>             <USE_DSP_TUNING_WHEN_POSSIBLE>)
>>>             >
>>>             > What goes in place of the careted argument?
>>>             >
>>>             > Rich
>>>             >
>>>             > On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel
>>>             <address@hidden <mailto:address@hidden>
>>>             > <mailto:address@hidden
<mailto:address@hidden>>> wrote:
>>>             >
>>>             >     Hi Rich,
>>>             >
>>>             >     You can create and pass a tune_request_t into the
>>>             set frequency call
>>>             >     of a USRP object. This gives you control of how it
>>>             tunes. By default
>>>             >     it does not optimize for speed to my knowledge.
>>>             >
>>>
http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>>>             >
>>>             >     Depending on what USRP you are using there are self
>>>             calibration
>>>             >     thresholds which will cause a retune to incur a
>>>             delay when tuning
>>>             >     outside of a certain range. On the B200 for
>>>             instance this range is
>>>             >     100MHz.
>>>             >
>>>             >     Regards,
>>>             >     Derek
>>>             >
>>>             >     On Mon, Jun 13, 2016 at 3:05 PM, Richard Bell
>>>             >     <address@hidden
<mailto:address@hidden>
>>>             <mailto:address@hidden
>>>             <mailto:address@hidden>>> wrote:
>>>             >
>>>             >         I am using set_center_freq(center_freq) in my
>>>             python script to
>>>             >         retune my USRP to various center frequencies.
>>>             Does this command
>>>             >         use the smartest retune technique to get to the
>>>             new frequency?
>>>             >
>>>             >         For example, if I want to retune from 900.000
>>>             MHz to 900.001 MHz
>>>             >         ( a 1 kHz change), will it use DSP tuning
>>>             instead of RF tuning
>>>             >         for speed? Is there a way to control this
>>>             through python?
>>>             >
>>>             >         In my testing, it seems the retune time is
>>>             constant whether I
>>>             >         make a 1 GHz hop, a 3 MHz hop or a 1 kHz hop,
>>>             which makes me
>>>             >         think I'm overlooking something.
>>>             >
>>>             >         Thanks,
>>>             >         Rich
>>>             >
>>>             >         _______________________________________________
>>>             >         Discuss-gnuradio mailing list
>>>             >         address@hidden
>>>             <mailto:address@hidden>
>>>             <mailto:address@hidden
>>>             <mailto:address@hidden>>
>>>             >
>>>              https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>             >
>>>             >
>>>             >
>>>             >
>>>             >
>>>             > _______________________________________________
>>>             > Discuss-gnuradio mailing list
>>>             > address@hidden <mailto:address@hidden>
>>>             > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>             >
>>>
>>>
>>>             _______________________________________________
>>>             Discuss-gnuradio mailing list
>>>             address@hidden <mailto:address@hidden>
>>>             https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Discuss-gnuradio mailing list
>>>     address@hidden <mailto:address@hidden>
>>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>     _______________________________________________
>>     Discuss-gnuradio mailing list
>>     address@hidden <mailto:address@hidden>
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>