[Discuss-gnuradio] UHD Announcement - October 15th 2010

[Josh Blum]

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

-----------------------------------------------------------------------
Feedback is welcome!
-Josh