Re: [Discuss-gnuradio] GNU Radio Conference 2011

[Marcus D. Leech]

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.

On a similar track, the CASPER folks at Berkeley have an interesting tool-chain for taking MatLab/SimuLink simulations, and producing
  downloadable VHDL (either Verilog or VHDL) for their various FPGA hardware.  My thought would be wholesale theft of that idea, but
  using GRC as the high-level design abstraction, and having *something* that can produce some subset (or all) of the flow-graph that lives on
  FPGA hardware (like USRP-family or other similar devices).

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org