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

Tyler Weaver tweaver at lgsinnovations.com
Wed Apr 22 14:14:10 EDT 2015


I don't know if this is useful but here is the specific errors generated
by my code when trying to do many captures.  I'm outputting some
debugging messaging to show what sort of scans are causing the error,
yet it happens in either case.  In between captures I'm asking for
different center frequencies:

STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 7e+06fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,

UHD Error:
    The receive packet handler caught an exception.
    ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:24 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,

UHD Error:
    The receive packet handler caught an exception.
    ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,

UHD Error:
    The receive packet handler caught an exception.
    ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,

UHD Error:
    The receive packet handler caught an exception.
    ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:49 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:49 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:50 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:51 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
Wed Apr 22 12:02:51 2015



tyler

On 04/22/2015 12:02 PM, Marcus D. Leech wrote:
> On 04/22/2015 01:03 PM, Weaver, Tyler wrote:
>> I am using the cable that was provided with the B210.  I misspoke on
>> the N210, I’m sampling at 50 MS/s with a bandwidth of 40 MHz.
>>
>> Thank you for the link.  I’ll change these and report if it affects
>> anything.
>>
>> What do you think is causing the bad packet errors?  How could I debug
>> that?  It seems to correlate with selecting 8bit samples.  I would
>> think 8bit samples would tax the system less, yet it seems to have no
>> affect on the number of overflows.
> Well, 'D' is dropped packet.  The question is where that dropped packet
> is happening.  Once a packet in a flow of packets gets dropped, the overall
>   "syntax" of the flow gets out-of-sync.
> 
> Making this worse is that there's a long-standing bug in the FX3 USB-3
> chip, that Ian talked about a few days ago, where when 'O' happens, the
>   DMA machinery in the FX3 gets confused.  This doesn't always happen,
> and happens on some systems on not others (there are subtle
>   USB-land interactions between the host controller and FX3 that are
> largely 'invisible' to the Ettus code).   Ettus R&D are really busy
> trying to figure
>   this out.  But again, on some systems, it's fine, on others, you get
> this weirdness.
> 
> In terms of USB 3 controllers, the Intel 8 series, which is what, as I
> recall, you have, is generally regarded as one of the better ones.
> 
> 
>>
>> Is there a known good set of USB hardware I could purchase to avoid
>> these problems?
>>
>> thank you,
>> tyler
>>
>>> On Apr 22, 2015, at 10:37 AM, Marcus D. Leech <mleech at ripnet.com> wrote:
>>>
>>> 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:
>>>>>> -----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.
>>>>>>
>>>>>> 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:
>>>
>>> http://files.ettus.com/manual/page_transport.html#transport_usb
>>>
>>> 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