>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