Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

[Andrew Davis]

Well some major GNUradio program would drive up sales of USRP's :)

Back on topic, IMHO Gnuradio's problem with large apps stems from it
trying to be the source to sink and everything in between of a radio.
Lets take DREAM for example, they do transfer functions and digital
AGC and the likes that GNUradio by design should not do. If you want
to re-write DREAM with GNUradio you will end up writing about +200
blocks, not much fun. What people want is simple input to there
program and a simple output API, not there entire program. They don't
what to figure out how to write a GNURadio block or know anything
about the complexities of GNURadio. They want to say "get me a signal
at 100MHz, filter and interpolate to 1ksp with these cutoff
frequencies then send me the data and let me do the rest", no need to
know anything about GNURadio, what other API makes you learn as much
about it?

And Gnuradio can do that, with its C++ API, but not with python,
python is great for demos like "source->AM demod->sink", and that's
also great for academic projects too, but simply not enough DSP
control for real programs. In the web scanner program at the top of
this thread, in the developers complimentary they write: " I was
originally using some demo code written in Python as my base, but I
got tired of dealing with the foibles of that code and rewrote it in
C++ one night last summer. " Isn't it strange that one of the big
examples does exactly this.

spectrum_sense.py is another great example, the block bin_statistics_f
has only one use and that it for the program spectrum_sense, so if
spectrum_sence was writen in C++ it would have just benn part of the
program and not its own block, but insted it calls python and vise
versa in an amazingly hackish way.

 If real programs are going to be made there needs to be a better way
to use GNUradio as an API and not an entire SDK. Just get the samples
out-of GNURadio and into the programs hands, then back into GNURadio
in the end for final filtering and output, possibly some work using
GNURadio functions in the middle is all that is needed. Back to DREAM,
a lot of the filters, audio input/output, signal conditioning, etc
could be in GNURadio, but a lot of the middle section cannot. GNURadio
can not be the whole program, just helper functions in big programs
like this. Only about %20 of DREAM could be replaced with GNURadio API
calls, but instead you will have to rewrite it %100 as GNURadio blocks
with the current block to block only mentality </rant>

On Wed, Feb 15, 2012 at 12:49 PM, Ben Hilburn <address@hidden> wrote:
>
> Jeff -
>
>>
>> All understood.  Demos that highlight GNU Radio's tremendous progress are 
>> crucial to its long-term success.  But
>> nevertheless Clark makes a crucial point.  GNU Radio is owned by National 
>> Instruments and I might guess their sales
>> guys are not too happy with this thread.
>
>
> Erm, what?
>
> This reflects a really severe misunderstanding of GNU Radio.
>
> GNU Radio is _not_ owned by NI, in any way.  GNU Radio is owned by the Free 
> Software Foundation, and has nothing to do with NI.
>
> Ettus Research, the creator of USRP hardware, is owned by NI.  But, USRPs are 
> _not_ GNU Radio.  You are confusing a free software project with a company 
> that makes hardware.  USRPs can be used with LabView, Simulink, GNU Radio, or 
> without any SDR framework at all; they are just general-purpose hardware with 
> a C++ / Python API.
>
>>
>> They can't sell "cool demos".  Progress must be made to create
>> revenue-producing applications.  Like Clark says, most of that work is not 
>> fun, and it eats a lot of time and effort,
>> but in the real business world, there isn't a choice.
>
>
> > Ok.  I should have said "is owned by" with "substantially depends on"...
>
> NI has no control over the direction of GNU Radio.  Ettus Research supports 
> GNU Radio, but we do not control it in any way.  GNU Radio's progress is 
> controlled by Tom Rondeau, and its developers and users; hence, the existence 
> of threads like this for the community to discuss ideas.
>
> Cheers,
> Ben
>
>
>>
>> -Jeff
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>