UHD Announcement - October 15th 2010

GNU Radio
1

Hello list,

I would like to announce additional daughterboard support and API
changes in regards to the UHD. As of this announcement, all Ettus
hardware is supported under UHD.

Daughter board features and support

TVRX support

DBSRX fixes and ability to set the filter bandwidth

XCVR2450 ability to set the filter bandwidth

Notes on the bandwidth ranges can be found here:
http://www.ettus.com/uhd_docs/manual/html/dboards.html

API Changes

The device::send() call now has an optional timeout parameter. Meaning:
a call to send() can timeout if there is not an available buffer to fill
with data.

In the case of USRP2, send() currently blocks regardless of the timeout.
This will be fixed with host-based flow control; or if you really need
it, there is a #define waiting to be uncommented. The send timeout for
USRP1 functions properly.

All device timeouts are now doubles, and in units of seconds. For
device::recv() and device::recv_async_msg(), this is an API breakage.
The reason for the change being: to provide maximum precision to the
underlying implementation of the timeout should the need to do so arise.

If you were not using timeouts, then just rebuild your application (this
includes gr-uhd). If you were using the recv timeouts, convert from
units of milliseconds to seconds.

On buffer resizing

I believe the warning about buffer resizing has lead to some confusion
and misuse so I would like to clarify some things:

A UDP socket has re-sizable kernel buffers for send and receive. A large
receive buffer improves performance (reduces data overflows). However, a
large send buffer actually seems to hurt performance (increases data
underflow).

By default, the UHD will automatically resize the receive buffer to
something large, and print a warning if it cannot. On linux, the fix
is to change a sysctl value that caps the max receive buffer size.

There was some confusion as to how to deal with this warning and
resizing buffers with special device parameters. To clarify this, the
warning now prints the sysctl command that you should run, its even
polite.

The notes about resizing the socket buffers has been moved to the
transport application notes and marked for “advanced users”:
http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers

2

The device::send() call now has an optional timeout parameter.
The reason for the change being: to provide maximum precision to the
and misuse so I would like to clarify some things:
There was some confusion as to how to deal with this warning and
Feedback is welcome!
-Josh

OK, so did a “git pull” on both my Gnu Radio and UHD local repos today,
to update everything.

Did a “make clean; make; sudo make install” in both UHD and Gnu Radio.

I have a GRC-based application that uses a SingleUSRP UHD object. On
startup, I now get this error:

terminate called after throwing an instance of ‘std::runtime_error’
what(): usrp2: unhandled clock configuration pps source

Now, my GRC-based application doesn’t even specify the clock
configuration, and indeed, the generated python code has no reference
to the clock configuration in it. So my guess is that the default
initialization code now has an improper value in it.
HELP!

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium