Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)

[Tom Rondeau]

On Thu, Dec 29, 2011 at 6:41 PM, Marcus D. Leech <address@hidden> wrote:

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?

I absolutely agree on this. We should definitely have a standard uhd options parser that we can pull in to any program using a uhd device. Excellent suggestion.

If we have/had one for GNU Radio before, I never used it or knew about it. Having recently just fixed most of the examples, I never ran across it, either. We do have a preferred style and suggested options in our style guide on the Wiki, though.

For this, we probably don't have enough general use options to have a default GR options parser module, though. We should definitely make a UHD one though.

Also, Python 2.7 has deprecated optparser in favor of argsparser (http://docs.python.org/library/optparse.html). We should start trying to make our programs compliant with this while still supporting Python 2.5. It seems awkward to have a check in every Python script if it's 2.7 or earlier, though, but we could easily do it in the UHD options module.

Tom

 

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio