[USRP-users] Errors 0x8 and 0xf when capturing with b210.

Marcus D. Leech mleech at ripnet.com
Wed Apr 22 12:37:57 EDT 2015

On 04/22/2015 12:24 PM, Weaver, Tyler wrote:
> This is not through a VM in either case.  All of the following tests were performed on the Dell.
> The initial messages say that it’s operating over USB3, clock rate of 32 MHz, all tests pass and the reference is internal GPSDO.  Device is connected to included external power supply.  850 band antenna is connected to RF-A RX2.
> using rx_samples_to_file
> output was set to /dev/null
> duration was 60 seconds
> frequency was set to 800 MHz
> D = bad packet
> O = overflow error
> wirefmt/rate
> sc8/32e6: DO x5
> sc8/16e6: DO x2
> sc8/8e6: DO x2
> sc8/4e6: DO
> sc16/32e6: O x5
> sc16/16e6: O x2
> sc16/8e6: O
> sc16/4e6: O
> I ran several of these multiple times and saw different numbers of errors but not more than +/- 2 of what I showed above.  I determined the bad packet occurs when the format is set to signed complex 8 bit.  Where the overflow error rate seems to happen even at very low data rates and more at high data rates.  The error printed by rx_samples_to_file relating to the overflow indicates that the medium (hard drive or ram?) has to sustain a rate of a certain amount for this to be avoided.  What’s confusing is that I’ve never seen either of these errors when running the N210 I have on the same computer at a sample rate of 40 MS/s.  It is content to a usb3-to-ethernet dongle and performs just fine.
> Are there any other tests you’d suggest?  Does this tell you anything more about my configuration?  Could it have to do with the usb’s buffering?  Is there anyway to increase the size of the buffer?  Is the medium mentioned the hard drive or ram.  In either case they should be fast enough, this computer has a high end ssd that I’ve been able to stream to at 40 MS/s (sc16) off the pci buss with a different company’s radio with no problems.
> thank you,
> tyler
>> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <mleech at ripnet.com> wrote:
>> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>>> Hash: SHA512
>>> Sample rates:
>>> I have tried various sample rates and the errors occur at > 8 MHz.  For my application I need something > 20 MHz.  Preferably I want to sample at 30.72 MHz.
>>> Hardware:
>>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>> Clock rate:
>>> I’ve tried 30.72 and 61.44 MHz.  Neither have gotten rid of the errors.
>> What happens if you do something super-simple, like using rx_samples_to_file, and specifying /dev/null for the output file, and then try your
>>    various sample rates.  Leaving the master clock at the default 32MHz, I'd try 4, 8, and 16 msps.
>> If this is through a VM, then you can expect potentially-horrible USB performance...
Are you using the USB cable that Ettus provided, or something else?

Also, you might try experimenting with some of the USB transport 
parameters here:


When rx_samples_to_file talks about "medium" it's talking about whatever 
is storing your bytes.   It has now way of knowing definitively that the 
cause of
   any overruns is your filesystems inability to "keep up" it's just 
making a guess.

Also, not sure how you're getting 40Msps out of an N2xx, since that's a 
rate that would require fractional resampling in the N200. Rates must be
   an integer fraction of whatever the master clock rate is, and on the 
N2xx, that is fixed at 100MHz.

Also, a single overrun at startup is not-uncommon, as the kernels 
buffering system "ramps up".  Overruns after that are an indication that 
the average
   ability of the system, overall, to "keep up" is somewhat less than 
the offered load.   USB uses shorter transactions "over the wire" than 
ethernet, and
   is thus subject to higher overheads in things like IRQ processing.  
Also, the low-level USB3 drivers in the kernel may not be as optimized as
   ethernet drivers.  USB3 is still somewhat immature in the market.

More information about the USRP-users mailing list