Re: Why Isn't GNU Radio Used More?

[mdeering]

On May 9, 2011, at 2:48 PM, Alexander C. wrote:

Dual-licensing is a flawed model, it’s truly hard to make it working
right.

From what I understand, dual licensing mostly works for Qt – and, I
doubt that Ettus would be exploring it for UHD if it didn’t have some
merits. I wonder if you can elaborate on how/why it is flawed?

I believe that something like LGPL would be sufficient.

I fully agree, but I doubt that the FSF will downgrade the license to be
just LGPL. They might allow a second license as a means of income? -
MLD

[mdeering]

On 5/9/11 9:08 AM, Philip B. wrote:

I don’t see any point trying to appease the free software is anti IP
crowd. They will just invent new excuses. It is our job to help these
people understand how things really work.

I agree, so let’s start at home.

No embedded engineer who values his job will touch a GPL piece of code
with a 10 foot pole. Period.

A good embedded engineer will use Linux only under duress. And that
will be the only GPL code he will use.

Anyway, the largest generator of dollars in the free software world is
the Linux kernel, and that is GPL. So economics suggest GPL is the way
to go.

Please note that the Linux kernel explicitly restricts you to GPLv2
ONLY because they don’t like some of the sharing requirements of
GPLv3.

You might want to try to convince the Linux folks to move to GPLv3
before preaching the GPL sharing gospel to others. Mysteriously, they
don’t seem particularly enlightened about it.

It is, after all, easier to preach to the converted, right?

Oh, don’t mind the laughter. We’re laughing with you.

-a

[mdeering]

Good points, Kunal. I know that Tom has talked about having nightly
builds for the major OSs – as much as anything to make sure that the
GIT master always compiles and passes “make check” at the end of the
day. Maybe he could also set up that system such that it provides those
builds as installable tarballs? I think part of the issue here is that
GNU Radio has so many -required- dependencies that the tarball would be
very large for some OSs to make sure all of the dependencies are met –
certainly not impossible, but maybe difficult until gnuradio-core is
further split into smaller parts? - MLD

[mdeering]

Hi all,

You are just totally wrong and have understood GNU Radio erroneously!

I wonder what your ear say when I say Software deinded Radio?
I hear versatile (modifiable) using software to define just my task.

GNU Radio is open software, if you want to listen at submarines,
aircrafts,
what ever satellites, etc
the CORE is in GNU Radio, mod it as you want. Notice, it aint easy (just
like that) it takes skills and alot of testing.

1: jams so many different fields of expertise into one package.
It jams most fields (I’d say most if not all), it is up to you to
choose
your field

I wont answer your 2, 3, claims since they are words from an uneducated
user.

Patrik

----- Original Message -----
From: “Colby B.” [email protected]
To: “Alexander C.” [email protected]
Cc: [email protected]
Sent: Monday, May 09, 2011 21:33
Subject: Re: [Discuss-gnuradio] Why Isn’t GNU Radio Used More?

[mdeering]

I believe this conversation has strayed quite a bit from GNU Radio
itself. Whatever you believe about licensing, IP, versions of the GPL,
etc., the fact is that for better or for worse, GNU Radio is licensed
under GPLv3. The only way that will change is if FSF releases a GPLv4.
It is something which is up to the FSF.

The conversation about ways to bring more people into the community are
very useful. I truly believe that GRC takes away 95% of the need for
the user to actually code in either Python or C++. To me, the real
question is how to get that last 5%.

As for Windows support, Josh has been working on making Windows
installers for GNU Radio. Nearly all of the main components are in
there. With this, a Windows user never even needs to compile anything
or worry about dependencies. See:

http://www.joshknows.com/gnuradio_port#binary_packages

Matt

[mdeering]

I truly believe that GRC takes away 95% of the need for
the user to actually code in either Python or C++. To me, the real
question is how to get that last 5%.

