"GNU Radio is crap" and GSoc

Hi,

for those who haven’t yet read Tom’s recent blog post, I recommend
it–in a sentence, the lack of applications is hurting GNU Radio, and I
couldn’t agree more.

One way to remedy this might be GSoC. Developing a nice application,
paid by Google… doesn’t that sound like the perfect thing to do this
summer?

So, if you’re a student, consider joining the forces for GSoC. If you’re
a student advisor of some kind, kick[1] your students to make them join
GSoC.

Have a look here http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC
to find out more. Surprise, surprise–the most project ideas so far are
stand-alone applications.

Martin

[1] In a caring, supportive way, that is.

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Feb 14, 2012, at 12:59 AM, Martin B. wrote:

for those who haven’t yet read Tom’s recent blog post, I recommend
it–in a sentence, the lack of applications is hurting GNU Radio, and I
couldn’t agree more.

How about a whole web application which would not exist without GNU
Radio?

http://scanner.rachelbythebay.com/

That’s been running more-or-less continuously since July.

Without a monetization strategy I don’t see how the gnu radio project
gets much past its current state. The problem is the functionality of a
prototyper or student is implemented in about 20% of the effort for a
full application. The documentation, testing, deployment, and
maintenance of a real application needs a lot more work and that work is
not educational or enjoyable. So without something like an app store
where developers can get reimbursed for that other 80% the applications
will stay stuck at the cool demo stage.

-Clark

I really think that projects like the ones in CGRAN have great value.

The key point in my option is to implement some widely used standards
using the gnuradio framework.
As examples I’d say TV broadcast standards like DVB, ISDB-Tb, radio
standards like DAB, DRM, …, this will greatly improve Gnuradio
adoption
and use, by universities, hobbists and companies.

I don’t think money is the only issue involved, but of course it would
help.
An university involvement approach like the VT one is also very
interesting.

Best regards,
Rafael D.

Tom makes the point that Gnu Radio isn’t “shiny”. Indeed, it isn’t.

Some people arrive at Gnu Radio expecting that it is an “end
application”, and walk away badly disappointed. They have in their mind
a firm notion of what constitutes a “radio”, and fully expect that Gnu
Radio is that “radio”, except that it has GUI widgets instead physical
controls. For this class of “customer” for Gnu Radio, I blame the early
ham-radio SDR market, and the suppliers thereto. They packaged their SDR
hardware with fully-built applications, and in some cases, didn’t expose
the underlying API in any meaningful sense, so people come to Gnu Radio
expecting it to simply be an Open Source version of an existing SDR
application in the amateur-radio/scanner space.

The problem is that
the field of “radio” is incredibly diverse, so much so that from my
perspective I can’t imagine a single class of application that would be
“the one that everyone is looking for”. Sure, there has been an emphasis
on SDR in academic environments for use in commercial
networking/telecoms applications, but really, that’s rather the tip of
the iceberg when it comes to potential applications for SDR (and by
implication, Gnu Radio).

Clark P. observed that building end-user
applications is a lot of work. I completely agree. End-user
applications have to be polished, reliable, easy-to-use, and fully
documented. Even something as relatively simple as SIDSuite, which is up
on CGRAN, requires a lot of work to make it “friendly” to an
“appliance” user. I just can’t see our core developer team spending
their time in that part of the space. But if their job is done
correctly, the applications will (and have!) emerge.

Much application
development for Gnu Radio is going on in the background, on private
projects that will never be published. So it’s easy for people to get
the impression that Gnu Radio has no apps. That’s just plain not true.

On Tue, 14 Feb 2012 06:21:18 -0800, Rafael D. wrote:

I really
think that projects like the ones in CGRAN have great value.

The
key point in my option is to implement some widely used standards

using the gnuradio framework.

As examples I’d say TV broadcast
standards like DVB, ISDB-Tb, radio
standards like DAB, DRM, …, this
will greatly improve Gnuradio adoption
and use, by universities,
hobbists and companies.

I don’t think money is the only issue
involved, but of course it would help.
An university involvement
approach like the VT one is also very interesting.

Best regards,

Rafael D.

Without a monetization strategy I don’t see how the
gnu radio project gets much past its current state. The problem is the
functionality of a prototyper or student is implemented in about 20% of
the effort for a full application. The documentation, testing,
deployment, and maintenance of a real application needs a lot more work
and that work is not educational or enjoyable. So without something like
an app store where developers can get reimbursed for that other 80% the
applications will stay stuck at the cool demo stage.

