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

[Michael Dickens]

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