Re: [Discuss-gnuradio] gnuradio interface cleanup

[Eric Blossom]

On Fri, Feb 18, 2005 at 06:45:32AM -0800, John Gilmore wrote:
> 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!

I agree it's not clear or obvious, and is a pain.  However, the
reality of the situation is that there are only certain values of
sampling rate that either the Tx or Rx side can do.

We could provide an interface that allows the user to specify the
sampling rate that they want, and then check that against legal
values.  At least then they are thinking in terms more directly
related to the problem domain.

There are of course other constraints such as total USB throughput
that somebody has to be cognizant of.

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

I agree.

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

Both connectors on the "A side" daughterboard.  I is on one connector
and Q on the other.  [I have proto boards so I'm not sure how they are
labeled on the production version.]

You can get the signal to the "B side" daughterboard or two both sides
at once by changing the value of the mux argument to the constructor.
This is the -m mux option to most Tx commands.  See the comments in
usrp_standard.h, reproduced here:  [The CVS version of usrp generates
and installs docs in /usr/local/share/doc/usrp-<version>/html/index.html]

DAC0 is the I output on the A side, DAC1 is the Q output on the A
side, DAC2 is the I output on the B side, DAC3 is the Q output on the
B side.

  /*!
   * \brief Set output mux configuration.
   *
   * <pre>
   *     3                   2                   1                       
   *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
   *  +-------------------------------+-------+-------+-------+-------+
   *  |                               | DAC3  | DAC2  | DAC1  |  DAC0 |
   *  +-------------------------------+-------+-------+-------+-------+
   * 
   *  There are two interpolators with complex inputs and outputs.
   *  There are four DACs.
   * 
   *  Each 4-bit DACx field specifies the source for the DAC and
   *  whether or not that DAC is enabled.  Each subfield is coded
   *  like this: 
   * 
   *     3 2 1 0
   *    +-+-----+
   *    |E|  N  |
   *    +-+-----+
   * 
   *  Where E is set if the DAC is enabled, and N specifies which
   *  interpolator output is connected to this DAC.
   * 
   *   N   which interp output
   *  ---  -------------------
   *   0   chan 0 I
   *   1   chan 0 Q
   *   2   chan 1 I
   *   3   chan 1 Q
   * </pre>
   */
  bool set_mux  (int mux);


The current FPGA code (and constraints due to using the digital
upconverter in the AD9862) require that the DACs be used in I&Q pairs.

Note that the Rx side also contains a (different) mux which
controls routing from ADC's to digital down converters.


> 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 think this can be fixed with a set of hierarchical modules that
encapsulate common behavior.  E.g., "signal generator"
Then you can plug these together as you like.

> 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 Tx and Rx paths are independent and can be opened by different
processes.  This is reflected in the structure of the USB device
itself (different USB endpoints for Tx and Rx) and in all the code.

It would take considerably more work to provide independent control of
Tx A from Tx B and Rx A from Rx B.

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

We should probably fire a callback for the underrun/overrun stuff in
the audio and usrp code.  That would allow the app to handle or ignore
it as it pleases.

> 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;

The GUI code exits with File/Exit or close window.

Press Enter to Exit is definitely more fun ;-)

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

Good point.  We can wrap this with something.

> 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