Re: Why Isn't GNU Radio Used More?

[dubstep]

Can we bring Tom’s post to this list?

<
http://gnuradio.squarespace.com/home/2011/5/8/why-isnt-gnu-radio-used-more.html

Yes, I do actually read his posts I hope others do too; he writes
with clarity and has things to say if you’re into SDR and GNU Radio.

I hope Tom’s post sparks some good discussion – not just with me or Tom
(or the usual GNU Radio cohorts), but with more casual users as well
since (I believe) they make up the majority of the folks trying to use
GNU Radio. I will post my initial comments shortly, but I wanted to get
this discussion going. - MLD

[mdeering]

On 09/05/2011 8:53 AM, Michael D. wrote:

Can we bring Tom’s post to this list?

<
http://gnuradio.squarespace.com/home/2011/5/8/why-isnt-gnu-radio-used-more.html>

Yes, I do actually read his posts I hope others do too; he writes with
clarity and has things to say if you’re into SDR and GNU Radio.

I hope Tom’s post sparks some good discussion – not just with me or Tom (or the
usual GNU Radio cohorts), but with more casual users as well since (I believe)
they make up the majority of the folks trying to use GNU Radio. I will post my
initial comments shortly, but I wanted to get this discussion going. - MLD

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”.

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.

There’s a fear of Python, both because a surprising number of folks
don’t know Python, and also because there’s some (largely-misplaced)
fear that a Python-based application will be far too slow for their
application. There’s still ignorance about GnuRadio Companion–I think
a lot of folks think that
it’s only useful for “initial tinkering and playing around”. But I’ve
constructed entire applications with it, and if it were better
documented, more
people would likely use it for production work. The XMLRPC server
feature, for example, isn’t well understood by most follks, but I use it
in two of
my applications to great advantage.

[mdeering]

In addition to Marcus’s comments, a lot of people using GNUradio, myself
included, are not software developers by training. They/we are
electrical engineers interested more in the DSP, communications, and RF
applications than figuring out to put together an application from
hundreds of disparate modules with little to no documentation. Compare
using Matlab to GNuradio: In matlab you can search through hundreds of
help pages that have examples on how to use every single matlab command
and the exact syntax required, whereas with GNUradio, you either spend
hours trudging through source code and webforums or rely on the kindness
of strangers to point you in the right direction by using this list.

GnuRadio is very nice package but the barrier to entry is quite high.

Scott

Marcus D. Leech wrote:

not so much document writers.
feature, for example, isn’t well understood by most follks, but I use it

–
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
[email protected]

[mdeering]

On May 9, 2011, at 11:12 AM, 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.

True; that’s how I did (MATLAB; Simulink wasn’t around yet). I’d take
that a step further: I’d guess that 90+% of -potential- MATLAB /
Simulink / Octave / PyLab / LabVIEW / GNU Radio / GR Companion users
just want the system to work as provided, without having to implement
anything further beyond basic scripts – meaning, for GNU Radio, they
don’t want to have to delve into writing or deciphering C++ blocks, and
SWIG and XML glue necessary to use them in Python and GRC. I don’t know
if GRC provides this what those 90+% need just yet in terms of blocks;
good “help” files / system are a necessity, as pointed out by Scott.

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”.

I think that GNU Radio is pretty well represented in many areas & those
are growing pretty quickly right now. I don’t think GNU Radio will grow
in academia until it is more accessible and meets the needs to those
90+%.

I think to succeed in the way MATLAB did, GNU Radio needs to provide
functionality and documentation for those 90+%, without requiring them
to learn “anything GNU Radio” more than the GRC GUI. For many potential
users, writing C++ / Python / SWIG / XML is too daunting to even
consider – whether because of fear of the unknown, because they are not
well documented, or just because there are too many potential areas for
“difficult to debug” mistakes.

IMHO what GNU Radio needs is a stable API, internal code documentation,
help files for “how to use GNU Radio”, and then a well-written “how to
use GNU Radio” book that includes examples of using GRC. I think this
combination would bring GR/C to the masses – those 90+%. - MLD

[mdeering]

Intellectual Property: Many people / companies view the GPL as being
incompatible with IP – and, whether true or not, this perception is
certainly an issue. To make progress here, maybe GNU Radio could take
Ettus’ UHD dual-license approach, if that is still possible? I don’t
know if the FSF (the copyright owner) would allow such a change;
further, even with that change, I think a separate company would need to
be setup to deal with the non-GPL license. I think having a
less-restrictive license than the GPL would encourage adoption of GNU
Radio in places where IP is an issue. - MLD

