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 <b...@ettus.com> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
