Dev Ramudit wrote:
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).
Short answer:
What you're doing here is breaking new ground, not the way gnuradio is
designed to be used, and probably won't ever work. There is a better
way :-)
Longer answer:
The flow graph infrastructure in GNU Radio is not designed to call back
up into Python, and so deriving from gr_block.h in Python is not a
workable strategy for getting data into and out of a GNU Radio flow
graph from the network.
GNU Radio itself has data source and data sink blocks for capturing data
from and sending data to the network. You can create a listener on a
udp port using gr.udp_source(...), then connect that block as an input
to your GNU Radio flow graph. Going the other direction, you can send
data via a UDP stream by using gr.udp_sink(...), which will encapsulate
items received on the flowgraph into packets and send them out on the
network.
On the receive side in this latter case (or the sending side in the
former), you can use whatever network interface library you like to
generate or receive the data. The format of the data inside the packets
is simply the binary representation of the data stream in that part of
the flowgraph. For example, if you connect a gr.udp_sink to a
usrp.source_c, you will have packets of data that contain single
precision floating point complex numbers (4 bytes for real part, 4 bytes
for imaginary part), in the endian order of the machine generating the
samples.
(Not to say that way you did by making a gr_pyblock was a bad strategy
in principle, just not the way GNU Radio works. It may be possible to
make the call to general_work happen, but I doubt there's enough
interest to make it a standard way of doing things. Nonetheless,
patches welcome :-)