Re: [Discuss-gnuradio] GNU Radio Conference 2011

[Tom Rondeau]

On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech <address@hidden> wrote:
> On 08/29/2011 08:31 PM, Tuan (Johnny) Ta wrote:
>
> I'm very excited for the upcoming conference. The issue is I haven't worked
> on GNU Radio for almost a year. And I see that there're quite a few changes.
> Even when I was working with GNU Radio, I couldn't say that I was very
> comfortable with it.
> So my question is in the next 2 weeks, what can I do the best prepare myself
> for the conference?
> I'm a grad student in Communications and Signal Processing. I plan to use
> GNU Radio (and USRP2) to implement systems that my research leads me too (as
> you can see I still have too vague of an idea about research topics). The
> systems might start simple as a way to measure the wireless channel in
> different conditions, to more complicated as real-time video streaming, or
> even a full-blown WiMAX receiver.
> In the past I've had a lot of problems with debugging GNU Radio codes.
> Debugging techniques are certainly among the things I want to learn out of
> the conference.
> Some other goals I can think of:
> - Development process: should I start with Matlab simulation code, or should
> I jump straight into the C++ blocks.
> - Representing results: is it convenient to use the QT interface, or dumping
> data into a file and work with Matlab is easier. I have never used the QT
> interface.
> - Staying up-to-date with the new features such as VOLK, stream tags
> It's a pity that the hackathon is called off. I was really looking forward
> to seeing some of the GNU Radio top developers actually writing codes.
> Thank you,
> Johnny
>
> You know, some things I've thought about for a long time in the context of
> "what cool things could a grad student do in the context of
>   Gnu Radio".  More interesting, for many of us here, isn't what you could
> do *with* Gnu Radio as it currently stands, but what could
>   you do *to* Gnu Radio.
>
> For example, GRC was developed as a student project by Josh Blum (although
> he took over from someone else, whose name escapes me).
>
> One idea, which I credit to a conversation I had with Frank Brickle some
> months ago, is the ability to synthesize a new block using a collection
>   of sub-blocks, and have it be "efficient".  For example, in GRC, I might
> draw a box around a collection of relatively-cheap, adjacent, sub-blocks,
>   and command GRC to produce a compiled object that is the aggregation of
> those adjacent functions into an efficient "superblock". The idea
>   is that for simple blocks, it may be more efficient (and likely *is*) to
> have them avoid the buffer/block-scheduling *internally*, and only have
>   them visit the block/buffer scheduler *at the edge*.  The approach might
> have GRC emit a block of C++ code that subsumes the functionality
>   of the selected adjacent blocks, and then it gets compiled and linked-in
> to your final flow-graph.  The idea could obviously be extended in
>   various ways--like integrating GPGPU support in a way that is "seamless"
> in GRC--provide a separation between function and implementation
>   that we don't really have in Gnu Radio.

Marcus,
That's a GREAT idea. It goes about solving a pretty serious limitation
in the GNU Radio concept. We make blocks as small as possible. Each
one is supposed to have one responsibility to make it as generic and
reusable as possible. This leads to lots of data moving and buffer
copies that are overhead. While it's a great way to develop, test,
experiment, etc., at the end of the day, we often come down to a
single, static flowgraph that could be optimized by coupling many of
the blocks together.

This seems to be more of a CS issue, though, so a student focused on
communications or an EE degree isn't likely to have the skill (or
desire) to go that deep in to something like this. But I would love to
see someone take this up as a project.

Tom