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
