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 <richard.be...@gmail.com
<mailto: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 <mailto: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>
> <mailto: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>
<mailto: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>
<mailto: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 <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
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
