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

Reply via email to