Re: dvbt2 transmitter can not be real-time with LimeSDR

If you're using the packaged UHD on your particular distro, you are necessarily at the mercy of whatever decisions the packaging team made with respect to build options. 

Sent from my iPhone

On Sep 30, 2024, at 12:19 PM, Ron Economos <w6rz@comcast.net> wrote:



Here's the one NEON file in UHD.

https://github.com/EttusResearch/uhd/blob/master/host/lib/convert/convert_with_neon.cpp

On 32-bit ARM, I used to use this for the CMake invocation for my Beagleboard X15:

cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -g" ../

I don't have any 64-bit ARM boards to test with (I'm all in on RISC-V these days), so I'm not sure what's going on there. It's possible NEON is enabled by default, but it needs to be checked.

Ron

On 9/30/24 08:56, Anıl Gürses wrote:

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 <w6rz@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.karakose@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

---

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