On Sat, Dec 24, 2011 at 6:52 AM, Andrew Davis <glneolistm...@gmail.com>wrote:

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

Ok, so here's what I'm seeing now. We have the program options interface
and on top of that, we have a check for a config file. This config file
should work with the standard directory look-up path: current dir, home
dir, system dir (maybe /etc/gnuradio [and a Windows equivalent] and
possibly set with a GNURADIO_CONFIG_DIR -- will want to think on that more
to make sure we support other environmental variables like that).

We should have a function defined in GNU Radio that parses this file. It
would take in a dictionary, or kwargs (we have used
the _modulator_class.extract_kwargs_from_options(options) to convert the
'options' object from the OptionParser class to kwargs). If the config file
is not found, nothing happens. If there is a config file but they option
has already been set through the command line, then the command-line value
should supersede the file. Otherwise, the dictionary is updated to include
the new setting.

Of course, I'm using dictionary in the sense of Python, and this kind of
function would be trivial to write in Python, but we'd want to do it in C++
for anyone working in that domain.

Tom




> 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

Reply via email to