Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)

[LRK]

On Thu, Dec 29, 2011 at 07:01:19PM -0500, Marcus D. Leech wrote:
> On 29/12/11 06:48 PM, Tom Rondeau wrote:
> >
> >
> > I absolutely agree on this. We should definitely have a standard uhd
> > options parser that we can pull in to any program using a uhd device.
> > Excellent suggestion.
> >
> > If we have/had one for GNU Radio before, I never used it or knew about
> > it. Having recently just fixed most of the examples, I never ran
> > across it, either. We do have a preferred style and suggested options
> > in our style guide on the Wiki, though.
> >
> > For this, we probably don't have enough general use options to have a
> > default GR options parser module, though. We should definitely make a
> > UHD one though.
> That was my suspicion--that there just aren't really any "general" Gnu
> Radio options, except perhaps for scheduler
>   tweaks (TPB vs not-TPB is the only one I can think of).

I keep thinking this may be a reason for the lower interest in GnuRadio.
If someone writes a program to run on a USRP2 and daughterboard and I want
to run it on my USRP1, the UHD part should take care of the differences
if the frequencies and such are compatible. The computer should be able
to tell what hardware is connected and use the appropriate parts or
default to the most likely.

I finally got programs to work with UHD and my USRP1 but only after much
searching and adding command-line info. I know I'm old school, but the
computer is supposed to work for the user as best it can rather than the
user having to work for the computer. This, of course, is about the
programming but I spend far too much time trying to get older programs
to work because of some update that breaks everything.

If I find some neat new block in GRC I spend way too much time trying to
figure out what parameters to enter rather than tweaking default params.
Of course the error messages are seldom useful either. The uhd_fft.py
finally worked on my 3 GHz 4-core machine after I figured out the options
but just hung when I clicked on anything. Seem to be the frame rate problem
which should have been fixed long ago.

It is hardly worth updating the hardware if the same problems will be
encountered. I'm afraid to update Ubuntu or GnuRadio at the moment since
my experiments will likely be stopped again. I have some programs I run
under FreeBSD, since that is my preferred OS, but I can't update any of
them because GnuRadio won't compile there at all since 3.2.2. Most of the
problems are probably like the header files in the TCP sink code when
something was probably "updated" from an old version.

I use GnuRadio a lot to just get bits to feed to C programs where they
get processed because doing that in GnuRadio is much harder. Good thing
I'm not doing this for a living.


-- 
LRK
gr-user . ovillatx.sytes.net