[Discuss-gnuradio] gnuradio interface cleanup

[John Gilmore]

The gnuradio packages have funny ideas about what users will need
to specify and how they need to specify them.  These ideas probably
came from implementing the guts of GNU Radio and the USRP, but they
don't really make sense to people who haven't implemented the guts.

For example, the programs we've been told to run to check out our
USRPs don't take any arguments in samples per second, or megasamples
per second, or bytes per second, or megabytes per second.  No, that
would be too easy!  Instead they take an argument which is the
"interpolation rate", i.e. the reciprocal of the fraction of 128
megasamples per second that we want to send.  Except when it's the
reciprocal of the fraction of 64 megasamples per second that we want to
receive.  Clear as mud, and oh so portable to other hardware, too!

The very first thing I'd want to specify to a signal generator (or to
any other processing chain that has an output signal, like a
transmitter) is what output port or device the signal should be fed
to.  There doesn't seem to be any way to specify that, in the programs
I've encountered so far.  E.g. in gnuradio-examples/usrp/siggen.py.

Oh, and which connector on which "Basic TX" board (on which USRP, if I
have more than one) does it output to "by default", even if I can't
change the default?  It's not documented and it's not obvious.

The programs also seem tied to particular input or output devices.
E.g. you can't use that signal generator to output to a sound card.
Why not?  There's a "dial tone" signal generator that's perfectly capable of
making output to the sound card -- but I bet it can't output to the USRP.

I also suspect that if I was able to tell it "continuously produce a
500Hz sine wave on the TX_A port of the TXA board", and left that
running in the background, or in one window, that the software would
be totally unable to simultaneously let me run another command like
"produce a 75 kHz square wave on the TX_A port of the TXB board for
three seconds".  Unless I wrote my own custom program for doing both
simultaneously in the same process.  This will make it hard to access
more than one radio at once: even though the USRP has eight high speed
ports, you probably can't use more than one input port and one output
port simultaneously, without doing custom programming.

The library routines called by high level code aren't silent -- they
spit things out to stdout or stderr, like "usrp: found usrp rev2",
or "uU".  Libraries should generally be seen and not heard.

The high level Python code generally runs its "main loop" while also
awaiting keyboard input with a prompt "Press Enter to quit".  It might
have been more fun if it said, "Press Enter to Exit".  But it would be
even better if it obeyed the standard interfaces, i.e. if it's a GUI
program, it quits when you close its window; if it's a terminal-based
program that isn't reading its input from the keyboard, it stops when
you interrupt it with the INTR character, generally Ctrl-C.  (When I've
tried that, it currently spits out lines of ugly debugging information
about where in the Python code I've interrupted it -- and probably
doesn't clean up on its way out.)

I hope we can knock some of these rough edges off the programming
interfaces quickly -- before too much code has these assumptions
embedded in it, and before too many users have to learn how to code
around these assumptions.

        John