On 09/05/2011 1:24 PM, Stefan Gofferje wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let me give my 2ct to this from the perspective of a new user :).
First of all, I'm no engineer. I'm a tech guy in the management in a
company which is active in security and defense fields. I have
reasonable experience in the radio fields and pretty solid experience in
IT/Linux fields.
I have a specific task to fulfill which brought me to GNURadio because I
try to find Open Source solutions for any tasks if possible.
Here we come to the first point...
If I wouldn't be using Linux since 1996, I would be used to a certain
level of not-documentation and I wouldn't know about mailinglists, etc.
If I wouldn't have the focus on using OSS, I wouldn't have the spirit to
bite through to get it to work. You can imagine the looks of my
(non-tech) colleagues I get every day when they see me fiddling with
GRC. Each and every one of them would have tried maybe for 10 minutes
and then went on to look for a commercial solution. So GNURadio wouldn't
even have gotten compiled here.
So yes, documentation IS an issue. And also useability. I don't say,
GNURadio must be turnkey but if already the compiling goes south because
we use Opensuse (which is pretty popular in Germany and Europe in
general), it's an unnecessary obstacle.
I think you (tangentially) touched on an interesting point. Many users
come to Gnu Radio expecting it to be
"A turnkey application to solve my radio problems". They don't
really get that it's a *development* platform
for *developing* SDR-based radio applications. They expect it to be
"the best HF SSB radio on the planet",
or "a really funky satellite downlink radio". Not perhaps really
having internalized that Gnu Radio is more
like a tray full of parts than a finished product. In precisely the
same way that the C compiler isn't your
end application--it's one of the tools you use to produce your end
application. There are some number of users
who arrive at Gnu Radio fully expecting that it's a finished
application (and, more precisely, *their* finished application),
and then become discouraged when it is clearly more like the C
compiler than the local consumer electronics store.
Regarding Python, as I said, I am using Linux since 1996. I'm SuSE
Certified Linux Trainer (2001) and I really do A LOT with Linux.
Basically my whole home is handled by a Linux server, from mediaserver
over home-automation to the PBX and I have worked 10+ years in IT as
tech, trainer and consultant.
But I never ever got in touch with Python. I speak bash, PERL, PHP, C, a
little C++... Python always was "just another of these script language -
don't need it, why should I learn it?" to me.
Python was a choice that was made a long time ago. I personally might
not have gone that way, but that was the choice.
In fact, I learned Python *precisely because* Gnu Radio used it for
"glue code".
These days, much of the infrastructure that the Python code glues
together is fully accessible to C++ programs as well, so
you don't have to learn Python.
The little bit sad thing is, that GNURadio was a little bit more
turnkey-ish some time ago. Something around 2 or so years ago, when I
looked at it the first time, out of personal / hobby interest, there was
a SuSE RPM available and it worked out of the box. No compiling
problems, no trouble with the audio hardware, etc. And GRC is - at least
for me - intuitive enough to try first steps.
So, from my point of view, todos would be
1.) Make sure, everybody gets it running! The perfect solution would be
a binary RPM for every big distro, always uptodate and checked for
distro-specific issues, like sound, etc.
The problem is that development is brisk enough that cutting
rpms/debs/whatevers every few days is
*work*. Unless someone steps up to do that work, it won't get done.
Scripts like build-gnuradio
go some of the way to make it less painless to build from source.
Yes, it only supports Ubuntu and
Fedora, but I'm happy to accept patches for other distributions, like
your favourite OpenSUSE.
2.) Documentation, documentation, documentation. Preferably NOT in an
Internet Wiki - if I follow advice, the LAN port of my laptop is blocked
by the x-cable to the USRP2... In-app help is the key.
Yes, in-app help is a good idea. But the *intention* is that you have a
dedicated Ethernet port for your
USRP2. USB ethernet devices for the regular LAN side of your work
are quite cheap, and well-supported.
3.) Get rid of Python or at least enhance GRC that much that you need to
go into Python only in real hardcore cases. GRC is the way to go. Comeon
- - even software is developed visually nowadays without much hand-coding...
There's essentially *zero* chance that Python is going to go away. I'd
also assert that it will *never*
be the case that there will be no circumstances under which you'll
have to augment the functionality
that GRC encompasses. Yes, it needs more blocks--both existing ones
that haven't been GRCed, and
new blocks that haven't been invented yet. And perhaps there needs
to be more automation of how
those blocks show up in GRC. But there are *no*
graphical-programming tools that can fully-encompass
all the types of programming problems and algorithms one might want
to implement. In fact, the "connect the blocks"
paradigm is inherently limited in the classes of problems that can be
economically expressed under that paradigm.
There will always be cases in which you'll need to augment what GRC is
capable of. There should perhaps be better mechanisms
for augmenting those capabilities, and better documentation for the
mechanisms that already exist--the XMLRPC stuff, for example,
is really quite powerful, but I fear I may be the only person using
it. Further, at least in a Linux environment, existing mechanisms
like FIFOs can be used fairly easily to do "stuff" outside of the
normal Gnu Radio pipeline that don't nicely "fit" the connect-the-blocks
model. But documenting all of that will tend, necessarily, to wander
off into documenting existing Linux mechanisms, and that begs the
question "how much does a documentation effort wish to bite off".
4.) Make sure I don't have to publish the source if I write some
specific block or application for/with GNURadio. My boss and our
customers are kinda sensitive about giving out information that are
operatively relevant :).
The existing GPL licensing would make that difficult. But you can
isolate your own functionality behind existing IPC mechanisms, and thus
avoid
binding any of your code to the Gnu Radio libraries.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio