>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)
Best regards
Patrik
----- Original Message -----
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
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 address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|