Re: [Discuss-gnuradio] gnuradio interface cleanup

[James Mastros]

Eric Blossom wrote:
> 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.
...on any particular device.  It's important to remember that the USRP, 
while one of the most powerful devices available for this work, is quite 
expensive, and there are other, less powerful, less expensive, and more 
common devices available, and it would be nice, both in terms of having 
more people able to use gnuradio, and having more people able to 
contribute to gnuradio, to be able to use all these devices, rather then 
just the USRP.

Various devices have various different limitations; generic applications 
should probably pass whatever IF, sampling rate, etc, that they want, 
and the device-dependent layer should do the best it can to abide by 
their wishes, and inform the device-independent layer of what actually 
happened.  Preferably, it should be possible to do most interesting 
things without worrying about where the samples are coming from, be it a 
file, a TV tuner (obviously one that can get at the tuned baseband, and 
not just the demodulated sound), or a USRP.

(The other way of doing this is to have an API to find out the 
limitations of the device, and simply error if the device-independent 
program requests something of the device it cannot handle.  This isn't 
as good, because it means that users have to do more to write portable 
programs, which should be made as easy as possible.  Also, it isn't 
always easy, or even possible, to describe the limitations of a given 
device -- sometimes, the only way to tell is to ask the device, and see 
if it errors, or the limitations are known, but not simple to describe.)

        -=- James Mastros