On 08/26/2018 10:19 PM, RizThon via USRP-users wrote:
Hi all,
I'm still trying to reach 56MS/s on a B210 without (too many)
overflows. I was told that sc12 used to work with the B210 but broke
at some point.
Can someone confirm and tell me what version I should try?
On Windows, with all versions of 3.10.0.0, I get an error, whether I
use sc12 or not: /Error: RuntimeError: fifo ctrl timed out getting a
send buffer/
With uhd_3.10.3.0-release_Win64_VS2015.exe I can't use sc12:
Error: LookupError: KeyError: Cannot find a conversion routine for
conversion ID
Input format: sc12_item32_le
Num inputs: 1
Output format: sc16
Num outputs: 1
On Windows and Linux, UHD 3.12.0.0, with sc8, I don't get any overflow
with the following: rx_samples_to_file.exe --null --time 20 --freq
2450e6 --gain 50 --spb 680 --rate 55e6 --wirefmt sc8
With sc16 I get better results adding /--args
"num_recv_frames=44,recv_frame_size=680"/ , around 900 overflows
instead of almost 6000 without the /--args/.
With the same /--args/ with sc8 I get
[ERROR] [STREAMER] The receive packet handler caught a value
exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET
With sc12, I always get that error, whether I use /--args/ or not.
When going from 3.12.0.0 to 3.13.0.1, uhd_images_downloader.py says
everything is up-to-date, but when starting the B210 it says
Error: RuntimeError: Expected FPGA compatibility number 15, but
got 14:
The FPGA build is not compatible with the host code build.
So I removed all FPGA and FW and ran uhd_images_downloader.py again.
On Windows with 3.13.0.1, I can use sc12 but it doesn't seem to make
much difference whether I use sc16, sc12 or sc8 with /--args
"num_recv_frames=44,recv_frame_size=680"/, I get respectively 1880,
1840 and 1780 overflows over 20s.
Without the /--args/, I get 6600, 5460 and 3060 overflows respectively.
So again, what version of UHD should I use if I wish to use sc12 with
a B210?
Thanks.
I wouldn't specify the frame_size argument, and make you num_recv_frames
at least 128 if you can.
The main problem is that even *native* Windows WinUSB performance is
notoriously poor.
And if you're seeing similar problems in a *native* linux install, with
num_recv_frames >= 256, then your hardware combination just isn't
up to the task.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
