I believe the gr event scheduler, presented at the last gr conference, is for just that kind of thing.
Tim On Feb 17, 2012 7:39 PM, "Andrew Davis" <[email protected]> wrote: > Yes, I could feed the blocks work functions directly, but this is > tricky sometimes. I'm working on a simple program that needs to route > data from different sources to changing functions and blocks and then > to multiple sinks. The current scheduler is just to static in flow for > this task ( I believe, tell me if i'm wrong ). > > On Fri, Feb 17, 2012 at 7:17 PM, Almohanad Fayez <[email protected]> wrote: > > 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 <[email protected]> > > To: Jens Elsner <[email protected]>; discuss-gnuradio > > <[email protected]> > > 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 > > GNURadio and show off GNURadio as-well. But this idea has been batted > > around before and never really develops, possibly due to the way > > GNURadio is currently setup. When I get some free time i'll continue > > getting some of the python examples ported to C++, so that potential > > developers who prefer C over python can see how things can be done > > from C world. I think this will get people who find GNURadio to start > > porting other C based programs to the GNURadio framework. > > > > On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner <[email protected]> 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 > >> [email protected] > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
