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.
Autch, GR is terrible, if you do not know how to “hackathon” C/C++. We
sure are looking forward to see your code and your improvements…
And you have done what in the past/today (links please)
----- Original Message -----
From: Marcus D. Leech
To: [email protected]
Sent: Tuesday, August 30, 2011 3:55
Subject: Re: [Discuss-gnuradio] GNU Radio Conference 2011
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
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 B.
(although he took over from someone else, whose name escapes me).
One idea, which I credit to a conversation I had with Frank B.
some months ago, is the ability to synthesize a new block using a
of sub-blocks, and have it be “efficient”. For example, in GRC, I
might draw a box around a collection of relatively-cheap, adjacent,
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
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
various ways–like integrating GPGPU support in a way that is
“seamless” in GRC–provide a separation between function and
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
FPGA hardware (like USRP-family or other similar devices).
Shirleys Bay Radio Astronomy Consortium