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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
