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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
