Hi all, 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).
The samples are converted to a different data type before being sent to USRP (ref: https://files.ettus.com/manual/structuhd_1_1stream__args__t.html). The biggest OTW data type is sc16, with a total size of 32 bits (16 bits I & 16 bits Q). Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0 > series of devices). > That's true but it also depends on how you handle the transmit process. If you are using timed commands to transmit the sample (ref. https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD), it's easier to reach maximum throughput. Otherwise, you have to wait for the end of the burst/transmission, which comes with a data transfer delay (both options have this delay but timed commands save some time). I suggest using smaller wire formats such as complex int12 or int8. This might affect the performance of your application (due to the quantization) but it should eventually help you to reach higher sampling rates. PS. You are using an SBC to host your application, which might not have enough computing power or USB bandwidth as mentioned by others. Cheers, Anil On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse <ceren.karak...@outlook.com> 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. > > > > > >
