[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Python gr_block implementation

From: Dev Ramudit
Subject: Re: [Discuss-gnuradio] Python gr_block implementation
Date: Wed, 27 Jun 2007 14:04:36 -0400
User-agent: Icedove (X11/20070329)

Johnathan Corgan wrote:
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

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

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

(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 :-)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]