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