I also agree that a big issue with gnuradio is that it tries to take over all the computing resources in an application but in my opinion that this is not an inherent issue with the gnuradio scheduler not wanting to play with other applications. Some people complain that gnuradio doesn't provide an API with functions that can be called to a process data in their external applications, I haven't tried this per se, but isn't that the purpose behind gnuradio supports running c++-only apps? But people need to be careful what they ask for, if they get only an API to call basic gnuradio functionality to process data they want to be processed the overall performance might not be acceptable because they are ultimately giving up the scheduler. Processing is done in gnuradio the way they are, at least in my opinion, to address the issue of running a Synchronous Dataflow (SDF) graphs which is exactly what you want for signal processing, and an integral part of running SDF graphs is running a suitable scheduler.
What gnuradio lacks is coherent links to the scheduler in my experience it is fairly difficult to step through the code with gdb to figure out what the scheduler is doing, if users are able to have some control over the scheduler or replace it entirely for custom applications where gnuradio needs to work in cohesion with other apps then gnuradio can run as part of a larger system versus being the only system running. While this might be outside the scope of a GSoC project but it's a necessity for gnuradio to progress beyond its current state. Almohanad (Al) Fayez -----Original Message----- From: Andrew Davis <glneolistm...@gmail.com> To: Jens Elsner <jpels...@1c3.de>; discuss-gnuradio <discuss-gnuradio@gnu.org> Sent: Thu, Feb 16, 2012 9:03 am Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc >I don't agree. We'll hopefully settle the matter some day. :-) Me too, DREAM is an amazing SDR program that could benefit from NURadio and show off GNURadio as-well. But this idea has been batted round before and never really develops, possibly due to the way NURadio is currently setup. When I get some free time i'll continue etting some of the python examples ported to C++, so that potential evelopers who prefer C over python can see how things can be done rom C world. I think this will get people who find GNURadio to start orting other C based programs to the GNURadio framework. On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner <jpels...@1c3.de> wrote: Andrew, Am 15.02.2012 19:41, schrieb 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 could elaborate on this point - why should GNU Radio not implement channel equalization (I assume that's what you mean?) or digital AGC? > If you want > to re-write DREAM with GNUradio you will end up writing about +200 > blocks, not much fun. Since I suggested this particular project, I obviously cannot agree. :-) Pulling the code base into GNU Radio might be a nice addition to the available receivers and it can be useful for all amateur radio operators world wide. Plus DRM is broadcasting so we don't need to worry about timing issues, a real drawback of GNU Radio (and high level SDR in general). How fine the signal processing chain needs to be chopped up is a matter of taste and performance, I believe. > 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? I am not sure I understand your point here. That is not GNU Radio, I see GNU Radio as a scheduler with a big collection of signal processing blocks attached. [...] > 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 Then it would be nice to find out what exactly is lacking to add this to GNU Radio. > 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> I don't agree. We'll hopefully settle the matter some day. :-) Jens _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ iscuss-gnuradio mailing list iscuss-gnura...@gnu.org ttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
