Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?

[Marcus D. Leech]

On 09/05/2011 1:24 PM, Stefan Gofferje wrote:
> -----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.
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.


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