[USRP-users] b200 Overflows

Marcus D. Leech mleech at ripnet.com
Mon Sep 29 10:14:39 EDT 2014

On 09/29/2014 10:04 AM, Marcus D. Leech via USRP-users wrote:
> On 09/29/2014 03:00 AM, Simon Brown wrote:
>> Marcus,
>> Using the 007.003.001 codebase uhd::stream_args_t("sc16", "sc12") 
>> crashes inside usrp->get_rx_stream. I don't see any reference to sc12 
>> in the https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so 
>> I'm a bit lost now.
>> Please clarify (I've read the source) if I get an overrun then the 
>> data is being delivered from the B200 faster than the UHD.dll is 
>> reading it? If this is the case I also believe that there's no way I 
>> can tell the underlying code to flush the LibUSB buffers?
>> I'm currently having considerable success with all Ettus hardware 
>> flavours but am a tad stuck with the whole UHD concept / way of life, 
>> your help is greatly appreciated.
>> Simon Brown G4ELI
>> http://v2.sdr-radio.com
> http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc
> Describes the components of stream_args_t.  In particular, the first 
> component is the desired host-side ("CPU") format, the second the 
> wire-side
>   format.
> I think sc12 was introduced after UHD 3.7.1, so upgrade.
Actually, I somewhat mis-spoke.  As of current release, there is no 
converter from sc12 to sc16, only to fc32, so if you use sc12 
wire-format, you
   pretty-much have to use fc32, and then if desired, convert it 
yourself to an integer format.

Some DSP folks have an aversion to floating-point for DSP work, but in 
fact on "ordinary" machines, notably, x86, floating-point is very often the
  better format for heavy-duty numerical work, both because of the heavy 
pipelining of non-SIMD floating point, and because of the SIMD units
  that can be used aggressively to handle floating-point numerical 
streams.   There are exceptions, of course, where the integer ALU is 
faster, but
  there's generally much more "pressure" on the integer unit from 
ordinary, non-numerical, flows.

There is no "flush the USB buffers, please" API call.  The overall 
reason for overruns is that the hardware is delivering them faster than your
   system, overall, can cope.  The "harvester" of data in UHD is quite 
efficient, so if things are running into trouble, it's usually the 
*overall* system
   that is the cause.   There's usually no single cause, but a 
collection of things all cooperating to hamper your ability to handle 
real-time data flows.

The benchmark_rate tool that I mentioned last week can be used to get 
some rough idea of what the basic "stack" from USB up to UHD can handle,
   without bringing in the complexity of actually "doing stuff" with the 
resulting samples.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/bf9ea66c/attachment-0002.html>

More information about the USRP-users mailing list