Hello Richard, The Python "API" is a minimal wrapper of the C++ API. You can call nearly every function of the multi_usrp class on a USRP sink or source object in Python. The function names are altered slightly because it makes no sense to call, for instance, set_rx_freq, on a USRP sink.
Here is the declaration of the set_center_freq function for the USRP source block. https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_source_impl.h#L90 ::uhd::tune_result_t set_center_freq(const ::uhd::tune_request_t tune_request, size_t chan); This is converted to a call to set_rx_freq in the gr-uhd implementation. https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_source_impl.cc#L142 Your program, and most others, are calling the function set_center_freq function with a frequency (number of herz) and no channel number. The frequency is automatically converted to a tune_request using the constructor which takes just a double. The default channel is 0 if one is not given. http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a9b61448f392466e20572fdcb042e8ec6 virtual tune_result_t uhd::usrp::multi_usrp::set_rx_freq(const tune_request_t & tune_request, size_t chan = 0) To use your tune request with use it instead of a frequency in a call to set_center_freq self.usrp = uhd.usrp_sink(device_addr=options.args, stream_args=uhd.stream_args('fc32')) self.usrp.set_center_freq(900e6) uhd.usrp_sink.get_center_freq() tr = uhd.tune_request(901e6, 1e3) self.usrp.set_center_freq(tr) uhd.usrp_sink.get_center_freq() Regards, Derek On Tue, Jun 14, 2016 at 12:13 PM, Richard Bell <richard.be...@gmail.com> 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 > > 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
