> > Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm not > even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, you had > to compile UHD with specific CFLAGS to enable NEON. >
That's a good point. *AFAIK* even if you enable NEON cflag, there are no SIMD instructions for NEON. There is most likely a delay in data conversion. convert_benchmark.py in uhd/host/utils can provide more insights about the delay. Anil On Mon, Sep 30, 2024 at 11:49 AM Ron Economos <w...@comcast.net> wrote: > The DVB-T2 transmitter is a continuous stream. > > On x86, int8 gives a little help. int12 is worse than int16. > > Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm not > even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, you had > to compile UHD with specific CFLAGS to enable NEON. > > Ron > On 9/30/24 08:12, Anıl Gürses wrote: > > 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. >> > >> > >> >>