[mdeering]

On Mon, May 9, 2011 at 20:08, Philip B. [email protected]
wrote:

issue. - MLD
That’s true - people don’t like GPL and a good library has to do
something about it.

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’m also less inclined to contribute to projects using BSD style licenses
since I see no benefit to me, to contribute to a project that can be used
for profit by people who do not plan to share the code with their customers.

I believe that a library should use LGPL instead of a “clean” GPL.
Then all contributions to the library are shared with the community,
while people are still allowed to build their black boxes.
Re-licensing of GnuRadio as LGPL would be a big step towards much
higher popularity.

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.

That’s not true, Linux kernel itself doesn’t generate $$$.
And to say truth - Linux kernel allows you (1) to load binary
proprietary drivers without open-sourcing them and (2) to use it with
user-space programs without open-sourcing them. And this makes Linux
kernel such an awesome thing.
GnuRadio must follow this model if it wants to be considered seriously.

–
Regards,
Alexander C…

[mdeering]

On 05/09/2011 11:57 AM, Michael D. wrote:

Intellectual Property: Many people / companies view the GPL as being
incompatible with IP – and, whether true or not, this perception is certainly an
issue. To make progress here, maybe GNU Radio could take Ettus’ UHD dual-license
approach, if that is still possible? I don’t know if the FSF (the copyright
owner) would allow such a change; further, even with that change, I think a
separate company would need to be setup to deal with the non-GPL license. I think
having a less-restrictive license than the GPL would encourage adoption of GNU
Radio in places where IP is an issue. - MLD

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’m also less inclined to contribute to projects using BSD style
licenses since I see no benefit to me, to contribute to a project that
can be used for profit by people who do not plan to share the code with
their customers.

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.

Philip

[mdeering]

I completely concur with what you wrote below and what Scott J.
wrote some time ago.

USRP is an incredibly powerful platform and substantially low cost - I
am somewhat befuddled by how it has not attained greater prevalence but
at least some of the reasons are plainly obvious

• incomplete (or in some cases non-existent) documentation
• as a hardware engineer, my time is better spent in getting quickly to
  using the thing than to learn the nuances of Python
• it seems the vast majority of users today are software programmers,
  who may not be that averse to spending copious amounts of time on C++…

I also suspect that the folks at Ettus are somewhat stretched thin by
all the support work. Having said all that I will add that GRC is very
good (easy to learn) and can do most things that I need. It does have
stability issues, as I frequently get some error dialog or the other.

Best regards,
-Vijay
— On Mon, 5/9/11, Michael D. [email protected] wrote:

From: Michael D. [email protected]
Subject: Re: [Discuss-gnuradio] Why Isn’t GNU Radio Used More?
To: “GNURadio D.ion List” [email protected]
Date: Monday, May 9, 2011, 11:51 AM

On May 9, 2011, at 11:12 AM, 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.

True; that’s how I did (MATLAB; Simulink wasn’t around yet). I’d take
that a step further: I’d guess that 90+% of -potential- MATLAB /
Simulink / Octave / PyLab / LabVIEW / GNU Radio / GR Companion users
just want the system to work as provided, without having to implement
anything further beyond basic scripts – meaning, for GNU Radio, they
don’t want to have to delve into writing or deciphering C++ blocks, and
SWIG and XML glue necessary to use them in Python and GRC. I don’t know
if GRC provides this what those 90+% need just yet in terms of blocks;
good “help” files / system are a necessity, as pointed out by Scott.

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”.

I think that GNU Radio is pretty well represented in many areas & those
are growing pretty quickly right now. I don’t think GNU Radio will grow
in academia until it is more accessible and meets the needs to those
90+%.

I think to succeed in the way MATLAB did, GNU Radio needs to provide
functionality and documentation for those 90+%, without requiring them
to learn “anything GNU Radio” more than the GRC GUI. For many potential
users, writing C++ / Python / SWIG / XML is too daunting to even
consider – whether because of fear of the unknown, because they are not
well documented, or just because there are too many potential areas for
“difficult to debug” mistakes.

IMHO what GNU Radio needs is a stable API, internal code documentation,
help files for “how to use GNU Radio”, and then a well-written “how to
use GNU Radio” book that includes examples of using GRC. I think this
combination would bring GR/C to the masses – those 90+%. - MLD

