GNU Radio Conference 2011

GNU Radio
1

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

2

On 08/29/2011 08:31 PM, Tuan (Johnny) Ta wrote:

me too (as you can see I still have too vague of an idea about
should I jump straight into the C++ blocks.
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 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 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).

3

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: [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
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 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
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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

Very interesting ideas. Thanks Marcus for sharing! Unfortunately I don’t
have enough background in compiler to implement such ideas. I’m in the
phase
of learning GNU Radio, keeping up with its fast development is already a
big
task for me. I’m certainly willing to do something to GNU Radio when
I’m
more capable and the opportunity presents. But I can definitely see some
CS
grad student picking this up.

My question is more of what I can look at/practice so that I can ask the
right questions at the conference, if my goal is to be familiar enough
with
GNU Radio to implement my own applications/algorithms. Given that there
are
only 2 weeks left, I think wandering around might not be a good idea.

Thank you,
Johnny

5

Patrik,

I’m not sure I understand what you’re saying. I know my knowledge is
limited
especially my coding skill (I come from a more theoretical background).
And
I think the best way to learn is to watch others do it first and
practice.
I’m sorry if that’s completely off your point.

Johnny

6

Martin,

Thanks for the suggestion! I think it’s a good idea. I remember having a
lot
of problems with the OFDM receiver. The frequency offset between the 2
oscillators screwed things up. Looking around, I don’t think this issue
has
been resolved. Correct me if I’m wrong.

Thank you,
Johnny

7

If you are having frequency offset problems, you need to synchronize the
USRPs with an external reference, i.e. a GPS receiver.

Scott

8

Scott,

I thought the frequency offset should be taken care of by the receiver
synchronization? The 802.11 NIC don’t have external reference but they
can
still sync to the AP.

Thank you,
Johnny

On Tue, Aug 30, 2011 at 9:04 AM, Scott Johnston

9

On Mon, Aug 29, 2011 at 11:19:39PM -0400, Tuan (Johnny) Ta wrote:

left, I think wandering around might not be a good idea.
Hi everyone,

I actually think doing something with GNU Radio is the more
interesting part, at least at the beginning. How about you start writing
a receiver for your favourite comms standard?

That way, you can start with a fairly simple environment, use a lot of
code templates and concentrate on what you already know.

Once you start doing that, you will inevitably end up with something
that annoys you, something you feel is inefficient or whatever. Then
you’ve got something to discuss about at the conference :slight_smile:

MB

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

10

On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech [email protected]
wrote:

you can see I still have too vague of an idea about research topics). The
data into a file and work with Matlab is easier. I have never used the QT
do with Gnu Radio as it currently stands, but what could
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.

Marcus,
That’s a GREAT idea. It goes about solving a pretty serious limitation
in the GNU Radio concept. We make blocks as small as possible. Each
one is supposed to have one responsibility to make it as generic and
reusable as possible. This leads to lots of data moving and buffer
copies that are overhead. While it’s a great way to develop, test,
experiment, etc., at the end of the day, we often come down to a
single, static flowgraph that could be optimized by coupling many of
the blocks together.

This seems to be more of a CS issue, though, so a student focused on
communications or an EE degree isn’t likely to have the skill (or
desire) to go that deep in to something like this. But I would love to
see someone take this up as a project.

Tom

11

On Tue, Aug 30, 2011 at 3:25 AM, Martin B. [email protected]
wrote:

to implement my own applications/algorithms. Given that there are only 2 weeks

Once you start doing that, you will inevitably end up with something
that annoys you, something you feel is inefficient or whatever. Then
you’ve got something to discuss about at the conference :slight_smile:

MB

Yeah, Martin, I think there is room for both. A point that I have
often brought up is that software radio is a mix of disciplines, all
of which are important in doing real, interesting things with
communications. But we do tend to specialize, so pushing the
boundaries of the technology in any direction is going to require
study and expertise in some areas over others. For comms people,
building new things with GNU Radio is probably the best thing that
they can do. Then, like you said, we’ll learn where the platform
doesn’t perform and hopefully work on fixing it.

For those more inclined to the CS side of things, doing something like
Marcus suggested might be better. We have a lot of optimization that
we can do with GNU Radio. We will hopefully start including VOLK soon
to take advantage of vectorization in our processors. The
implementation of VOLK had little to do with any knowledge of
communications. Instead, there was a recognized need for improved
performance that lead to some slick work that made VOLK possible.

In other words. There’s plenty to do for people of all persuasions :slight_smile:

Tom

12

On Aug 30, 2011, at 9:34 AM, Tom R. wrote:

have GRC emit a block of C++ code that subsumes the functionality
copies that are overhead. While it’s a great way to develop, test,
experiment, etc., at the end of the day, we often come down to a
single, static flowgraph that could be optimized by coupling many of
the blocks together.

This seems to be more of a CS issue, though, so a student focused on
communications or an EE degree isn’t likely to have the skill (or
desire) to go that deep in to something like this. But I would love to
see someone take this up as a project.

