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?
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
