"GNU Radio is crap" and GSoc

GNU Radio
21

Andrew,

Am 15.02.2012 19:41, schrieb Andrew D.:

Well some major GNUradio program would drive up sales of USRP’s :slight_smile:

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.
:slight_smile:

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

I don’t agree. We’ll hopefully settle the matter some day. :slight_smile:

Jens

22

I don’t agree. We’ll hopefully settle the matter some day. :slight_smile:

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.

23

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

24

I believe the gr event scheduler, presented at the last gr conference,
is
for just that kind of thing.

Tim

25

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 ).