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

[Marcus D. Leech]

> 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
>
>
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 Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org