UHD examples/apps

Hi list,

I just wanted to point out that last week I added a couple of UHD-based
examples to the GNU Radio master git branch.

You can find these in: gr-uhd/apps

They are replicas of usrp2_fft.py and usrp2_rx_cfile.py, which are two
of
the most widely used scripts, but lacking UHD implementation in the
tree.
While we want to make a more full-blown spectrum analyzer app using UHD,
I
wanted to make these first steps in order to provide more support for
UHD
apps as well as show how to use them.

Also, when you install GNU Radio, these scripts will be installed into
$(prefix)/bin.

Tom

Hi Tom,

I tried running the uhd_fft.py script with the USRP1, but I run into
an error with

RuntimeError: LookupError: KeyError: cannot set this property
in void usrp1_impl::mboard_set(const wax::obj&, const wax::obj&)
at /home/csboyer/uhd/host/lib/usrp/usrp1/mboard_impl.cpp:392

due to a call in the .py file:
self.u.set_clock_config(uhd.clock_config.internal(), uhd.ALL_MBOARDS)

I checked around in the source, but it seems to be a generic error
flag in a switch case statement.

On 05/16/2011 05:26 PM, Colby B. wrote:

self.u.set_clock_config(uhd.clock_config.internal(), uhd.ALL_MBOARDS)

Aha, no clocking options were implemented on USRP1. Thats why you see
the error. I suppose it would be better to properly handle setting clock
config even though its not really configurable.

-Josh

On Mon, May 16, 2011 at 6:22 PM, Josh B. [email protected] wrote:

at /home/csboyer/uhd/host/lib/usrp/usrp1/mboard_impl.cpp:392


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Hi Josh,

I ended up editing out that line and it works fine.

Also the .py threw an error on

File “./uhd_fft.py”, line 212, in set_freq
self.myform[‘baseband’].set_value(r.actual_inter_freq)
AttributeError: ‘tune_result_t’ object has no attribute
‘actual_inter_freq’

It should really be r.actual_rf_freq

Maybe you can be kind enough to push the change. . .I don’t have access.

On 05/16/2011 09:22 PM, Josh B. wrote:

Aha, no clocking options were implemented on USRP1. Thats why you see
the error. I suppose it would be better to properly handle setting clock
config even though its not really configurable.

-Josh


Especially since GRC always sets the clocking option to something,
yes?


Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On 05/16/2011 09:50 PM, Josh B. wrote:

no, many of the parameters when left default yield no code. Part of the
goal of generating nice simple readable code.

-Josh

Hmmm, this will require some thinkage. I just ran into a similar
problem when running
Tom’s uhd_fft.py on a BASIC_RX, because it sets the antenna, and of
course, there aren’t
any antenna options on the BASIC_RX.

The question becomes whether we place the burden on the user app to
“know” what is reasonable,
and not ask UHD to set things that aren’t actually there, or whether
there should be some kind
of explicit “default” value that means “don’t barf on me, bro”.

For a hand-coded Python/C++ app, perhaps it’s reasonable for the APP to
ask UHD what
features are available, and only ask for settings related to those
features. But for GRC, it’s
harder to do that sort of thing, since GRC is inherently declarative,
and not procedural.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On 05/16/2011 06:46 PM, Marcus D. Leech wrote:

Especially since GRC always sets the clocking option to something, yes?
no, many of the parameters when left default yield no code. Part of the
goal of generating nice simple readable code.

-Josh

Here is a patch that uses the get_center_frequency to readback the
actual baseband frequency. I prefer that over the tune result given the
incompatibility due to the naming mix up. My bad.

http://gnuradio.org/cgit/jblum.git/commit/?id=71d6e9d8b5396467ca3b5e004cc1b9a365554db4

-Josh

Hmmm, this will require some thinkage. I just ran into a similar
problem when running Tom’s uhd_fft.py on a BASIC_RX, because it sets
the antenna, and of course, there aren’t any antenna options on the
BASIC_RX.

I would like the app to only set the antenna when the option is
specified. So if options.antenna: self.u.set_rx_antenna(…)

The question becomes whether we place the burden on the user app to
“know” what is reasonable, and not ask UHD to set things that aren’t
actually there, or whether there should be some kind of explicit
“default” value that means “don’t barf on me, bro”.

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.

For a hand-coded Python/C++ app, perhaps it’s reasonable for the APP
to ask UHD what features are available, and only ask for settings
related to those features. But for GRC, it’s harder to do that sort
of thing, since GRC is inherently declarative, and not procedural.

Indeed.

The available antennas are query-able. Available clock configurations
are not yet. Thats planned for the next rev of the API.

-Josh

On Tue, May 17, 2011 at 2:45 AM, Colby B. [email protected]
wrote:

in void usrp1_impl::mboard_set(const wax::obj&, const wax::obj&)
-Josh

Also the .py threw an error on

File “./uhd_fft.py”, line 212, in set_freq
self.myform[‘baseband’].set_value(r.actual_inter_freq)
AttributeError: ‘tune_result_t’ object has no attribute ‘actual_inter_freq’

It should really be r.actual_rf_freq

Maybe you can be kind enough to push the change. . .I don’t have access.

I can certainly push a change, but patches are always welcome, too.

Josh, was there are change in the tune_result_t names? When I made the
code
last week, the actual_inter_freq existed but now it doesn’t.

Tom

On 05/16/2011 10:22 PM, Josh B. 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 :slight_smile:


Principal Investigator
Shirleys Bay Radio Astronomy Consortium