[mdeering]

On 09/05/2011 12:39 PM, Vijay P. wrote:

• it seems the vast majority of users today are software programmers,
  who may not be that averse to spending copious amounts of time on C++…

I find this attitude a little strange–not meaning to offend or
anything. But this is, in fact software defined radio. So why is it
always a big surprise
when hardware types encounter an SDR platform and become
more-than-vaguely-queasy at the though of having to, perhaps, learn a
little bit
about software.

Just as not every piece of combinatorial logic that could ever be
conceived of hasn’t already been implemented in the (digital) hardware
world, so
to in the software world, not every conceivable functional block
having to do with folding/spindling/mutilating a digital sample stream
has yet
been created (and, by extension, the useful combinations of those
fundamental blocks). Which is why, well, those of us on either side of
the fence (hardware or software) have jobs.

Similarly, when a software-only guy encounters SDR, they become vaguely
offended that they might actually have to think about (shock!) hardware
issues, and real-time scheduling, and the vagaries of propagation.
In the software world, you can just “add another layer of abstraction”,
to make
your problems go away (or at least hide them under the covers
sufficiently well that they’re not so frightenting). But in a sense,
SDR in general,
and Gnu Radio in particular, are “perfect storms” for the
uninitiated. You really, honestly, do have to understand things on
both sides of
the fence. And there aren’t too many practitioners out there who
straddle the fence acceptably well at this point.

[mdeering]

Alexander-

Well said.

I would add an additional comment about “Linux as a model” for GNU
Radio. Linux exists at least in part because of
widespread developer anger with Microsoft in the 1990s. Guys like
Ballmer simply couldn’t think straight and failed
to respect developers’ time and effort. Linux solved that problem but
seems to have reached limits, such as desktop
applications. It’s less an economic model and more a model for global
cooperation and standardization in a
fundamental area of software too important to be left to short-term
oriented executives.

What I think might translate for GNU Radio is to find ways to support
more types of platforms. What about a small
USRP for smart phones and tablets? Would that draw in more developers?
A “platform broadening” might also make sense
from a revenue standpoint: small open source initiatives need revenue
streams to grow and be able to afford things
such as extensive documentation. For GNU Radio, this means hardware.

-Jeff

[mdeering]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me give my 2ct to this from the perspective of a new user :).

First of all, I’m no engineer. I’m a tech guy in the management in a
company which is active in security and defense fields. I have
reasonable experience in the radio fields and pretty solid experience in
IT/Linux fields.
I have a specific task to fulfill which brought me to GNURadio because I
try to find Open Source solutions for any tasks if possible.

Here we come to the first point…
If I wouldn’t be using Linux since 1996, I would be used to a certain
level of not-documentation and I wouldn’t know about mailinglists, etc.
If I wouldn’t have the focus on using OSS, I wouldn’t have the spirit to
bite through to get it to work. You can imagine the looks of my
(non-tech) colleagues I get every day when they see me fiddling with
GRC. Each and every one of them would have tried maybe for 10 minutes
and then went on to look for a commercial solution. So GNURadio wouldn’t
even have gotten compiled here.

So yes, documentation IS an issue. And also useability. I don’t say,
GNURadio must be turnkey but if already the compiling goes south because
we use Opensuse (which is pretty popular in Germany and Europe in
general), it’s an unnecessary obstacle.

Regarding Python, as I said, I am using Linux since 1996. I’m SuSE
Certified Linux Trainer (2001) and I really do A LOT with Linux.
Basically my whole home is handled by a Linux server, from mediaserver
over home-automation to the PBX and I have worked 10+ years in IT as
tech, trainer and consultant.
But I never ever got in touch with Python. I speak bash, PERL, PHP, C, a
little C++… Python always was “just another of these script language -
don’t need it, why should I learn it?” to me.

The little bit sad thing is, that GNURadio was a little bit more
turnkey-ish some time ago. Something around 2 or so years ago, when I
looked at it the first time, out of personal / hobby interest, there was
a SuSE RPM available and it worked out of the box. No compiling
problems, no trouble with the audio hardware, etc. And GRC is - at least
for me - intuitive enough to try first steps.

So, from my point of view, todos would be

1.) Make sure, everybody gets it running! The perfect solution would be
a binary RPM for every big distro, always uptodate and checked for
distro-specific issues, like sound, etc.