_______________________________________________ Discuss-gnuradio mailing
list [email protected] [1]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]

Links:

On Tue, Feb 14, 2012 at 09:59:45AM +0100, Martin B. wrote:

One way to remedy this might be GSoC. Developing a nice application,

I’m a little surprised by this discussion. I think GNU Radio is
positively amazing for prototyping, testing, and academic
purposes. I can’t imagine making finished applications with it
though. Is that really what it’s supposed to be for?

Seems like distribution alone would be a problem. You’d have to
get your python and boost libraries exactly right just to have a
chance.

Perhaps I’m crazy.

-Paul


If riding in an airplane is flying, then riding in a boat is swimming.
116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.

On Tue, Feb 14, 2012 at 11:26 AM, [email protected] wrote:

Tom makes the point that Gnu Radio isn’t “shiny”. Indeed, it isn’t.

Some people arrive at Gnu Radio expecting that it is an “end application”,
and walk away badly disappointed. They have in their mind a firm notion of
what constitutes a “radio”, and fully expect that Gnu Radio is that
“radio”, except that it has GUI widgets instead physical controls. For this
class of “customer” for Gnu Radio, I blame the early ham-radio SDR market,
and the suppliers thereto. They packaged their SDR hardware with

And at the same time they’re doing an incredible disservice to the
SDK-universe
by not enabling the kind of DSP experimentation that SDR can enable!
GNURadio does a reasonable job of enabling that stuff— or at least I
found it pretty easy to build my own radio toys and get on the air.
Much easier than assembling an analog radio from components at least.

Though I think that there is a gap here: People hesitate to buy the
hardware needed to support gnuradio because they aren’t sure that
they’ll get around to the some-assembly-required part. It would be
nice if there were a few end user applications so that people would be
comfortable that they wouldn’t just end up with more junk they’ll
never get around to using… and to also serve as starting boards for
development: If your grand idea is an automatic GPS linked repeater
directory for ham radio, it kinda sucks that to build that idea with
GNU radio you first have to build the a whole frequency-duplexing
radio.

… but the solution to that gap isn’t to complain about it, — it’s to
write the software. If no one wants to do that, all the complaining in
the world won’t help.

The “you’d have to get all the dependencies right” is no different
than any other advanced application out there.

Things like “gimp” and
“blender” and a whole whack of others these days have a huge dependency
tree. Gnu Radio is no different.

I have software that I sell that uses
a little bit of Gnu Radio underneath the GUI. Not a huge deal, but it
does require that you do a Gnu Radio install.

On Tue, 14 Feb 2012
14:53:36 -0500, Paul Miller wrote:

On Tue, Feb 14, 2012 at
09:59:45AM +0100, Martin B. wrote:

One way to remedy this might be
GSoC. Developing a nice application,
I’m a little surprised by this
discussion. I think GNU Radio is positively amazing for prototyping,
testing, and academic purposes. I can’t imagine making finished
applications with it though. Is that really what it’s supposed to be
for?
Seems like distribution alone would be a problem. You’d have to
get your python and boost libraries exactly right just to have a chance.
Perhaps I’m crazy. -Paul

On Tue, Feb 14, 2012 at 2:53 PM, Paul Miller
[email protected]wrote:

chance.

Perhaps I’m crazy.

-Paul

I think Marcus’ response already covers this, so I won’t spend much time
here. I think what you are reacting to has more to do with our lack of
real
integration with the standard installation procedures for the civilized
Linux distros out there (apt-get and yum in particular). But, again,
using
any civilized distro, all of our package requirements are well supported
and have been for years.

Tom

On Tue, Feb 14, 2012 at 11:26 AM, [email protected] wrote:

**

Tom makes the point that Gnu Radio isn’t “shiny”. Indeed, it isn’t.

“Everything’s shiny, Cap’n. Not to fret”

That was just a little something for the Firefly fans in the audience.

Good perspectives, everyone, thanks!

Some people arrive at Gnu Radio expecting that it is an “end
application”,

The problem is that the field of “radio” is incredibly diverse, so much so
that from my perspective I can’t imagine a single class of application that
would be “the one that everyone is looking for”. Sure, there has been an
emphasis on SDR in academic environments for use in commercial
networking/telecoms applications, but really, that’s rather the tip of the
iceberg when it comes to potential applications for SDR (and by
implication, Gnu Radio).