I’d say as long as GNU Radio is used for R&D, we’ll never be able to get
rid
of that last 5%. With R&D people are often trying to use GNU Radio in
ways
that have not been previously anticipated. Maybe you weren’t talking
about
that 5%, though.

As for Windows support, Josh has been working on making Windows

installers for GNU Radio. Nearly all of the main components are in
there. With this, a Windows user never even needs to compile anything
or worry about dependencies. See:

Josh Knows | CMake GNU Radio Port

Wow, that looks great! On any *nix, I have no qualms about going into
bash
and building from source. But I think Windows users (I still consider
myself
one) are just too used to installers with GUIs. This will definitely
make
GNU Radio attractive to a larger audience.

Kunal

[mdeering]

On Mon, May 9, 2011 at 2:59 PM, Andrew L. [email protected]
wrote:

No embedded engineer who values his job will touch a GPL piece of code with
a 10 foot pole. Period.

…and these are folks who will be out-competed in the marketplace by
competitors who are more agile and less phobic.

[From the original article]

Conversely, the DSA community seems to want to keep reinventing
solutions. Every year we see demos that are slightly more polished
and maybe a bit more expansive than the previous year’s, but we still
aren’t really seeing huge leaps and bounds in the technology that I
think we could and should be seeing.

The obvious explanation is that there isn’t actually a market in this
space
people build things here in order to demonstrate how smart and capable
they are— advancing the art is hard and isn’t strictly necessary
for just showing that you know how to build yet another slightly better
wisbang.

Marcus D. Leech wrote:

I think there’s a significant community out there that learned DSP
techniques inside the envelope of Matlab/Simulink, and that’s what
they’re comfortable with. To change this, Gnu Radio has to appear
in more places in academia, so that graduating engineers have already
been exposed to it, and find it “natural”.

One positive thing here is that python (esp with scipy/numpy) has been
aggressively replacing matlab/octave in many areas. It seems that
that this has gone slower RF DSP area, but this shouldn’t be surprising
because there is a larger dependency on canned DSP objects than in
some other areas.

Personally, I don’t find the adoption curves surprising. The entry cost
for GNURadio + USRP are low compared to traditional tools, but those
who could afford those are mostly already comfortable with the toolset
they already know. The entry costs are very high compared to pure
software activities or heavily commodity activities. If someone is
doing development of high level communication systems using standard
ethernet $20 off the shelf 802.11 gear then the cost (in terms of time
and hardware) of doing anything with GNURadio are basically
astronomic.
(And they would still be even if the USRP were free, though less so)

[mdeering]

On May 9, 2011, at 3:13 PM, Matt E. wrote:

I believe this conversation has strayed quite a bit from GNU Radio
itself.

Not entirely, because I think a number of us believe that licensing is a
real issue. But, as you say, that ain’t gonna change any time soon
unless the FSF decides to do so – so, really, that point has been made
and we need to move on to other points.

And: Let’s keep the discussion polite – no name calling please! Each
of us is entitled to our opinions, no matter our education level. So
long as we Godwin’s Law doesn’t actually come to pass, I think we’ll be
OK.

As for Windows support, Josh has been working on making Windows
installers for GNU Radio.

Go Josh! Can we clone him for the documentation effort? - MLD

[mdeering]

On 09/05/2011 2:25 PM, Michael D. wrote:

I often use GRC for simple tasks – it’s a LOT faster than writing Python
scripts, and it “just works” for these tasks. Admittedly, these are simple –
such as reading a file of audio data, adding in gain, and then both displaying a
waterfall FFT and piping the data to audio out. I do agree that for any
cutting-edge project what you write is true, but if GNU Radio accumulates blocks
over time GRC will eventually fit the needs of that 90+% I keep talking about. Of
course, that ~10% will always remain, as they are the cutting edge folks.

