discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] UHD default subdevice.


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] UHD default subdevice.
Date: Thu, 29 Dec 2011 18:41:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On Thu, Dec 29, 2011 at 5:15 PM, Andrew Davis <address@hidden> wrote:
I will, but a lot are unmaintained. This is something that UHD should do anyway, and if it helps eliminate bad code then it's a win-win situation. Theres really no reason a program should have to ask for and set every UHD variable every time, this just adds a lot of clutter at the top of a program and if you don't have ALL variables user settable, someone somewhere with an oddball setup will have to rewrite every program they use for there setup, or they could just edit the default config file. Much simpler.

Sure. If you want this done as a UHD feature, you'll have to talk to those guys specifically about it. We're getting away from GNU Radio related problems (and potential solutions). I'd be happy to continue working with you on it for GR, but you've got a more general problem you're looking to solve.

Tom

 
I think I could go either way on this, but I think it's the case that ALL UHD-using applications with a command-line interface should be able to
  set *any* of the UHD parameters from the command line.  It is currently the case that this isn't true.  But perhaps what needs to be done
  is that (at least for the Python side), there needs to be a "standard UHD options module", with reasonable defaults.  There probably also
  needs to be a "standard Gnu Radio options module" (didn't we have one of those at one point?).  So your typical UHD+GR Python app will
  load the standard Gnu Radio options module, the Standard UHD options module, and then have it's own options in addition.  That
  would result in less clutter, and provide a consistent command-line experience and predictability about which options are actually
  present.  There's no reason that uhd_fft.py, for example, shouldn't be able to specify ALL of the relevant UHD parameters, including
  wire-format (ok, it now does, but you know what I mean), sub-device, etc, etc.  Same is true of Gnu Radio -- although there, it's not
  entirely clear what a "standard option set" would be.  For example, should "sample rate" be a Gnu Radio option that is "inherited" by
  the UHD option processor?

So, for UHD, the things I can think of off the top of my head that could reasonably go into a standard options module:

   frequency                  C
   gain                       C
   sub-device                 M
   device-id/args
   wire-format
   scaling for sc8
   1PPS source                M
   Reference source           M
   RX-antenna                 C
   TX-antenna                 C
   analog bandwidth           C
   sample rate
   nmboards
   nchannel

C = per-Channel parameter
M = per-Mboard parameter

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

reply via email to

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