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

mleech at ripnet.com mleech at ripnet.com
Thu Apr 30 12:18:02 EDT 2015


 

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? 
> 
> tyler 
> 
>> On Apr 30, 2015, at 8:53 AM, Weaver, Tyler <tweaver at lgsinnovations.com> wrote: 
>> 
>> Hello, 
>> 
>> 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. 
>> 
>> tyler 
>> 
>> $ ./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
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
 

Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150430/3ce5dc53/attachment-0002.html>


More information about the USRP-users mailing list