[USRP-users] uhd.tune_request on the fly?
Marcus D. Leech
mleech at ripnet.com
Fri Apr 17 16:22:55 EDT 2015
On 04/17/2015 03:45 PM, Murphy, John via USRP-users wrote:
> I am trying to change center frequencies in response to GUI text entry.
> Other blocks in the flowgraph accept and propogate the change in the
> GUI text thru a variable in GRC.
> But the UHD does not appear to change frequencies "on the fly" like
> this. It will only change when I stop the flowgraph, execute the
> change, and re-start.
> Is this the expected behavior when you pass a uhd.tune_request() to
> the center frequency parameter of a UHD Source block in GRC? Or maybe
> something with the version I am using anyhow? Or just something I am
> doing incorrectly?
> GR 22.214.171.124
> UHD 3.8.1
> UHD Source Block Ch0 Center Freq
> B200 (one of the old white boards)
> GPSDO on board if it by some chance matters
> center_freq and samp_rate are GRC flowgraph variables from QT GUI
> Entries with those names
> exact param is uhd.tune_request(center_freq, samp_rate / 2.0)
> similarly changing samp_rate (say, between 2M and 4M) *works on the
> fly* (for the samp_rate, it does not seem to change the tune request
> changing center_freq from 600M-ish to 1600M-ish for instance does not
> actually tune the receiver.
> even though I see the rest of the flowgraph update because axis labels
> on the GUI etc change
> (plus I have debug printfs that pop out when I change frequencies in a
> custom block)
> John Murphy
> jmurphy at comsonics.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
Please include your .grc file, and perhaps use the discuss-gnuradio
UHD absolutely tunes on-the-fly, and if it's handed a tune_request_t
on-the-fly will indeed honor it. The question is whether GRC is
actually, because of
the way you have your variables structured, handing the UHD block a
fresh tune_request_t dynamically or not.
More information about the USRP-users