Tunning USRP From Seperate C++ Block?

Hello,
I would like to make a signal processing block which would generate a
certain number of samples (corresponding to a specific time window),
pass
them to a USRP sink, then tune the USRP to a new frequency and repeat
the
process. The issue that I’m running into is that I’m not sure that there
is
a way for me to tune the USRP sink from a separate C++ block within a
python
flowgraph. There is a method under gr_uhd_usrp_sink.h in the GNURadio
3.6
API which looks like it would do the job, but I’m not sure that it is
accessible if I don’t have direct access to the UHD sink at the C++
level,
which in this case I wouldn’t as it is in another signal processing
block. I
have also been reading about gr.feval, which should allow me to call the
python tune method from C++ (Some usrp_spectrum_sense.py code Explanation - GNU Radio - Ruby-Forum).
I’m
having trouble seeing how feval works in gr_bin_statistics_f.cc and the
GNURadio 3.6 API though. Is there any other documentation or examples of
feval?

From what I know so far, my options are to:
1.) Make a separate block which uses the feval function to change the
frequency in Python.
2.) Do all of the frequency changing in python. This is not desirable as
my
understanding is that the python flowgraph will not share a timebase
with
the samples passed between blocks. This might be acceptable though. The
RPC
server with a separate python script acting as a client has worked thus
far
but we have had to add extra delay time just in case and I would be a
bit
worried about the possibility of the two time bases drifting with long
term
use.
3.) Construct a wrapper block for the UHD sink. The wrapper will be used
in
the flowgraph and will itself call the actual UHD sink and (should) have
access to its tune method
4.) Just make the whole flowgraph in C++

What are your thoughts on this? Is there some other option that I’m
unaware
of which will make this easier? I’m somewhat inclined to make everything
in
C++ at this point. This would keep all variables/methods accessible and
may
make it easier to keep a common timebase, although I think each
individual
block will still be running in a separate thread (please correct me on
this
if I am wrong). I look forward to hearing the opinions of those more
experienced than me. I have found this mailing-list very useful in the
past.

View this message in context:
http://old.nabble.com/Tunning-USRP-From-Seperate-C%2B%2B-Block--tp33970855p33970855.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On 06/06/2012 08:54 AM, labarowski wrote:

which in this case I wouldn’t as it is in another signal processing block. I
understanding is that the python flowgraph will not share a timebase with
What are your thoughts on this? Is there some other option that I’m unaware
of which will make this easier? I’m somewhat inclined to make everything in
C++ at this point. This would keep all variables/methods accessible and may
make it easier to keep a common timebase, although I think each individual
block will still be running in a separate thread (please correct me on this
if I am wrong). I look forward to hearing the opinions of those more
experienced than me. I have found this mailing-list very useful in the past.

So, no matter how you solve this, there different timebase thing is an
issue. On the N210/N200, there is a set_command_time. You will want to
use this to coordinate when tunes occur in relation to the samples.
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5

  1. Now, something that I would like to do is create a message sink block
    that turns an arbitrary PMT message into a function name + args and
    calls this function in python on a block’s methods; obviously this is
    all from the context of a python flow graph. On your end, in c++ you
    would add a message port to your block that posts these control message
    to its message source output.

So thats possible given the project here (see message section):

You should be able to implement something on the c++ and python end with
the messages. But, I hope to make something like this more
strait-forward with the arbitration block described above.

  1. If thats not feasible, there are these gr_msg_queue objects
    (unrelated to the link above) that let you pass binary blobs around. You
    can push into the queue in c++, and pop the message in a python thread,
    call the setting…

I’d say either option is easier than implementing a wrapper of some sort
or using feval. Bringing it into c++ may not be too bad though…

-josh

Sorry for the time between replies. I’ve been taking exams and packing
up. Timing the frequency changes is not terribly critical, as long as
they stay in rough order with the incoming samples. Our current way
involves a separate script which generates RPC packets for the XML-RPC
server to change a variable for the frequency. This has actually worked
ok in testing but I’m concerned that the timing between GNURadio and the
separate python script could drift during extended tests, causing the
incoming samples to be correlated with the wrong frequencies. Doing
everything in C++ would still not give a true time base, but at least if
I called the frequency changes from the work function it would correlate
directly to the samples. Will take note of the set_command_time function
as it could definitely prove useful for this project.

Great job on the Gr-extras Josh! The PMT passing definitely seems much
more straightforward than feval. Even still, I’m leaning a bit towards
C++ for this project. That should allow me to simply pass a pointer of
the UHD Sink block to the block which is going to change it’s frequency.
This same method would probably prove useful for other aspects of this
project as well. It would make it really easy to pass data between
blocks. I also have a lot more experience with C++ than I do with
Python. Problem is, I can’t seem to find any documentation or examples
on constructing a flowgraph in C++. I’m not even sure which libraries
would need to be included. Is there somewhere that I can look for C++
examples/tutorials?

Thanks!

On 06/09/2012 04:58 PM, Daniel Labarowski wrote:

directly to the samples. Will take note of the set_command_time function
as it could definitely prove useful for this project.

Well, whatever works is the right answer. :slight_smile:

Even calling tune from the work function of your block is still going to
have time ambiguity with the samples. You never know how much is
buffered in the kernel or in a gr stream.

I suppose an indirection of RPC would add some latency and possibly
exacerbate the problem. I can’t say by how much.

Timed commands aside, the next safest thing you can do is shut off the
streaming (start/stop methods of the source block) if you dont want any
ambiguously tuned samples.

Great job on the Gr-extras Josh! The PMT passing definitely seems much
more straightforward than feval. Even still, I’m leaning a bit towards
C++ for this project. That should allow me to simply pass a pointer of
the UHD Sink block to the block which is going to change it’s frequency.
This same method would probably prove useful for other aspects of this
project as well. It would make it really easy to pass data between
blocks. I also have a lot more experience with C++ than I do with

BTW, I just produced a PMT RPC block, code here:

You can stick this block in a python flow graph and it will parse its
incoming messages and make calls on the flow graph. You can produce the
messages for the RPC block in python or C++ work() function.

I’m not pressuring you to use it or anything, but your inquiry did spark
a neat idea :slight_smile:

Python. Problem is, I can’t seem to find any documentation or examples
on constructing a flowgraph in C++. I’m not even sure which libraries
would need to be included. Is there somewhere that I can look for C++
examples/tutorials?

Here is a blocks coding guide I wrote for GNU Radio:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide

And here is the equivalent document for GrExtras:

Looks like I left the top_block part of the guide as TODO, but here is a
good example for that:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-audio/examples/c++/dial_tone.cc

-josh

Josh,
The RPC-PMT block is definitely a great idea. Whether I go the python
route or not, I will keep that tool in my back pocket. IMO, this solves
the problem in a much more accessible manner than feval. Still, C++ may
be better suited for this project. I’m going to be out of town so I’ll
have some time to read over the resources that you’ve sent me and decide
which is the best. You guys will probably here from me again when I pick
this project back up in a couple weeks. Thanks again for all of the
support that you provide for Gnuradio Josh, both in the form of code as
well as answering questions on this mailing list.

-Dan