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

On Mon, Jun 13, 2016 at 4:47 PM, Richard Bell <richard.be...@gmail.com>
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 <martin.br...@ettus.com>
> 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 <derek.ko...@ettus.com
>> > <mailto:derek.ko...@ettus.com>> 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
>> >     <richard.be...@gmail.com <mailto:richard.be...@gmail.com>> 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
>> >         Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> >         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to