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
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.
From: discuss-gnuradio-bounces+ceren.karakose=outlook.com@gnu.org <discuss-gnuradio-bounces+ceren.karakose=outlook.com@gnu.org> on behalf of Ron Economos <w6rz@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 LimeSDRSorry, 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.
>
>
No comments:
Post a Comment