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

[Marcus D. Leech]

> The obvious thing to do is either set the closest possible rate and
> provide a warning or decide it is not at all close and error off. If
> the user program can read the actual setting, it might well just use
> that with a little math to make the program work.
UHD already does that.  But the resulting program behaviour may be wildly
  not what you intended.

> My suggestion is not that these things can be perfect but that the user
> should spend her time working on software defined radio development not
> repeatedly fixing new bugs. My fisrt build of 3.5(?) on Ububtu resulted
> in a situation where starting the program caused the USRP to vanish. If
> I just moved it to the FreeBSD machine, it would not work there either.
> Powering down, it would reload and work again. I think it was loading
> the USRP with the wrong firmware but that went away and I never identified
> the problem.
I'm sorry that you had USRP problems after you upgraded to 3.5.  Knowing 
that
  sooner, rather than later, may have resulted in fixes sooner as well. 
 For what
  it's worth, I have a flotilla in my personal lab of USRP hardware, 
including USRP1
  and USRP2.  They both worked just fine with 3.5, with the exception 
of a minor
  glitch involving USRP1 and hardware interpolation that was only in 
the master
  branch of UHD, and which was fixed before Xmas.

The build-gnuradio script arranges for the UHD firmware to be in "the 
right place", which
  is /usr/local/share/uhd/images.  The USRP1 firmware/FPGA images 
haven't changed in a
  very long time, so as long as they're in the right place, they're 
compatible.  Another issue
  is that USB-2.0 is sometimes flaky when there are multiple devices on 
the USB.  That is an
  issue I have found with hardware other than USRP1, including some USB 
audio devices.
  The bus can get into a "funny" state, and the only fix is to reboot 
the host machine, or
  sometimes, just power-cycle the devices on the bus.  The 
recommendation is to run
  USRP1 (and now B100) on a dedicated USB-2.0 port, *preferrably* on a 
dedicated
  USB controller, which with most motherboards means a separate 
PCI/PCI-e USB card
  for either your *other* USB devices, or your USRP1/B100.


> As I said, I'm old school. We did not have all the memory and speed of
> today and making programs bullet-proof was part of the job.
I fully agree with "bullet proof".  But the pragmatic aspect of the 
situation is that modern software
  relies on *mountains* of other pieces of software to work properly 
underneath it.  It's not efficient
  or productive to have the "top layer" project fixing all the bugs in 
the underlying layers, and sometimes,
  there aren't any reasonable work-arounds.  And often, the subtlely of 
those bugs (see the recent
  Boost locking issues for example) may take *years* to finally nail 
down, and at the end of the day,
  the fix is in some dependency, not in Gnu Radio itself.

For example, the scheduling and various other algorithms in the Linux 
kernel aren't particularly well-tuned
  for real-time data streaming with low-latency.  Different versions of 
the kernel will have different
  emergent behaviours with respect to scheduling.  Sometimes those 
changes will have impact on
  Gnu Radio throughput or latency, or both.  Should Gnu Radio decide 
"screw it, we're writing our own
  custom kernel that is tuned to Gnu Radio's particular needs"?  While 
that might be the right answer for
  *some* people, this is a community-developed project, that must 
necessarily stand on the shoulders of
  giants we don't control or even influence particularly well.

In the old days, it was much more usually the case that large software 
systems were integrated wholes.
  Very little dependency on outside libraries, with the possible 
exception of things like LIBC, or whatever
  your "system API library" was called.  You very typically had 
complete control  over the delivered
  quality of your product.  It's very, very rare indeed these days to 
have that luxury, with the possible exception
  of certain classes of embedded systems (and many of *those* now run 
Linux or *BSD).

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org