EttusResearch / uhd

The USRP™ Hardware Driver Repository
http://uhd.ettus.com
Other
970 stars 653 forks source link

Cannot receive IQ samples with high sample rate #541

Closed ersinyar closed 3 months ago

ersinyar commented 2 years ago

Issue Description

I have a USRP, Ettus x310, with daughterboard WBX 50-2200 MHz Rx/Tx (40 MHz). I try to receive samples using Python API. I cannot obtain samples with sampling rate bigger than 40 MS/s without errors. USRP throws overflow "O" and dropped samples "D". I use a very large number for "recv_buff_size" parameter too.

Using benchmark_rate.exe coming from UHD driver installation, I can confirm that 50 MS/s OK, but higher sampling rates are problematic.

USRP bandwidth is limited by daughterboard. Still, I think I should be able to get the samples without errors.

What might be the problem? Thanks.

Setup Details

UHD 3.15.0.0, Windows 10, 10 Gb Ethernet connection, Intel X710 ethernet adapter, 10 Gb Ethernet Switch I have enabled Jumbo packets.

Expected Behavior

Obtaining 50 - 100 - 200 MS/s without errors in each second

Actual Behaviour

For sample rates bigger than 40 MS/s overflows and dropped samples occur

Steps to reproduce the problem

I use below code segment.

`import uhd import numpy as np

usrp = uhd.usrp.MultiUSRP()

num_samps = 100000000 # number of samples received center_freq = 1000e6 # Hz sample_rate = 100e6 # Hz gain = 25 # dB

usrp.set_rx_rate(sample_rate, 0) usrp.set_rx_freq(uhd.libpyuhd.types.tune_request(center_freq), 0) usrp.set_rx_gain(gain, 0)

st_args = uhd.usrp.StreamArgs("fc32", "sc16") st_args.channels = [0] metadata = uhd.types.RXMetadata() streamer = usrp.get_rx_stream(st_args) recv_buffer = np.zeros((1, 1000000), dtype=np.complex64)

stream_cmd = uhd.types.StreamCMD(uhd.types.StreamMode.start_cont) stream_cmd.stream_now = True streamer.issue_stream_cmd(stream_cmd)

samples = np.zeros(num_samps, dtype=np.complex64) for i in range(num_samps//1000000): streamer.recv(recv_buffer, metadata) samples[i1000000:(i+1)1000000] = recv_buffer[0]`

ghost commented 2 years ago

I see no one commented, so I am going to give it a shot.

I think a large part of the problem is definitely Windows. When I was on Windows I could get 6 MS/s (duplex) stable (somtimes even this was unstable) and 12 MS/s (duplex) unstable. When I switched to Linux (Pop OS, an Ubuntu fork) I maxed out the SDR's sampling rate (23 MS/s duplex).

I used a B210. Also, I used the C++ API since that is always a better option for time sensitive work.

mbr0wn commented 3 months ago

This hasn't seen any info in a while -- we routinely do higher rates, so it's likely that the host system (and OS) is part of the issue.