I agree, definitely. I think that there’s so much interesting
capabilities
out there for SDR that we’re only just getting in to now. I’m often
asked
about doing standards in GNU Radio, but to me, that’s really
uninteresting.
It has it’s role, sure, but once you have a standard defined, you can
build
a chip to handle it. GNU Radio is much to general, flexible, and dynamic
for a standard. We want to see new ideas and classes of applications
enabled because of this technology. I really don’t want to go chasing
the
standards train because by definition, we’re always going to be lagging.

Clark P. observed that building end-user applications is a lot of
work
. I completely agree. End-user applications have to be polished,
reliable, easy-to-use, and fully documented. Even something as relatively
simple as SIDSuite, which is up on CGRAN, requires a lot of work to make
it “friendly” to an “appliance” user. I just can’t see our core developer
team spending their time in that part of the space. But if their job is
done correctly, the applications will (and have!) emerge.

No, we’re not interested in that level of involvement, and I understand
why
there is varying levels of friendliness and/or bitrot occurring in some
of
the CGRAN projects when you don’t have someone who’s motivated in
keeping
it up to date. Many of the projects out there were student projects and
those students then went and got jobs that are paying them to do other
things. And I’m incredibly grateful to those people who took the time to
publish there work at all, lest anyone think that I’m critical of the
contributions made!

On the other hand, there are definite rewards that come from open source
development, many of which are monetary. There are an increasing number
of
jobs out there that are requesting GNU Radio experience. When you can
point
to your published code for your resume, that could be pretty convincing.

I won’t get into all of the ways that open source works as a model, even
for complex programs. I’ll just point to Linux, GCC, Apache, and Python.
There are a variety of reasons people contribute to those projects,
sames
as GNU Radio.

Much application development for Gnu Radio is going on in the
background,

on private projects that will never be published. So it’s easy for people
to get the impression that Gnu Radio has no apps. That’s just plain not
true.

And that’s a really good point. There’s lots of work that’s been done
out
there. My specific issue was that there’s not necessarily a lot
“out-of-the-box” that people can point to and get working. A lot of the
high-quality apps that exist are not distributed (and as far as I’ve
seen,
no one is breaking the GPL with what they are doing), so that model
doesn’t
help with the general outside perception that I was discussing in my
post.

Tom

On Tue, Feb 14, 2012 at 04:13:30PM -0500, Tom R. wrote:

“Everything’s shiny, Cap’n. Not to fret”

That was just a little something for the Firefly fans in the audience.

You’ve just received +10 geek cred plus a personal “favourite OSS
project leader of the month” award from myself :slight_smile:

Since I actually started this thread (sheesh, I’m such a buzzkill
somethimes) to motivate people to have a look at the GSoC page, I’d
like to throw out a couple of points:

  • An ‘application’ does not have to be a perfect, end-user friendly
    product. It can be anything as simple as a grc file that lives in
    gnuradio-examples. If it just outputs stuff on the command line that’s
    OK for me (if it does something cool).
  • Also, there’s no obligation to maintain an application until the end
    of days. If there’s a cool demo available, adding some ‘evidence’ to
    the project page (and this could simply be a page on CGRAN), such as
    pictures, or perhaps a Youtube video, is already enough to make GNU
    Radio
    look better as a backend.

So, don’t be discouraged!

MB

development, many of which are monetary. There are an increasing number of jobs
on private projects that will never be published. So it’s easy for people
to get the impression that Gnu Radio has no apps. That’s just plain not
true.

And that’s a really good point. There’s lots of work that’s been done out
there. My specific issue was that there’s not necessarily a lot
“out-of-the-box” that people can point to and get working. A lot of the
high-quality apps that exist are not distributed (and as far as I’ve seen, no
one is breaking the GPL with what they are doing), so that model doesn’t help
with the general outside perception that I was discussing in my post.


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Tue, Feb 14, 2012 at 09:11:19AM -0500, Clark P. wrote:

Without a monetization strategy I don’t see how the gnu radio project gets much
past its current state. The problem is the functionality of a prototyper or
student is implemented in about 20% of the effort for a full application. The
documentation, testing, deployment, and maintenance of a real application needs a
lot more work and that work is not educational or enjoyable. So without something
like an app store where developers can get reimbursed for that other 80% the
applications will stay stuck at the cool demo stage.

