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.
On Fri, Dec 23, 2011 at 10:18 PM, Tom Rondeau <trondeau1...@gmail.com>wrote: > On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis <glneolistm...@gmail.com>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 > > > > >> On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau <trondeau1...@gmail.com>wrote: >> >>> On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis >>> <glneolistm...@gmail.com>wrote: >>> >>>> 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? >>> >>> >>> 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 >>> >>> >>> >>>> >>>> >>>> On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech <mle...@ripnet.com>wrote: >>>> >>>>> 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 Leech >>>>> >>>>> Principal Investigator >>>>> Shirleys Bay Radio Astronomy Consortium >>>>> http://www.sbrac.org >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
