Re: [Discuss-gnuradio] interface levels

[Ralph Hyre]

What you describe sounds a little bit like what concepts like RDL
(Radio Description Language) are for.

I agree that there need to be multiple levels of accessibility:

1) one level for the application builder building a consumer friendly
front-end based on existing blocks of functionality (think of LEGO
mindstorms and their RCX 'brick' and you are on the right track.)

2) a lower-level set of interfaces, designed to support standard radio
modulation and demodulation (FM detection, mixing, AGC, and so forth)

3) the physical interfaces to the specific RF platform.
(This is where you are concerned about whether you are talking to a
USRP, SSRP, or SDR1000)

- Ralph, N3FGW


On Fri, 18 Feb 2005 06:45:32 -0800, John Gilmore <address@hidden> 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!
> 
> 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
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>