First, “cool demo stage” is already a pretty good stage.
Second, I’d like to point out a very successful OSS project not unlike
GNU Radio & the USRP: the Arduino.
By itself, it’s useless–it’s a hardware/software development tool.
Sounds familiar?
If you read sites like hackaday.com, the Arduino comes up all the
time
with posts like “Look what X did with an Arduino”. On this
specific site, GNU Radio comes up 3 times, the newest article being from
February 2009.

Some coverage of cool hacks using GNU Radio certainly wouldn’t hurt the
project.

MB

PS: Anyone who gets a GNU Radio related post on hackaday get invited to
dinner by me, redeemable at the pre-WSR meeting.


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

A bit late on this conversation… I just noticed it after I posted an
update for CGRAN.

GNU Radio has been largely successful in the academic community, because
it
provides us the flexibility to perform the style of research we need.
Ultimately though, the limitations of the framework that were put in
place
to achieve this flexibility, I believe hurt the ability of GNU Radio to
support more high-end applications. I’m not talking about the lack of
someone coming around to do it, I’m talking about the lack of GNU Radio
and
USRP to support many of the current wireless standards today. This is
going to be slightly biased in my area of research… but, what would be
a
great app? Show interoperability of GNU Radio and 802.11, ZigBee, DECT,
RFID (thanks Michael), NFC, Bluetooth, etc.

To me, pushing GNU Radio to the next level has never been about building
the next set of applications on what is currently supported, but really
pushing the platform to the next level. Being able to support low
latency
applications, support wide ranges of MAC protocols, different PHYs.
This
opens up the ability to build so much more and new on GNU Radio.

I can’t express how many times I’ve gotten personal e-mails about my MAC
work and about projects on GNU Radio of people wanting to do some pretty
cool things and I’m just like… “well, the architecture just doesn’t
support that.” For example, meta-data between blocks IMO was something
brain-dead that should have been in GNU Radio 7 years ago which would
have
really enabled new things to be done with the framework. Instead, it
took
7 years for stream tags :wink: This is functionality that pushes the frame
and
the architecture, that is the kind of stuff that I think will push the
platform.

So to me, it’s not about having the next demodulation block, it’s about
what is going to happen to the architecture and the framework to support
an
802.11, a ZigBee, DECT, RFID, NFC, Bluetooth, Xbox controller… things
that people want to play with and showcase the capabilities of the
radio.

I think what “we” should be doing is taking what is “hot” in the radio
world, and asking whether or not it can be supported by GNU Radio and
the
USRP. I really think that GNU Radio needs to get passed its major
application being simple streaming or demodulation and really push
packet
radio. Two way low latency communication. Networks, I suppose.

To me, I go “well, in 6 years GNU Radio really hasn’t changed” … has
it?
Yeah, block details, new blocks, the amount of bandwidth from the USRP,
but like, what has fundamentally pushed the limitations of the system?

Just my 10 cents! I am unbelievably grateful for GNU Radio and the
USRP.
They truly transformed my view of the RF world, the radio, and have
given
me invaluable experience that I would have never gotten on any other
platform. The community itself is great, and I’ve been happy to be a
part
of it (in and out) for the past 6 years. That’s the reassuring part
that
I’m on your side, these are just my thoughts on where I wish GNU Radio &
USRP would go :slight_smile:

Martin-

By itself, it’s useless–it’s a hardware/software development tool.
Sounds familiar?
If you read sites like hackaday.com, the Arduino comes up all the
time
with posts like “Look what X did with an Arduino”. On this
specific site, GNU Radio comes up 3 times, the newest article being from
February 2009.

Some coverage of cool hacks using GNU Radio certainly wouldn’t hurt the
project.

All understood. Demos that highlight GNU Radio’s tremendous progress
are crucial to its long-term success. But
nevertheless Clark makes a crucial point. GNU Radio is owned by
National Instruments and I might guess their sales
guys are not too happy with this thread. They can’t sell “cool demos”.
Progress must be made to create
revenue-producing applications. Like Clark says, most of that work is
not fun, and it eats a lot of time and effort,
but in the real business world, there isn’t a choice.

-Jeff

On 2/15/12 11:31 AM, Jeff B. wrote:

… GNU Radio is owned by National Instruments …

!!!

You are confusing GnuRadio with Ettus R…

GnuRadio is an open source SDR framework.

Ettus is the manufacturer of the USRP series of hardware
and the UHD driver libraries to access it.

@(^.^)@ Ed

Jeff -

