I'm trying to implement a collection of networked USRPs for an
application I’m working on. I need to create blocks that retrieve data
from various remote sources, and the library I’ve been using this far
has been pyro (pyro.sourceforge.net), which is extremely simple and
straightforward for the kinds of networked tests I need to run.
Unfortunately, I can’t send the USRP back as it is through pyro, because
it is a SWIG object using local file descriptors, which pyro is unable
to serialize. I’d like to implement my own blocks in python to sit
between the remote USRPs’ data and my local application, to handle the
various network transfer and configuration issues involved. I realize
doing this is possible in C++ with SWIG, but I’d thought I’d try to do
it first in Python and see if it was doable (the speed issues aren’t
really a factor, as the network connection is going to be my main
bottleneck).
I've read through the various .c, .h and .i files for gr_block,
gr_basic_block and flow_graph, and created my python class accordingly.
As far as I can see, I’ve implemented every method necessary to make my
gr_pyblock class a drop-in replacement for the gr_block class. I’ve
created a test very similar to the “writing your own block” document,
and everything seems to work without errors (I’ve done more than a day’s
worth of dropping in print statements everywhere in the library to
determine that the io_signature and block_details of my class are
receiving the right values), however, when the flow_graph gets forked to
a different thread, it stalls indefinitely. Replacing my gr_pyblock
implementation with the example code provided makes it work again. I’m
stumped as to where the problem is, and I’ve attached all of my work so
far. I’d greatly appreciate any help in this matter, or suggestions as
to where to look for problems.
Thank you!
Dev R.
P.S. I apologize if attachments aren’t to be sent on this list, please
let me know if I’m incorrect in doing so
Thanks for your help John, I haven’t tried it yet, but the
gr.udp_source/sink seems like it would work pretty well for what I
need to do. Reading through your comments and spending more time with
my previous code, it seems like you’re correct about the C++ portions
of gnuradio not being able to call back up to my python general_work
function. I’ve been reading through various portions of the codebase
and the SWIG docs, and I’ve thought of a couple of things that might
work (using SWIG directors maybe?). I’ll try to come back at some
point and submit that patch
It gets more complicated, though, as the flowgraph is operating in a
different thread from the Python interpreter “main” thread that calls
fg.run(). So calling back up into Python via SWIG will need management
of the Python global interpreter lock, and you need to worry about all
the typical multi-threaded issues of deadlock and race conditions.
If I haven’t scared you into using gr.udp_source/sink yet, then study
the gr_feval.* implementation in the trunk code. You won’t be able to
use this directly but it does show all the hackery needed to go back up
into Python from C++ when running in a separate thread.
to serialize. I’d like to implement my own blocks in python to sit
What you’re doing here is breaking new ground, not the way gnuradio is
GNU Radio itself has data source and data sink blocks for capturing data
is simply the binary representation of the data stream in that part of
patches welcome
Thanks for your help John, I haven’t tried it yet, but the
gr.udp_source/sink seems like it would work pretty well for what I need
to do. Reading through your comments and spending more time with my
previous code, it seems like you’re correct about the C++ portions of
gnuradio not being able to call back up to my python general_work
function. I’ve been reading through various portions of the codebase and
the SWIG docs, and I’ve thought of a couple of things that might work
(using SWIG directors maybe?). I’ll try to come back at some point and
submit that patch
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
