discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD de


From: Andrew Davis
Subject: Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)
Date: Fri, 30 Dec 2011 15:16:07 -0500

Very true, all of it, GNUradio is quite the hodgepodge of different APIs, Languages, and Ideas.
And that's not always a bad thing, it can allow great flexibility, but sadly it is currently doing the opposite. With required versions of SWIG, Python 2.x/3.x and other helper programs it ONLY compiles reliably on ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small differences in GTK versions break most of wxgui. I am also a die-hard FreeBSD user forced into Ubuntu as no other operating system can compile GNUradio since 3.2. OK sorry for the rant.

What we are here to fix in this thread is the program to hardware incompatibility, as stated earlier many programs are created for one device configuration. UHD solves this though a unified interface to hardware with many settable parameters for anyone's hardware. The problem comes about when programers, not considering outside use of there work, do not extend control to the user and hard-code the parameters into there code. The way I believe it should be done is the programmer simple asks UHD for the default device, and UHD looks to a config file and finds what device, sub-device, and antenna to use. The programmer could of course overwrite this and tell UHD specifically what it wants for special cases. Now the lazy programmer just trying to get it working will not have to write out a long program header reading command line arguments and setting up the device in code but simply ask for a device and he can set what device it will return in the config file. This will motivate programmers to write more compatible code as it will be the easier route to simply ask for and setup a default device.

For the Python world we do need a more standardized option parser set, so that every program will not need that long command reading header but a simple call to a command parser.

Also I noticed a patch was submitted that fixed a problem with the new uhd_rx_cfile.py, before it was setting the gain before it picked out the sub-device, with the USRP1 being the only device with two sides this bug will only effect USRP1 users. This is the kind of thing that can be fixed by giving UHD a set of parameters and then letting it turn them on in order ( GAIN 45, WBX, 192.168.1.44, TX/RX, SIDE B, 250ks/s ).

On Fri, Dec 30, 2011 at 2:18 PM, LRK <address@hidden> wrote:
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

_______________________________________________
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]