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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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
> [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected] <mailto:[email protected]>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
