[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Retune Request Time
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] Retune Request Time |
Date: |
Wed, 15 Jun 2016 09:42:05 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
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
>
- [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/13
- Re: [Discuss-gnuradio] Retune Request Time, Derek Kozel, 2016/06/13
- Re: [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/13
- Re: [Discuss-gnuradio] Retune Request Time, Martin Braun, 2016/06/13
- Re: [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/13
- Re: [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Martin Braun, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Marcus D. Leech, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Marcus D. Leech, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time,
Martin Braun <=
- Re: [Discuss-gnuradio] Retune Request Time, Derek Kozel, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Martin Braun, 2016/06/14
- Re: [Discuss-gnuradio] Retune Request Time, Richard Bell, 2016/06/14