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

[labarowski]

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.
-- 
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.