|
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 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |