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

[Andrew Davis]

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