2.) Documentation, documentation, documentation. Preferably NOT in an
Internet Wiki - if I follow advice, the LAN port of my laptop is blocked
by the x-cable to the USRP2… In-app help is the key.

3.) Get rid of Python or at least enhance GRC that much that you need to
go into Python only in real hardcore cases. GRC is the way to go. Comeon

• • even software is developed visually nowadays without much
    hand-coding…

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 :).

---

(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk3IIzoACgkQbQKZlCdPOMOSbgCgkA6Z4KZOPi4uQLIouZvNogJP
HucAoJF+raFUVXT9nFYFm8yQTtZHQM2+
=l3zd
-----END PGP SIGNATURE-----

[mdeering]

On May 9, 2011, at 1:22 PM, Marcus D. Leech wrote:

this is, in fact software defined radio. So why is it always a big surprise
when hardware types encounter an SDR platform and become more-than-vaguely-queasy
at the though of having to, perhaps, learn a little bit about software.

If I got paid a dime for each time someone in a meeting made the comment
“Why is there so much hardware in -software- defined radio?” I’d be
wealthy!

I think your points about SDR being the “perfect storm” by requiring
both software and hardware knowledge is quite true – and, because of
this joint complexity, one reason why folks aren’t adopting it in
droves. As you say: there aren’t too many practitioners out there who
straddle the fence acceptably well at this point. I’m a software guy; I
can integrate software with hardware, but I don’t do hardware beyond
knowing specs and writing the software for integrating it. I have no
desire to be a hardware guy, though I know that understanding hardware
limitations is important for DSP and SDR in particular where “real time”
means something.

One cannot have every possible block available in GR/C; but, if enough
blocks are available to do 90+% of what common users need, then that’s
good enough for the GR/C release. And, then much like MATLAB / Octave,
there needs to be a way to install new blocks easily from an archive or
local compile – I really don’t know if that’s the case right now.

In my thinking, what blocks to include comes down to what end-users
actually -need- to do, versus what we engineer / developers think they
need to do; there is often a substantial gap between these areas. In
order to attract “the masses”, this gap needs to be reduced / closed. -
MLD

[mdeering]

On 09/05/2011 1:24 PM, Stefan Gofferje wrote:

try to find Open Source solutions for any tasks if possible.

So yes, documentation IS an issue. And also useability. I don’t say,
GNURadio must be turnkey but if already the compiling goes south because
we use Opensuse (which is pretty popular in Germany and Europe in
general), it’s an unnecessary obstacle.
I think you (tangentially) touched on an interesting point. Many users
come to Gnu Radio expecting it to be
“A turnkey application to solve my radio problems”. They don’t
really get that it’s a development platform
for developing SDR-based radio applications. They expect it to be
“the best HF SSB radio on the planet”,
or “a really funky satellite downlink radio”. Not perhaps really
having internalized that Gnu Radio is more
like a tray full of parts than a finished product. In precisely the
same way that the C compiler isn’t your
end application–it’s one of the tools you use to produce your end
application. There are some number of users
who arrive at Gnu Radio fully expecting that it’s a finished
application (and, more precisely, their finished application),
and then become discouraged when it is clearly more like the C
compiler than the local consumer electronics store.

Regarding Python, as I said, I am using Linux since 1996. I’m SuSE
Certified Linux Trainer (2001) and I really do A LOT with Linux.
Basically my whole home is handled by a Linux server, from mediaserver
over home-automation to the PBX and I have worked 10+ years in IT as
tech, trainer and consultant.
But I never ever got in touch with Python. I speak bash, PERL, PHP, C, a
little C++… Python always was “just another of these script language -
don’t need it, why should I learn it?” to me.
Python was a choice that was made a long time ago. I personally might
not have gone that way, but that was the choice.
In fact, I learned Python precisely because Gnu Radio used it for
“glue code”.

These days, much of the infrastructure that the Python code glues
together is fully accessible to C++ programs as well, so
you don’t have to learn Python.

a binary RPM for every big distro, always uptodate and checked for
distro-specific issues, like sound, etc.
The problem is that development is brisk enough that cutting
rpms/debs/whatevers every few days is
work. Unless someone steps up to do that work, it won’t get done.
Scripts like build-gnuradio
go some of the way to make it less painless to build from source.
Yes, it only supports Ubuntu and
Fedora, but I’m happy to accept patches for other distributions, like
your favourite OpenSUSE.

2.) Documentation, documentation, documentation. Preferably NOT in an
Internet Wiki - if I follow advice, the LAN port of my laptop is blocked
by the x-cable to the USRP2… In-app help is the key.
Yes, in-app help is a good idea. But the intention is that you have a
dedicated Ethernet port for your
USRP2. USB ethernet devices for the regular LAN side of your work
are quite cheap, and well-supported.