There’s a growing expectation that Gnu Radio exists to provide
functional blocks for all parts of your communications system. I
think that’s
a flawed model, and flies in the face of sound modularity
principles. There’s an expectation that Gnu Radio handle “everything”,
and I just
don’t think that’s a good model. Gnu Radio, to me, is a DSP engine
that happens to live on a general-purpose compute platform. But it has
become “sullied” over the years with “other stuff” unrelated to
strictly-signal-path problems. Attempting to shoe-horn “stuff” that
isn’t
strictly signal-path oriented into Gnu Radio will cause both
unnecessary bloat in the codebase, but more-importantly, it will cause
people
to suffer grief in that they’re trying to use the wrong paradigm to
solve the not-strictly-signal-path parts of their “solution”.

True, but it’s an enormous class. Maybe I’m too limited, but I cannot think of
a communication algorithm that can’t be implemented graphically in GRC, somehow
(or the equivalent, via some combination of a data-flow graph and text command
line such as provided by Python).

See above. The problem is that people want the Gnu Radio signal-path
paradigm to solve problems that aren’t necessarily directly signal-path
related. Strictly speaking, for example, none of the GUI stuff
should be in Gnu Radio proper at all. But it’s awfully convenient. The
thinking that
lead to non-signal-path processing inside Gnu Radio is, I would
assert, a strong reason for people finding it “wanting”–they naturally
expect
that it does “everything”. Which it can’t. Hmmm, I wonder if a
flow-graph is Turing complete? Another example: HTML. HTML can be used
to solve a vast number of problems, and indeed rich “applications”
have been constructed using HTML. But (at least early versions of) HTML
isn’t Turing complete–it’s not a complete programming paradigm, and
so much functionality must necessarily be implemented outside of
it. I would assert that Gnu Radio is in the same category–it’s a
paradigm for managing mathematical data-flow. So, when you have a
problem
that falls outside of that model, you have to ask yourself: is it a
flaw in the model, or a flaw in my reasoning about the applicability of
the model
to my application? From what I’ve seen on the list over the last
several years, a goodly chunk of “heartburn” on the part of newbie users
is
due to imperfect understanding of the model, and incorrectly
assigning functional pieces to the flow-graph model.

True, but that’s OS-dependent and a nuisance. Why not the dual-license approach
– one as GPL and another that allows for local IP (the LGPL would probably
suffice)? Again I don’t know if the FSF would allow it, but there are plenty of
potential end-users who would benefit from this model. - MLD
I’m not an expert on licensing issues, which is why I’ve avoided them in
the couple of small-scale commercial systems I’ve done with Gnu Radio as
an
underlying “engine”.

[mdeering]

On 09/05/2011 2:22 PM, Alexander C. wrote:

Is it that hard to re-license it under LGPL? Really.

I don’t know. But in the meantime, Linux has such a rich set of IPC
primitives (and programming languages, etc, etc), that using Gnu Radio
as
your base and mixing in your own proprietary secret sauce shouldn’t
be that big a deal, even in lieu of different licensing.

I’ve done it that way a couple of times. If Gnu Radio moves to LGPL, I
might reconsider some of that work. But it also allows me to isolate
my proprietary GUIs and “other stuff” for functional and “good
programming practice” reasons as well.

[mdeering]

Gregory-

On Mon, May 9, 2011 at 2:59 PM, Andrew L. [email protected] wrote:

No embedded engineer who values his job will touch a GPL piece of code with
a 10 foot pole. Period.

and these are folks who will be out-competed in the marketplace by
competitors who are more agile and less phobic.

That sounds more wish than reality. For example, Apple is hardly being
out-competed for being closed.

Andrew makes an excellent point – for-profit entities will avoid GPL if
it means placing their code of value into the
public domain. They will use GPL code when it saves time/cost and
continue to find ways to mix and match with
binary-only modules, physical separation across a bus or between
dissimilar chips (or cores within an SoC), and other
ways to “box” their proprietary code.

