[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
> 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,
>> 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:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> 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.
>>> 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
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
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
ability of the system, overall, to "keep up" is somewhat less than
the offered load. USB uses shorter transactions "over the wire" than
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