Tune UHD - as fast as possible

GNU Radio
#1

Hi!

I have put a Flow-Graph together, which is quite simple:
Sine Signal -> USRP2 UHD

Now I want to change the center-frequency as fast as possible.

My initial idea was a while True loop and to issue the
self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) command from Python.
This does not work. It remains at the initial frequency.

Do you use the Function Probe block in GRC? Or is there any other way to
make it tune without ending the Flow-Graph?

Best,
Marius

#2

self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) will take forever,
the
whole front end has to re-settle. How far are you moving the center
frequency? If it’s less than 50MHz you could change the sin signal
frequency. You could even hook up a Frequency modulator and change the
frequency continually and with absolutely no delay.

#3

Hi Andrew,

thanks for the reply. I need the RF Frontend to change. I’m doing
measurements in order to find out how fast the RF Frontend can tune over
more than 25 MHz (on a USRP2). I need some exact data here, e.g. plots.
So in fact I want it to tune with no workarounds. And I want to see it
tune :wink:

I pinpoint the Transceiver of the XCVR
(http://datasheets.maxim-ic.com/en/ds/MAX2828-MAX2829.pdf) in order to
get a down-scaled frequency. I want to set a new frequency. An then I
want to plot how long it takes the device to issue the change. That’s
UHD Device driver command + Ethernet latency + FPGA reaction.

My problem is, that I know of no way to tune it. Automatically changing
the center-frequency from GRC seems to be impossible to me.

http://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html

  • I found that. But
    uhd.tune_request(target_freq, dsp_freq=0,
    dsp_freq_policy=uhd.tune_request.POLICY_MANUAL) tells me, that it cannot
    be evaluated in GRC. Variables set of course. I guess the constructor
    changed, but there’s no docu here.

  • I can use a WX GUI slider, but I need an automated change. Actually a
    switch between 50 and 75 MHz (so that my Oscilloscope copes with that).
    Here I use the WBX. My overall goal is to understand more about the
    hardware.

So if someone knows how I can implement a callback or a polling function
to make the device tune for real, but as fast as possible, that’d be
very helpful.

Best,
Marius

#4

http://gnuradio.org/doc/doxygen/classuhd__usrp__sink.html#a279a28c250e2ae657aa9c43b5742c2fa

Is the current API, i’m not sure how it gets to python world, but it
looks
like you can still call it with just the frequency.

Also it there any reason your doing this with GRC and not python?

#5

Ive used XMLRPC for the same thing and you don’t have to worry about
unpacking integers into floating point etc

–
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org

#6

On 2/10/12 4:14 AM, Marius Ciepluch wrote:

So if someone knows how I can implement a callback or a polling function
to make the device tune for real, but as fast as possible, that’d be
very helpful.

In the past, I’ve done external tuning via GRC with the following:

Create a variable block (ie - “frequency”), and put the name in
the frequency parameter of the UHD-sink block.

Create a subgraph consisting of a UDP source block and a variable
sink block, aimed at the “frequency” variable.

Use an external program to send a UDP packet to the port number
of the UDP source block. The packet should contain a single
integer representing the frequency. Pay attention to byte-order.

I’ve used this setup to apply doppler correction from an external
program when receiving telemetry from a spacecraft. We were only
sending packets about once per second, so I don’t know how fast
this setup will go, but it’s worth pursuing.

@(^.^)@ Ed

#7

On 11/02/12 05:50 AM, Marius wrote:

Well, yes, it will add latency. Not a lot, but some. The hardware
generally takes about 1ms
to tune and lock.

If you want absolute minimum latency without doing an FPGA-based
implementation, then stick
entirely with the C++ API. GRC produces Python, and while the blocks
themselves are mostly
written in C++, things like parameter changes to blocks (including
source/sinks) have to
“percolate” through Python first, and it’s an interpreted language.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

#8

Hi!

On 10 February 2012 18:12, Marcus D. Leech [email protected] wrote:

Ive used XMLRPC for the same thing and you don’t have to worry about unpacking
integers into floating point etc

Ah, the XMLRPC block automatically adds callback functions for the
variables. That’s a great startpoint. Thanks a lot. Now I finally know
why someone would need an XMLRPC in DSP :wink:

@(^.^)@ Ed

I hope it doesn’t add any latency to the equation like: RPC command +
UHD command + FPGA reaction + RF frontend. I’m not even sure if using
the C++ API would be any different. So my Monday morning experiment
now is set :wink:

Best,
Marius