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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