Discussion about how to solve this within GNU radio is useful… could
user-defined processing blocks be added that
run on a GPU accelerator? Could a version of the USRP be made available
that contains an OMAP or other device that
would allow substantial user-defined baseband processing? Basically,
some place to insert in the data flow
user-defined code that has no GPL dependency. Documented reference
examples showing how to do this would bring more
users to GNU radio.

-Jeff

Over time, , whateverGPL whenever they can an

[mdeering]

On Mon, May 9, 2011 at 1:49 PM, Michael D. [email protected]
wrote:

I think it is important to point out, is that most baseband
processor design seems to follow a buffer-esque* based model for
implementation in silicon. A lot of wireless standards switch
modulation and coding midway through frames. Look at 802.11, GPP
Release XX, etc as examples. You need a sample buffer to jump to and
from in, to correctly decode a frame/packet/burst/etc. I don’t always
find this easy with the GNURadio framework, or maybe I am doing it
wrong.

*I say buffer-esque because once the buffers have been carved out, a
specific will go down a specific demodulation chain, i.e. CCK
modulation or DQPSK.

[mdeering]

On May 9, 2011, at 4:42 PM, Marcus D. Leech wrote:

Gnu Radio, to me, is a DSP engine that happens to live on a general-purpose
compute platform.

True. But the GNU Radio model is build on data-flow, while the Octave
model is not – and, that might be a key difference. People have grown,
for better or worse, used to using the MATLAB / Octave script processing
model – which is buffer based instead of block based. I don’t see a
need to change GNU Radio’s model – but rather to note that it is
different from MATLAB / Octave & thus new(er) users need to think
differently about how to write GNU Radio scripts. I doubt this
difference in models makes any difference in adoption, but maybe it
does? - MLD

[mdeering]

4.) Make sure I don’t have to publish the source if I write some
specific block or application for/with GNURadio. My boss and our
customers are kinda sensitive about giving out information that are
operatively relevant :).

I’m pretty sure you only have to release the source to people who you
are giving/selling the software too, and only if they ask for it. So
if you’re developing the software for one customer there is no issue
at all. If you have more than one customer, then the customers all
need to trust one another not to release the source publicly (maybe
possible in some cases?). There is no obligation to make the source
public.

Ben

[mdeering]

I think that you’ll find many people who cross multiple fields of
expertise on this list – I think that’s part of the fun of SDR and GNU
Radio to many of us. Your point that SDR encompasses many disciplines
is valid, and certainly leads to a steep learning curve for some people.
I have, in general, enjoyed the learning associated with SDR, GNU Radio
& GRC, but I also believe it is an impediment for others. - MLD

[mdeering]

On May 9, 2011, at 5:12 PM, Ben R. wrote:

I’m pretty sure you only have to release the source to people who you
are giving/selling the software too, and only if they ask for it. So
if you’re developing the software for one customer there is no issue
at all. If you have more than one customer, then the customers all
need to trust one another not to release the source publicly (maybe
possible in some cases?). There is no obligation to make the source
public.

I think your interpretation is generally correct, but probably not
complete either.

Also: GNU Radio is under GPLv3, so there are other restrictive clauses
– e.g., regarding patentability of the licensed & any derived code.
GPLv2 doesn’t have these additional restrictions, which IIRC is why
Linux is still under it instead of v3.

While discussing GNU Radio’s license is interesting and important,
there’s nothing we can do about it for GNU Radio: as Matt & I have
written, that’s up to the FSF. There are plenty of other arenas where
we can do something. So, we need to be directing our comments in other
places – such as ways to “make GNU Radio better” as Philip started. -
MLD

[mdeering]

schrieb Marcus D. Leech am 2011-05-09 17:12:

The documentation, as Tom observed, is disorganized and incomplete.
This is rather an inevitable result of a system that grows organically
as it has–99% of the contributing participants are largely coders, and
not so much document writers.

