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