discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD default subdevice.


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] UHD default subdevice.
Date: Fri, 23 Dec 2011 22:18:10 -0500

On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis <address@hidden> 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 <address@hidden> wrote:
On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis <address@hidden> 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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]