I’ve been working on this issue for a bit now – I call it “the
computation granularity dilemma” because it deals with how fine a
computation can or should be made. There’s plenty of room for others to
work on this issue too, and I don’t claim to have solved it or that
there is even one good solution to it :slight_smile: I think, under certain
conditions, I can show that this combining can be done and made to work
more efficiently as a group than individually – but I cannot prove it
yet & nor do I have a working example. I cannot think of a good way to
do this combining in a general fashion – or, maybe a better way to say
this is that it doesn’t make sense to combine certain blocks together &
then how to tell the end-user that this particular superblock will not
be better than the individual blocks. I’m working with graph theory for
this part, so, yes, very CS-oriented stuff :slight_smile:

Traditionally, the idea of SDR was a do everything as fine-grained as
possible then slowly build out from there (connecting processes / blocks
/ components to create an application / waveform) – so, we have blocks
for doing specific tasks, and then those are connected together to form
more complicated tasks (at some extra expense in buffering and latency
in computation due to the need to schedule data processing). With
modern specialized processors it makes sense to take advantage of
specialized instructions (e.g., FFT, iFFT, vector math, turbo decode,
viterbi decode, etc as available – think Volk here); and, as Marcus
points out, sometimes we want to do away with the overhead of “buffers
and scheduling” created by the SDR data-flow model – I think these are
effectively the same problem, but approached from different directions.

Because of the way GNU Radio does block definition, I think one would
have to restructure things a bit – the “work” method’s code needs to be
accessible to group into the larger “superblock” instead of embedded in
a compiled & not installed C++ file. I think SCA / JTRS would be
well-suited for this sort of work “out of the box”, since it already
partitions it’s “work”-equivalent functions off – and, because of the
way SCA builds waveforms, these functions could be combined before
compilation starts. In GNU Radio, assuming the “work” methods were
available, GRC would have to compile and make available the new
superblock – not impossible, but not trivial either. Using runtime
compilation (e.g., as in OpenCL) makes this problem much more tractable,
too, but that would require rewriting all of GNU Radio’s blocks – again
not impossible but certainly not trivial either.

Anyway, it’s nice seeing this topic here! - MLD

13

On Tue, Aug 30, 2011 at 7:45 AM, Michael D. [email protected]
wrote:

of

various ways–like integrating GPGPU support in a way that is
single, static flowgraph that could be optimized by coupling many of
too, and I don’t claim to have solved it or that there is even one good
possible then slowly build out from there (connecting processes / blocks /

problem much more tractable, too, but that would require rewriting all of
GNU Radio’s blocks – again not impossible but certainly not trivial either.

Anyway, it’s nice seeing this topic here! - MLD

I’ve also been interested in reducing Gnuradio’s memory bandwidth
footprint.
The idea I had was to classify some blocks as capable of working “in
place”;
i.e., writing their output to the same buffer they use for input. This
way,
the data duplication caused by memcpying buffers around is eliminated.
This
requires changes to gr_buffer to support multiple writers. The criteria
I
put together for determining whether a block can work in place or not
are:

  1. gr_sync_blocks only
  2. ninputs == noutputs
  3. block has only one parent
  4. set_history(0)

The requirements are a little conservative; there are ways to get
history in
there, but it requires more carefulness with the buffers. As the
carefulness
is added restrictions can be removed. If a block fills the requirements
(which are evaluated in gr_flat_flowgraph), it can write its output to
its
input gr_buffer. Multiple blocks can be chained together in the same
way. I
put together a proof-of-concept but haven’t taken it any further than
that.
The benefit to this approach is blocks and flowgraphs don’t have to be
rewritten, and the speedups happen entirely “under the hood”, with no
user
intervention required. Lately I haven’t had time to take it further;
looking
forward to being able to talk about this with some folks at the
conference
as well.

–n

14

On Tue, Aug 30, 2011 at 9:23 AM, Tuan (Johnny) Ta [email protected]
wrote:

Scott,
I thought the frequency offset should be taken care of by the receiver
synchronization? The 802.11 NIC don’t have external reference but they can
still sync to the AP.
Thank you,
Johnny

The standards will specify the frequency offsets required for a system
to work. With the USRPs, the accuracy of the crystal oscillators is 20
ppm (I forget the numbers for the USRP2, but I think the accuracy is
about the same while the stability is better). Most standards require
a much smaller possible offset in their frequencies (0.1 - 1 ppm in
some), so that the maximum possible frequency offset is known and
accounted for in the standard. From there, yes, the waveform
synchronizations are enough.

For large frequency offsets, there are a handful of coarse frequency
correction algorithms out there, or you could measure the difference
and compensate for it, but that’s not scalable. Most things shouldn’t
require an external clock, though, even though a highly accurate
reference would solve these issues.

Tom

15

As I’ve thought about what you wrote, Nick, the more I like it. As you
say, it won’t work for every block – but there are certain blocks that
would benefit from doing “in-place” computations, avoiding the extra 1
or 2 buffer copies per call to “work”. And, the implementation needs to
be transparent to the end-user (e.g., using GRC; it should be entirely
“under the hood” changes).

As for implementation in GNU Radio: I think what you’re thinking of
doing is 2 parts: (1) for “in-place” type blocks, they just get input
buffer(s), no output buffer(s) (since they re-use the input buffers for
the in-place computation). (2) duplicate all input buffer(s) for blocks
to which this block is connected – thus the need for multiple writers
for a given buffer. Is this roughly the concept?

I certainly hope to be at the GNU Radio Conference, and would love to
discuss this & the other “under the hood” topics with you (& others). -
MLD