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. > >
