uhd icon indicating copy to clipboard operation
uhd copied to clipboard

Cannot receive IQ samples with high sample rate

Open ersinyar opened this issue 3 years ago • 1 comments

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[i*1000000:(i+1)*1000000] = recv_buffer[0]`

ersinyar avatar Dec 14 '21 13:12 ersinyar

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.

ghost avatar Jan 25 '22 09:01 ghost