[USRP-users] B210 bad packet errors with sc8 wire format

Weaver, Tyler tweaver at lgsinnovations.com
Thu Apr 30 12:30:41 EDT 2015

I understand your point about UHD not knowing if the hard drive can swallow the data fast enough.  However, I am able to run rx_samples_to_file with a N210 on the same computer(s) with a rate of 50e6 with no overflows.  That’s what has me confused.


On Apr 30, 2015, at 10:18 AM, mleech at ripnet.com<mailto:mleech at ripnet.com> wrote:

I'll comment on your second point.  The rx_samples_to_file example isn't heavily optimized, in particular, it isn't multi-threaded, so
 that filesystem writes aren't decoupled from vacuuming up samples from the hardware.  If you specify /dev/null as the file to write in
 rx_samples_to_file, you'll probably notice that the point at which you start getting 'O' is moved further out.

From a 10K-foot perspective the USRP device is like Niagara Falls.  It throws data at you at whatever rate you ask for.  Just as Niagara Falls has no idea how big the bucket is at the bottom you're trying to capture it with, neither does the USRP know or care.  The UHD drivers are roughly as optimized as they can be, given that this stuff is running on a general-purpose operating system, where the OS produces latencies, and buffering and scheduling behavior that are entirely outside of the control of UHD.   And emergent throughput and scheduling
 behaviors on general-purpose, multi-user OSes are hard to control and predict.

Now, examples, like rx_samples_to_file *could* be better-optimized, but they're just examples.  They aren't really intended as production applications.  The range of application of USRP hardware is *immense*, there's no way that the UHD team could possibly produce optimized examples that cover all those application domains.  Having said that, rx_samples_to_file *could* be optimized to use multiple threads, and that input has already gone into Ettus R&D.  No prediction on if/when something will happen on that front.

For your first point, I'll comment that I use 8-bit mode myself on a B210 at 2 X 11.5Msps on an Odroid XU3.  It works well most of the time, with only an occasional sample drop, but what I *do* find is that 'O' are nearly always accompanied by some vrt packet errors as you observe. I'm hoping that someone from R&D can comment on this.

On 2015-04-30 12:05, Weaver, Tyler via USRP-users wrote:

searching through the list I see that others have problems with sc8 on the b210.  if this is the case and it's not supported, then why doesn't uhd return an error to that affect.  Also, why does it seem to work on the benchmark_rate application?

Secondly, this still doesn't explain the overflow errors.  Is there a better method than what is in rx_samples_to_file to get samples form the radio and not result in overflow errors?


On Apr 30, 2015, at 8:53 AM, Weaver, Tyler <tweaver at lgsinnovations.com<mailto:tweaver at lgsinnovations.com>> wrote:


I am getting bad packet errors, the exact error is below when doing sc8 wire format reads with rx_samples_to_file however I get no errors when running benchmark_rate.  What could cause this?

I have tested this on 4 separate computers, all with similar specs, i7, 16gig ram, solid stated hard drives on fedora 21, mac OS X, and ubuntu LTS.  In all cases I get the same result.  Also, sc16 with rx_samples_to_file writing to null results in overflow errors on all computers, yet no errors when run with benchmark_rate.  When an overflow error is returned is there a way for me to know how many samples were lost so I could just insert zeros to keep timing accurate?  Also, I don't believe writing to the hard drive is too slow as I have a N210 that I can run rx_smaples_to_file at a rate of 50MS/s with no errors.

All of the computers are running UHD 3.8.2 built from source.

Thank you for your help.


$ ./rx_samples_to_file --rate 28e6 —null --args "master_clock_rate=56e6" --freq 2e9 --stats --wirefmt sc8
Mac OS; Clang version 6.0 (clang-600.0.56); Boost_105500; UHD_003.008.002-0-unknown

Creating the usrp device with: master_clock_rate=56e6...
-- Operating over USB 3.
-- Detecting internal GPSDO.... Found an internal GPSDO
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 56.000000 MHz
-- Actually got clock rate 56.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
Using Device: Single USRP:
  Device: B-Series Device
  Mboard 0: B210
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: FE-RX2
  RX Channel: 1
    RX DSP: 1
    RX Dboard: A
    RX Subdev: FE-RX1
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: FE-TX2
  TX Channel: 1
    TX DSP: 1
    TX Dboard: A
    TX Subdev: FE-TX1

Setting RX Rate: 28.000000 Msps...
Actual RX Rate: 28.000000 Msps...

Setting RX Freq: 2000.000000 MHz...
-- Successfully tuned to 2000.000000 MHz
Actual RX Freq: 2000.000000 MHz...

Waiting for "lo_locked": ++++++++++ locked.

Press Ctrl + C to stop streaming...

UHD Error:
    The receive packet handler caught an exception.
    ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

USRP-users mailing list
USRP-users at lists.ettus.com<mailto:USRP-users at lists.ettus.com>

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

More information about the USRP-users mailing list