UHD default subdevice

GNU Radio
1

Hello all,

Some programs don’t let you specify a subdevice, they let UHD decide, in
my
case it picks wrong. Is there a uhd config file to chose the default
subdevice if one is not specified ( I also wouldn’t have to type "–spec
“A:0” so much ).

Thank you!

2

Could you give me a hint? How do you interface with UHD before a
C++/python program requests the device?

Well, you complained about having to “type --spec A:0” a lot, which is a
natural for a shell script that starts your program–whether that
program is written in C++ or Python, and simply pass in a fixed value
for “the --spec” option to the program you’re trying to run.

For example, any of the setup parameters (well, most) of a
uhd_usrp_source or uhd_usrp_sink can be taken from a variable or
command-line
parameter, using the “variables” section in GRC, so you make them
come from command-line parameters, and default those
parameters, and again, you can make it fancier with a shell script
surrounding the invocation of the target program. In fact,
I have one startup script that parses the output of “uhd_usrp_probe”
to determine what cards I’m dealing with, and set command-line
parameters appropriately from parsing the output of “uhd_usrp_probe”.
I’m also working on an easier-to-use little python program
that is intended to set a bunch of shell variables based on probing
the hardware and setting a bunch of standard variables–specifically
to support better autoconfiguration from within shell scripts, etc.

If the target program doesn’t support the parameter you want as a
command-line parameter, then add it, and submit it
to be folded back in to the mainline. I recently did this for
uhd_fft.py and rx_cfile.py to support the “sc8” alternative wire-format,
which is
necessary to support 33.33Msps and 50Msps sample rates out of
USRP2/N2XX.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

3

I see what your saying but typing “–address ‘type=usrp1’ --spec ‘A:0’
–antenna ‘TX/RX’” every time wasn’t my problem.
The problem is programs that let UHD pick the default device, I don’t
know
how UHD chooses but it could check ~/.uhd/uhd.conf
or something instead of guessing. As you said I could just fix the
programs, but many of them are not maintained and why
fix up useless old programs when I could be fixing UHD which is still
maintained and would fix the old programs in the process.
Same for main GNUradio programs, the default device/subdevice/antenna
parser options could be read from a config file too.
So does this already exist somewhere or how can I help implement it?

4

On Fri, Dec 23, 2011 at 8:23 PM, Andrew D.
[email protected]wrote:

So does this already exist somewhere or how can I help implement it?
An interesting proposition. The problem is that the modularity of the
USRPs
allows people to switch daughterboards easily and quickly. How would you
propose to set the defaults if people change their d’boards? Some kind
of a
hash on the description of the device to see if it’s the same USRP and
d’board configuraiton?

Tom

5

That might work, but why worry about people who reconfigure just yet, us
who use the device consistently still have to type several args
every-time
we run a program, the first step is a simple default device config file.

6

Capture your complex command line in a shell script seems an easy way to
do
this yesterday, today, and tomorrow.

Bob

On Friday, December 23, 2011, Andrew D. [email protected]
wrote:

That might work, but why worry about people who reconfigure just yet, us
who use the device consistently still have to type several args
every-time
we run a program, the first step is a simple default device config file.

On Fri, Dec 23, 2011 at 9:09 PM, Tom R. [email protected]
wrote:

On Fri, Dec 23, 2011 at 8:23 PM, Andrew D. [email protected]

7

On Fri, Dec 23, 2011 at 9:23 PM, Andrew D.
[email protected]wrote:

That might work, but why worry about people who reconfigure just yet, us
who use the device consistently still have to type several args every-time
we run a program, the first step is a simple default device config file.

I’m more concerned that changing the default would screw up people who
change their d’boards. Or are you suggesting we have a config file that
you
would enter as the parameter (-F ~/.gnuradio/usrp.conf)?

Would you be up for outlining the process that would go in to creating
and
using the file? What exactly would be automated? How would people set
the
defaults and decide to use them or not? That type of thing.

