discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] UHD examples/apps


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] UHD examples/apps
Date: Mon, 16 May 2011 22:49:22 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

On 05/16/2011 10:22 PM, Josh Blum wrote:
>
> The UHD should handle all cases and throw a reasonable error like "no
> antennas to select". Those neglected properties should be filled in for
> the sake of completeness.
>
> Whether or not to use an empty string as a pass-through, not so sure.
>
>   
It seems that for the sake of GRC, it might be reasonable to have some
kind of
  "do the reasonable default thing", even when you explicitly call some
function
  that would perhaps currently raise an exception, because you're asking
it to
  set some property that doesn't actually exist, due to missing hardware
features.

I mean, sure, if the app *explictly* (for example) asks for RX2 on a
board that doesn't
 have RX2, that should be an error.  But if the app passes in the magic
"do the reasonable
 default thing", that should not raise an exception.

Among other things, it makes for apps that behave more-or-less
rationally across multiple
  hardware configurations.  I have an app that works with UHD for
USRP1/USRP2/N2XX for
  all manner of daughtercards, by being careful to default things that
might cause
  the kind of grief observed above.

In fact, there are probably large classes of applications that really,
honestly, need a fairly
  "generic" view of the hardware, with the "view" being limited to:

      o center-frequency
      o bandwidth
      o [optionally] "alternate RX-only antenna port, whatever it's called"
      o [optionally] "external reference clock, whatever it's called"

This raises tangential questions as well.  Like whether raising an
exception because you've asked the
  hardware to do something it can't do (because it doesn't have that
feature) should raise an exception,
  or do something more polite.  Setting out-of-limit frequency, for
example, has traditionally caused a
  non-fatal error to occur, and applications simply carry on. The
question is whether other such
  hardware-configuring "stuff" should be equally forgiving.   If I have
a surveillance radio application,
  and I "typo" in entering a frequency, it shouldn't cause my python
stack to collapse in a mess of
  horrible exception handlers, and I think perhaps other hardware
feature settings should be equally
  polite.

But maybe it's just after my bedtime :-)



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]