I don’t think that “outsourcing” documentation from coders is the way to
go. It’s the coders that know about the functionality. They also know
the rationale behind the creation a a certain part of the system and all
the implementation details: Why was this implemented in this way and not
another, what are the strengths, what is important to know, what would
be a dis-use of the component, etc.

Of course not every coder is a good User Documentation writer. This may
be because the coder would have problems to imagine a point of view
without all the details he already knows, or he/she is using the system
in a very special way, which would be quite different from the
mainstream use.

So I think the best situation would be to have the coders write API
documentation and document design decissions - this could be a text
document in the source tree, a blog post or a summary to a mailing list
discussion; it should last and be accessible. Then more usage-oriented
people with a broader, less detailed view create a users documentation.

IMO GNU Radio lacks a lot of low level docs and design docs. Referning
to the (undocumented) source code is not documentation.
That Howto is a good starter, but I think it does not fit the needs of
the average user: Putting blocks together that just work.

Sometimes one can find some glimpses of rationales of new features on
the mailing list, but in general my impression is that the future design
is decided by people off-scene.

Just my 2 -Cent…

Regards

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telemati_cs_, Techn. University Graz, Austria

[mdeering]

Martin-

:
:

To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason:

• Matlab is generally free of charge for universities
• Matlab is used by the industry
• Matlab is better documented and has a wider user base
• Simulink has more blocks already incorporated
• Matlab/Simulink has a much wider applicability outside realtime DSP

Here at CEL, the majority of student’s projects are done using
Matlab/Simulink.

In that case, what hardware are your students using with
MATLAB/Simulink?

-Jeff

[mdeering]

On Tue, May 10, 2011 at 09:07:38AM -0500, Jeff B. wrote:

Matlab/Simulink.

In that case, what hardware are your students using with MATLAB/Simulink?

Most use USRPs, but we also have some Lyrtech SFF SDRs.

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

[mdeering]

On Mon, May 09, 2011 at 11:33:32AM -0700, Colby B. wrote:

3. Hardware people also get lost in the digital comm stuff, and also
   some of the software. However, they tend to be less confused than the
   ‘maths’ people on the programming aspect

This sounds like it’s from the 80ies. Things have changed a bit;
education
has become more ‘fluid’ and it’s not a big deal to know a bit of
everything. Of course, you’ll never know all of everything, but if you
engage in a new project, you always have to learn new stuff as well.

I believe that our university is no different from many others in a
sense that if you graduate with a major in communications engineering,
you’re supposed to know at least two of your these; and let me also
point out that you can omit a lot of hardware knowledge if you want to
use GNU Radio.

Let me rephrase: People struggle with GNU Radio because it jams so many
difficult fields into one package. SDR is not, and never will be,
easy. Writing a receiver for standard XYZ (which can operate in
real-time) is always a daunting task, and there is no way to make it
simple.

The difference between Matlab and GNU Radio is that the guys from
Mathworks make it look easy, whereas are favourite software package
scares away the people who are not used to scarce documentation and
autotools.

My apologies, Colby, for interpreting your email in a way you probably
didn’t mean it. But what you wrote sounds like it’s the user’s fault GNU
Radio isn’t used more often. And well, it is of course, but frankly, we
haven’t made the biggest effort to make the decision between
Matlab/Simulink and GNU Radio flip to GR’s benefit.

To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason:

• Matlab is generally free of charge for universities
• Matlab is used by the industry
• Matlab is better documented and has a wider user base
• Simulink has more blocks already incorporated
• Matlab/Simulink has a much wider applicability outside realtime DSP

Here at CEL, the majority of student’s projects are done using
Matlab/Simulink. In those cases where the students chose GNU Radio, all
these things were true:

• The student had some background in open source dabbling (e.g. using
  Linux)
• The student was not scared away when I explained that the learning
  curve is intimidating
• The motivation to do the thesis was beyond simply wanting to earn
  credits

I guess if we really want more people to use GNU Radio, it’s up to us,
the active community, to get them on board.

MB

PS: I’m not really good at short posts

–
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