3.) Get rid of Python or at least enhance GRC that much that you need to
go into Python only in real hardcore cases. GRC is the way to go. Comeon

• • even software is developed visually nowadays without much hand-coding…

There’s essentially zero chance that Python is going to go away. I’d
also assert that it will never
be the case that there will be no circumstances under which you’ll
have to augment the functionality
that GRC encompasses. Yes, it needs more blocks–both existing ones
that haven’t been GRCed, and
new blocks that haven’t been invented yet. And perhaps there needs
to be more automation of how
those blocks show up in GRC. But there are no
graphical-programming tools that can fully-encompass
all the types of programming problems and algorithms one might want
to implement. In fact, the “connect the blocks”
paradigm is inherently limited in the classes of problems that can be
economically expressed under that paradigm.

There will always be cases in which you’ll need to augment what GRC is
capable of. There should perhaps be better mechanisms
for augmenting those capabilities, and better documentation for the
mechanisms that already exist–the XMLRPC stuff, for example,
is really quite powerful, but I fear I may be the only person using
it. Further, at least in a Linux environment, existing mechanisms
like FIFOs can be used fairly easily to do “stuff” outside of the
normal Gnu Radio pipeline that don’t nicely “fit” the connect-the-blocks
model. But documenting all of that will tend, necessarily, to wander
off into documenting existing Linux mechanisms, and that begs the
question “how much does a documentation effort wish to bite off”.

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 :).

The existing GPL licensing would make that difficult. But you can
isolate your own functionality behind existing IPC mechanisms, and thus
avoid
binding any of your code to the Gnu Radio libraries.

[mdeering]

On Mon, May 9, 2011 at 21:59, Marcus D. Leech [email protected] wrote:

On 09/05/2011 1:24 PM, Stefan Gofferje wrote:

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 :).

The existing GPL licensing would make that difficult. But you can isolate
your own functionality behind existing IPC mechanisms, and thus avoid
binding any of your code to the Gnu Radio libraries.

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

–
Regards,
Alexander C…

[mdeering]

On Mon, May 9, 2011 at 21:29, Jeff B. [email protected]
wrote:

What I think might translate for GNU Radio is to find ways to support more types
of platforms. What about a small
USRP for smart phones and tablets? Would that draw in more developers? A
“platform broadening” might also make sense
from a revenue standpoint: small open source initiatives need revenue streams
to grow and be able to afford things
such as extensive documentation. For GNU Radio, this means hardware.

I agree with that. I had an idea that a miniPCI SDR would be very
interesting solution, I discussed this with few people and they were
very interested indeed, but as a software guy I can’t develop it by
myself and I had not enough resources to make someone to build it. So,
if there are any cool hardware engineers out there, looking for a way
to contribute - lets design a small SDR board.

–
Regards,
Alexander C…

[mdeering]

On May 9, 2011, at 1:59 PM, Marcus D. Leech wrote:

I think you (tangentially) touched on an interesting point. Many users come to
Gnu Radio expecting it to be “A turnkey application to solve my radio problems”.
They don’t really get that it’s a development platform for developing
SDR-based radio applications.

Good point; one can go search through this list’s archive & find many
places where someone writes asking how to do some specific task, e.g.,
CR or DSA – as if expecting that GNU Radio already has a solution that
they can leverage. Clearly there is a perception out there that GNU
Radio -is- a generic solution, and then they don’t bother to RTFM to
figure out that it’s more like Octave & that they have to create their
application themselves. Better documentation would help, but it will
never solve this issue.

I’d also assert that it will never be the case that there will be no
circumstances under which you’ll have to augment the functionality that GRC
encompasses.

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.

the “connect the blocks” paradigm is inherently limited in the classes of
problems that can be economically expressed under that paradigm.

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).

you can isolate your own functionality behind existing IPC mechanisms, and thus
avoid
binding any of your code to the Gnu Radio libraries.

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

