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 <mle...@ripnet.com >> <mailto:mle...@ripnet.com>> 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 >>> <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 <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
