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