It's not a USB hardware problem, it's that he's trying to use a small
ARM based SBC (the Orange Pi 5 plus).
For the DVB-T2 transmitter, there are several blocks that require
significant CPU resources. What tends to happen is the GNU Radio
scheduler will sometimes run all of the high CPU blocks on the same core
for some period of time. Underruns can occur when that core exceeds 100%
usage.
Having UHD being one of the high CPU blocks just makes things worse.
The solution is too pin each block to a specific core, but that's some
tricky stuff. You have to use htop to determine which blocks need the
most CPU and come up with a core layout that evenly distributes the
load. More difficult when you only have 4 cores and the flow graph has
15 blocks.
Ron
On 9/30/24 07:42, Ceren Karaköse wrote:
Hi all,
This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission from your
USB port to your SDR device. 960M = 15M samples * 32 bits/sample (lime
sdr sink/source working with 32 bit float) * 2 (because Inphase and
Quadrature assuming you're working with complex signals).
If you are using usb 2.0 port, which has 480 Mbits/sec data rate, you
cannot achieve the desired data rate. Hence the underruns. On the
otherhand, if you're using USB 3.0 port on your device, it should be
*theoretically* able to achieve that rate as its data transfer speed
is 5Gbps. However, mind you that these values are *the maximum* values
that can ever be achieved. I'm not the expert on USB communication but
from experience never ever was I able to achieve that theoretical data
rate from USB connections. This is perhaps related to computer
architecture and how the bus is shared. For example your usb mouse and
keyboard *may* be sharing some of the bandwidth allocated for USB
connections in the computer and hence "stealing" from the theoretical
maximum data transfer rate.
My suggestion is that if you ever plan to go above 10M samples/sec,
use an ethernet-connected SDR.
Get Outlook for Android <https://aka.ms/AAb9ysg>
------------------------------------------------------------------------
*From:* discuss-gnuradio-bounces+ceren.karakose=outlook....@gnu.org
<discuss-gnuradio-bounces+ceren.karakose=outlook....@gnu.org> on
behalf of Ron Economos <w...@comcast.net>
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
*Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
series of devices).
Ron
On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport parameters for UHD USB devices
here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it kind of has to be. It supports
> many different hardware devices, going back to the USRP1
> originally sold in 2004. But having said that the "sample moving"
> pathways in the code are quite efficient. One shouldn't
> confuse the size of the library with the efficiency of the critical
> pathways.
>
>