All understood. Demos that highlight GNU Radio’s tremendous progress are
crucial to its long-term success. But
nevertheless Clark makes a crucial point. GNU Radio is owned by National
Instruments and I might guess their sales
guys are not too happy with this thread.

Erm, what?

This reflects a really severe misunderstanding of GNU Radio.

GNU Radio is not owned by NI, in any way. GNU Radio is owned by the
Free
Software Foundation, and has nothing to do with NI.

Ettus R., the creator of USRP hardware, is owned by NI. But,
USRPs
are not GNU Radio. You are confusing a free software project with a
company that makes hardware. USRPs can be used with LabView, Simulink,
GNU
Radio, or without any SDR framework at all; they are just
general-purpose
hardware with a C++ / Python API.

They can’t sell “cool demos”. Progress must be made to create
revenue-producing applications. Like Clark says, most of that work is not
fun, and it eats a lot of time and effort,
but in the real business world, there isn’t a choice.

Ok. I should have said “is owned by” with “substantially depends on”…

NI has no control over the direction of GNU Radio. Ettus R.
supports
GNU Radio, but we do not control it in any way. GNU Radio’s progress is
controlled by Tom R., and its developers and users; hence, the
existence of threads like this for the community to discuss ideas.

Cheers,
Ben

Ed-

and the UHD driver libraries to access it.
Ok. I should have said “is owned by” with “substantially depends on”…

-Jeff

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 inbetweenof 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 want
to re-write DREAM with GNUradio you will end up writing about +200
blocks, not much fun. What people want is simple input to there
program and a simple output API, not there entire program. Theydon’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 andinterpolate to 1kspwith these cutoff
frequenciesthen 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?

And Gnuradio can do that, with its C++ API, but not with python,
python is great for demos like “source->AM demod->sink”, andthat’s
also great foracademicprojects too, but simply not enough DSP
control for real programs. In the web scanner program at the top of
this thread, in the developerscomplimentarythey write: " I was
originally using some demo code written in Python as my base, but I
got tired of dealing with the foibles of that code and rewrote it in
C++ one night last summer." Isn’t it strange that one of the big
examples does exactly this.

spectrum_sense.py is another great example, the blockbin_statistics_f
has only one use and that it for the program spectrum_sense, so if
spectrum_sence was writen in C++ it would have just benn part of the
program and not its own block, but insted it calls python and vise
versa in an amazingly hackish way.

If real programs are going to be made there needs to be a better way
to use GNUradio as an API and not an entire SDK. Just get the samples
out-ofGNURadio and into the programs hands, then back into GNURadio
in the end for final filtering and output,possiblysome work using
GNURadio functions in the middle is all that is needed. 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
can not be the whole program, just helperfunctionsin 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

On Wed, Feb 15, 2012 at 11:52 AM, George N. [email protected]
wrote:

going to be slightly biased in my area of research… but, what would be a
work and about projects on GNU Radio of people wanting to do some pretty
802.11, a ZigBee, DECT, RFID, NFC, Bluetooth, Xbox controller… things
but like, what has fundamentally pushed the limitations of the system?

Just my 10 cents! I am unbelievably grateful for GNU Radio and the USRP.
They truly transformed my view of the RF world, the radio, and have given
me invaluable experience that I would have never gotten on any other
platform. The community itself is great, and I’ve been happy to be a part
of it (in and out) for the past 6 years. That’s the reassuring part that
I’m on your side, these are just my thoughts on where I wish GNU Radio &
USRP would go :slight_smile:

Those are fair points, George, but just keep an eye on what’s been
happening lately. Yep, we’ve introduced stream tags, I just included
more
control over latency between GR blocks, and we’re about to merge in
support
for Volk to drastically increase the compute power of the system. And
take
a look at the presentations from the last GNU Radio conference,
specifically the event scheduler. All of this is pushing in the
direction
of supporting packet communications.

Also, keep in mind that without input from users, developers, and
would-be
users, we develop either in the black-box of our own wants and desires.
We
respond to those who comes to us with ideas for what’s really needed.

Tom

On 02/15/2012 09:41 AM, Jeff B. wrote:

Ettus is the manufacturer of the USRP series of hardware
and the UHD driver libraries to access it.

Ok. I should have said “is owned by” with “substantially depends on”…

Or Ettus found that hiring people active in the GNU Radio community is a
way to recruit excellent SDR people.

There is a similar situation in the Linux kernel space, the number of
independent kernel developers is dropping slowly with time, because
people that show an ability to contribute code to the kernel are prized
by employers.

Philip

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs