How can we make GNU Radio better?

GNU Radio
1

Rather than flog the topic of what is wrong with GNU Radio, I’d prefer
to emphasize that it is only as good as we make it. So how can we make
it better. Here are some of my thoughts:

  1. Expand the pool of people contributing code.

  2. Improve the grc help files and parameter descriptions.

  3. Divide the code base in to true core functions, signal processing
    libraries, and applications.

  4. Use cmake instead of autotools. (Not my first choice, but may help
    the windows people)

I’m not certain what the way forward is. How can you help make GNU Radio
better?

The license thing can turn into a tar pit and flame war very easily, and
that draws peoples focus away from these core issues. Before spending
much bandwidth on the license issue, we should find out what options are
available since all the code has the copyright assigned to the FSF.

Philip

2

On Mon, May 09, 2011 at 03:23:21PM -0400, Philip B. wrote:

Rather than flog the topic of what is wrong with GNU Radio, I’d
prefer to emphasize that it is only as good as we make it. So how
can we make it better. Here are some of my thoughts:

  1. Expand the pool of people contributing code.

  2. Improve the grc help files and parameter descriptions.

  3. Divide the code base in to true core functions, signal processing
    libraries, and applications.

3a) Remove inconsistencies which have popped up due to the organic
‘growth’ of GNU Radio over the last years.

  1. Use cmake instead of autotools. (Not my first choice, but may
    help the windows people)
  1. Improve the development interface. When you’re developing stuff with
    GNU Radio, you’ll probably be using a lot of existing blocks and adding
    a few of your own. This process is still quite clumsy in my opinion and
    would be easier if
  • there were better DSP debugging tools (e.g. nicer graphical sinks you
    can simply connect your blocks – I’d say that anytime I need to pipe
    the output from a block into a file_sink and then analyse it with
    Matlab, that’s when the development interface is lacking),
  • GRC could be tied into the development chain (e.g. inspect hier_blocks
    by double-clicking them, inspect output of individual sub-blocks)

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

3

On May 10, 2011, at 4:21 AM, Martin B. wrote:

3a) Remove inconsistencies which have popped up due to the organic
‘growth’ of GNU Radio over the last years.

Can you elaborate on what you see these inconsistencies to be? Even
just an example of one would probably suffice. - MLD

4

On Tue, May 10, 2011 at 12:11:55PM -0400, Michael D. wrote:

On May 10, 2011, at 4:21 AM, Martin B. wrote:

3a) Remove inconsistencies which have popped up due to the organic
‘growth’ of GNU Radio over the last years.

Can you elaborate on what you see these inconsistencies to be? Even just an
example of one would probably suffice. - MLD

Sure!
I’ll just name some things from the top of my head… I’d like to
compile a longer list, but that would take some more time that I have
right now:

  • It is often unintuitive to me what the inputs, outputs and parameters
    of
    blocks are. The suffix ‘b’ either means bits or bytes: See e.g.
    gr_decode_ccsds_27_fb vs. most of the other ‘b’ blocks.
    gr_ofdm_demapper_vcb and gr_ofdm_bpsk_demapper could theoretically do
    the same thing, but are completely unrelated in terms of init
    parameters and block inheritance. gr_channel_model… does it take
    complex or float? Well, complex of course but is says so neither in
    doxygen nor is it suffixed.
  • Getters sometimes have a ‘get_’ prefix, but usually they don’t.
  • From the ‘how to write a block’ document, I assumed that files
    containing blocks have a gr_ prefix, whereas files with the gri_
    prefix implement something. This is not consistent (e.g. gr_crc32).
  • Why is gr_firdes not in ‘filter/’? And why are the window functions in
    the gr_firdes namespace (say I’d like to use them for spectral
    estimation)?
  • There’s a lot of code in the GR core which does not follow the same
    conventions as the other code, e.g. the stuff in viterbi/ and
    reed-solomon/, and some of the filter stuff. I assume this is because
    it’s copied from other projects, but at first glance it seems rather
    out of place. Since browsing the source tree is the main source of
    documentation, this makes the process of understanding GR a bit
    ‘bumpier’. I also believe this leads to multiple implementations of
    things (aren’t there several implementations of Bessel functions?) and
    kludge like the the second half of gr_remez.cc (commented out code).

I realise most of these things are very typical for such a large FOSS
projects with so many contributors, but still, I can imagine they can
confuse other people than me.

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

5

On Wed, May 11, 2011 at 2:57 PM, Michael D. [email protected]
wrote:

they end up having these same issues.

Martin,
I agree, that’s not a bad list. And as you know and Michael pointed out,
these things to have a way of moving by themselves, even if there is a
supposed style structure.

one (I remember having such a discussion with Eric, but I don’t know if a
“formal” document was ever created) – examples off the top of my head
include:

Yes, I’ve had a bit of this in the works but probably need to put more
emphasis on it.

One quick change in definition/language here. We’re not talking about
the
API, really (some of it is, like the get_ and set_ concept). This is the
coding style. The API is actully fairly stable. This has been one of the
concept behind our versioning. Anything in the master branch maintains a
consistent API. It might not be as consistent between blocks as you
might
like, but within a block, we don’t change the API until we update a
version.

So what we really want to discuss is the coding style, which will
involve
some common concepts of API’s into blocks.

Just to point out that another issue with changing API’s is that we have
a
huge base of code, so if we change a style of doing something, it would
be
nice if we could go back and change everything else to meet the same
style.
Obviously, we don’t necessarily do this.

  • underscore_separated_names but never CamelCase;
  • separate method names (“get_foo” and “set_foo”) instead of method
    overloading (“foo ()” and “foo (foo_type new_foo)”);
  • ‘b’ for bit, ‘B’ for byte, ‘c’ for char, ‘f’ for 32-bit IEEE float,
    etc…

I agree with points 1 and 2 here. In fact, the Qt Gui work that I
inherited
is largely in CamelCase (underneath, the GNU Radio interface bits
conform to
our style) and I’ve been wanting to change that. But again, it’s a lot
of
code and not enough time to worry about something like that. I have my
compulsions for this kind of thing, but they only go so far.

On the third point, we have a problem. ‘c’ is used for complex numbers,
so
what do we do about characters? I think we’re probably ok with bytes
standing in for character almost everywhere, though. We had some
discussions
with this naming concept in Volk, where I think we’ve come to a much
more
verbose but consistent and explicit naming scheme for data types. I
think
it’s a bit much for GNU Radio blocks, though, and it would involve
redoing
everything.

GRC makes this concept nice, since all ins and outs are color-coded and
it
will tell you immediately if there is a problem.

That having been said, we need to be a bit better about this. The
distinction between bits and bytes is important and confusing (because
it’s
really packed versus unpacked bytes), and unfortunately the ‘B’ is going
to
look odd compared to the rest of it. Plus, because its a
packed/unpacked,
the actual data type is a char regardless.

The other issue is vectors. We use v in the name to indicate that a
vector
is used, but does that mean the input or output or both? I suppose we
want
something like _cvcv for both and _cvc for a vector on the input and
_ccv
for a vector on the output. I don’t really like how that looks, but it
would
work.

I’m sure if you (Martin) wanted to do the legwork organizing such a
document, the rest of us would help review and augment it :wink: - MLD

We really should put this onto the Wiki. By the way, here’s the Volk
style
page:
http://gnuradio.org/redmine/wiki/gnuradio/Volk

Tom

6

On May 11, 2011, at 4:33 AM, Martin B. wrote:

I’ll just name some things from the top of my head… [snip] I realise most of
these things are very typical for such a large FOSS projects with so many
contributors, but still, I can imagine they can confuse other people than me.

For the sake of brevity, I’ve removed your list – it’s a good list BTW,
and yes, quite representative of “a large FOSS projects with so many
contributors”. Heck, when I look at my internal projects: Once they get
large enough it’s difficult for me to remember the “desired” APIs &
hence they end up having these same issues.

Are they confusing? Yes, sometimes. I’ve learned with most of the FOSS
projects that I work on or use that I cannot assume that the API will be
consistent & to make sure to check before using.

Maybe if/when gnuradio-core is split out whoever is doing that work
could also review the APIs to make sure they are consistent – YA API
change won’t kill GNU Radio, though it might be annoying to end-users.

And, before that, it would be good for Tom (since he’s the “benevolent
leader”) to organize a document describing the desired APIs if there
isn’t one (I remember having such a discussion with Eric, but I don’t
know if a “formal” document was ever created) – examples off the top of
my head include:

  • underscore_separated_names but never CamelCase;
  • separate method names (“get_foo” and “set_foo”) instead of method
    overloading (“foo ()” and “foo (foo_type new_foo)”);
  • ‘b’ for bit, ‘B’ for byte, ‘c’ for char, ‘f’ for 32-bit IEEE float,
    etc…

I’m sure if you (Martin) wanted to do the legwork organizing such a
document, the rest of us would help review and augment it :wink: - MLD

7

On May 11, 2011, at 11:06 AM, Tom R. wrote:

On Wed, May 11, 2011 at 2:57 PM, Michael D. [email protected] wrote:

  • ‘b’ for bit, ‘B’ for byte, ‘c’ for char, ‘f’ for 32-bit IEEE float, etc…

we have a problem. ‘c’ is used for complex numbers, so what do we do about
characters? I think we’re probably ok with bytes standing in for character almost
everywhere,

I was using those characters simply as examples; I don’t know if they
translate into what GNU Radio uses or not right now (been a while since
I had to deal with them ;). I think your reply shows that this is an
important naming issue that could use defining. - MLD