Re: [Discuss-gnuradio] How can we make GNU Radio better?

[Martin Braun]

On Tue, May 10, 2011 at 12:11:55PM -0400, Michael Dickens wrote:
> On May 10, 2011, at 4:21 AM, Martin Braun 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 Braun
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

pgpIZFBYmolxp.pgp
Description: PGP signature