Re: [Discuss-gnuradio] Tunning USRP From Seperate C++ Block?

[Josh Blum]

On 06/06/2012 08:54 AM, labarowski wrote:
> 
> 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++ (http://www.ruby-forum.com/topic/174437). 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.

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):
https://github.com/guruofquality/grextras/wiki
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.

2) 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