On Thu, Dec 29, 2011 at 6:41 PM, Marcus D. Leech <[email protected]> wrote:
> ** > > On Thu, Dec 29, 2011 at 5:15 PM, Andrew Davis <[email protected]>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 Consortiumhttp://www.sbrac.org > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