Of course, in the meantime, you could create a file that just contains a
line of the standard parameters (-a, -A, --subdev, etc.) and use cat file
in the command line to put it inline with command. Or make a shell
script
with the program with the parameters already specified (with the $* for
any
extras you want to put in). I’m not suggesting these as a real solution,
but they might help you temporarily.

Tom

8

On Sat, Dec 24, 2011 at 6:52 AM, Andrew D.
[email protected]wrote:

What I’m proposing is simply for the UHD, when not given a specific
device, to check for a configuration file ( in the users home directory
preferably ) and load its default device and settings. This way if you dont
have this config file it will still make up the default device ( I believe
this is ordered by a hash as my B side d’board is first for some reason ).
So my guess it to read in the config when UHD pulls devices off the device
hash table. Also it cannot be a command parameter as this would bring us
back to square-one as some 3rd party programs will not support it and will
offer no easy way to change what UHD picks.

Ok, so here’s what I’m seeing now. We have the program options interface
and on top of that, we have a check for a config file. This config file
should work with the standard directory look-up path: current dir, home
dir, system dir (maybe /etc/gnuradio [and a Windows equivalent] and
possibly set with a GNURADIO_CONFIG_DIR – will want to think on that
more
to make sure we support other environmental variables like that).

We should have a function defined in GNU Radio that parses this file. It
would take in a dictionary, or kwargs (we have used
the _modulator_class.extract_kwargs_from_options(options) to convert the
‘options’ object from the OptionParser class to kwargs). If the config
file
is not found, nothing happens. If there is a config file but they option
has already been set through the command line, then the command-line
value
should supersede the file. Otherwise, the dictionary is updated to
include
the new setting.

Of course, I’m using dictionary in the sense of Python, and this kind of
function would be trivial to write in Python, but we’d want to do it in
C++
for anyone working in that domain.

Tom

9

It’s going to have to be part of UHD because a lot of programs I’m
having
problems with are not using GNUradio, they just read from UHD. UHD
guesses
on a lot of things ( device, sub-device, antenna, fpga image, fpga
frequency etc. ) when not defined in the program, currently it’s up to
the
program to ask the user for these and set them, but some programs built
for
one persons needs have built-in defaults or simply let UHD guess and on
there system it guesses right but on mine it often doesn’t. Also I’m
having
problems with the order of commands sent to UHD, some programs converted
from the usrp-driver set frequency out of order with sub-device
selection,
this is OK if your sub-devices support the same range but mine do not
and
this causes problems so I have to rewrite programs ordering. The better
way
I believe is to send a list of settings to UHD and let it put things in
order, this might make the list of setting in a config file easier to
parse
also. We could also have a seperate GNUradio config file that the python
OptionParser class reads in first for some GNUradio program specific
defaults ( fft-size, fft-rate… ).

As you said it should look to UHD_CONFIG_DIR or GNURADIO_CONFIG_DIR
first
then check other spots. Also I don’t think anything will have to be done
in
python as UHD already returns its selection to python when you ask for a
device.

10

What I’m proposing is simply for the UHD, when not given a specific
device,
to check for a configuration file ( in the users home directory
preferably
) and load its default device and settings. This way if you dont have
this
config file it will still make up the default device ( I believe this is
ordered by a hash as my B side d’board is first for some reason ). So my
guess it to read in the config when UHD pulls devices off the device
hash
table. Also it cannot be a command parameter as this would bring us back
to
square-one as some 3rd party programs will not support it and will offer
no
easy way to change what UHD picks.

11

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.

12

On Thu, Dec 29, 2011 at 9:27 AM, Andrew D.
[email protected]wrote:

It’s going to have to be part of UHD because a lot of programs I’m having
problems with are not using GNUradio, they just read from UHD.

It seems like there is a lot of effort going into fixing problems with
bad
code; Perhaps these are issues you should take up with the developers of
those applications that are not written correctly.

-Matt.

13 
they could just edit the default config file. Much simpler.

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

14

On Thu, Dec 29, 2011 at 5:15 PM, Andrew D.
[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