[mdeering]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 08:59 PM, Marcus D. Leech wrote:

I think you (tangentially) touched on an interesting point. Many users
come to Gnu Radio expecting it to be
“A turnkey application to solve my radio problems”. They don’t really
get that it’s a development platform
for developing SDR-based radio applications.

Well, at least I look at it kinda like an IDE. And of course I don’t
expect my final software solution to bit shipped with the IDE. But I
kinda expect the IDE to start up and let me work with it :).

Python was a choice that was made a long time ago. I personally might
not have gone that way, but that was the choice.
In fact, I learned Python precisely because Gnu Radio used it for
“glue code”.

Yeah, probably because you are one of those crazy
used-to-suffering-Linux-types :). Like me and others :). See my point?

These days, much of the infrastructure that the Python code glues
together is fully accessible to C++ programs as well, so
you don’t have to learn Python.

As I said, I’m no engineer, so somebody should maybe look at the
question if engineers learn C++ or rather some other stuff.
I remember vaguely that in school’s occupational orientation week some
25 years ago I touched some weird languages for some hardware stuff -
don’t remember details though.

About the rest…
Marcus, I’m rather happy with GNURadio now. I AM one of this
used-to-suffering-Linux-Types and now, as I found the beginning, I’m
gonna continue using it - not to a small part thanks to you and your
off-list help.

The original question was “why isn’t GNURadio used more?”
I was trying to give some input to this topic.

I think, the way the community addresses the issues that new users have,
will in the end decide if GNURadio gets more popular or not.
Do you say “We do it so because we always did it so”, “Well, it is as it
is, live with it” or “changes are too much work” or do you try to make
it happen?

I think, GNURadio doesn’t only have potential in academic fields. I find
GRC so easy and intuitive that I could very well imagine it to be some
educational tool. Combine it with a low-cost limited hardware and you
can have kids learn engineering and RF basics in a very convenient way.
It also has the potential to become a leader in the HAM-radio world. I
have seen some commercial HAM-radio SDRs and their software is usually
very nice and colorful but lacks a big deal of GNURadio’s flexibility.

You just have to make it a bit easier and a bit more convenient for all
those not used-to-suffering-Linux-types :).

Btw - as soon as I got reasonably deep into stuff, I’d be willing to
write a few docs or howtos as my time permits.

---

(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk3IMvsACgkQbQKZlCdPOMM7zACgn5lFhhy5OkoiTJ86QrICQbOa
AzwAnAomSHygKEnPMdORVriwASkOJB84
=C2Fw
-----END PGP SIGNATURE-----

[mdeering]

On Mon, May 9, 2011 at 11:21 AM, Alexander C.
[email protected] wrote:

if there are any cool hardware engineers out there, looking for a way

One of big reasons I think that people struggle with GNURadio is that
is jams so many different fields of expertise into one package.

1. Digital Comms people (aka the Maths people) cannot program
   themselves out of a wet paper bag, for the most part. This is what I
   have seen in industry and academia.

2. Software people get lost in all the digital comm and signal
   processing lingo. While they can program, they really don’t understand
   what each block actually does.

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

[mdeering]

On Mon, May 9, 2011 at 22:25, Michael D. [email protected] wrote:

On May 9, 2011, at 1:59 PM, Marcus D. Leech wrote:

you can isolate your own functionality behind existing IPC mechanisms, and thus
avoid
binding any of your code to the Gnu Radio libraries.

Well, that this IPC should be very well integrated into GnuRadio, well
documented and made easy to use, especially for those who never used
GnuRadio before.

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

Dual-licensing is a flawed model, it’s truly hard to make it working
right. I believe that something like LGPL would be sufficient.

–
Regards,
Alexander C…

[mdeering]

Could it also be because GNU Radio has always treated the Windows
platform
as a second-class citizen?

I have tried installing GNU Radio on all three major OSes, Linux (RHEL,
Ubuntu), OS X (10.5, 10.6) and Windows (XP, using Cygwin), and I never
managed to get it running on Windows. On the other hand, it’s been ~5
years
since I tried and gave up, so things may have changed. Getting it
running on
OS X and Linux was (relatively) easy.

Windows is the most widespread desktop/laptop OS, and having to switch
to
Linux, or needing a separate machine, for GNU Radio development could be
significant barrier to adoption.

It may be helpful to look at what people do use instead of GNU Radio,
and
see how they differ.

Kunal