[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gnuradio interface cleanup

From: James Mastros
Subject: Re: [Discuss-gnuradio] gnuradio interface cleanup
Date: Sat, 19 Feb 2005 09:10:49 +0100
User-agent: Debian Thunderbird 1.0 (X11/20050116)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]