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

[Ceren Karaköse]

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@gnu.org 
 on behalf of Ron 
Economos 
Sent: Monday, September 30, 2024 5:27:19 PM
To: 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.
>
>

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

[Ron Economos]

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  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
 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@gnu.org

on behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: dvbt2 transmitter can not be real-time with
LimeSDR
Sorry,

Re: unable to execute new installation

[Elmore Family]

Thanks for the info Chris.

Now my result is as follows: (Note: the only change is in the last 2 lines 
of the message)


Running from source tree
Could not retrieve GNU Radio configuration directory from GNU Radio. Trying 
defaults.
Could not retrieve GNU Radio persistent state directory from GNU Radio. 
Trying defaults.

Traceback (most recent call last):
 File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
   from gnuradio.gr import paths
ImportError: cannot import name 'paths' from 'gnuradio.gr' 
(/usr/lib/python3/dist-packages/gnuradio/gr/__init__.py)


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in 


   run_main()
 File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in 
run_main

   sys.exit(main())
 File "/home/pi/gnuradio/grc/main.py", line 297, in main
   log_file = os.path.join(get_state_directory(), "grc.log")
 File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
   f"files to '{xdgand}'.")
NameError: name 'xdgand' is not defined

Jim

-Original Message- 
From: Chris Gorman

Sent: Monday, September 30, 2024 9:07 AM
To: Elmore Family
Cc: GNURadio Discussion List ; Volker Schroer
Subject: Re: unable to execute new installation

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris



On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:


What does 7513 refer to? How do I find it?

-Original Message-
From: Volker Schroer
Sent: Saturday, September 28, 2024 11:22 AM
To: GNURadio Discussion List
Subject: Re: unable to execute new installation

Please stay on the list.


First:

  File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
 f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment

is definitely a bug in the python code.

I proposed a fix. See #7513 on github.

This pr may not fix the reason of your problems, but you should get a
better error message.

What is the result of

gnuradio-config-info --prefix

Why do you start gnuradio-companion from the source tree and not from
the install directory?


Am 28.09.24 um 15:06 schrieb Elmore’s:
> I did perform the install command and I thought it worked. You also say
> this is a bug. Thus I am confused.
> Sent from my iPhone



--
This email has been checked for viruses by AVG antivirus software.
www.avg.com




--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

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

[Anıl Gürses]

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 
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@gnu.org
>  on behalf
> of Ron Economos 
> *Sent:* Monday, September 30, 2024 5:27:19 PM
> *To:* 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.
> >
> >
>
>

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

[Ron Economos]

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

On 9/30/24 07:42, Ceren Karaköse 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@gnu.org 
 on 
behalf of Ron Economos 

*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* 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.
>
>

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

[Marcus D. Leech]

On 30/09/2024 10:27, Ron Economos wrote:
Sorry, but UHD is a big CPU hog for transmitting (at least with the 
B2X0 series of devices).


Ron
I just did a quick test using "benchmark_rate" into a B210, doing a "tx" 
test at 30Msps.  That consumed 52% of a single
  CPU on my i5-6200 system at 2.7GHz.  There were a handful of U during 
the 1 minute test.


Since I don't have LimeSDR setup on my machine, I can't compare. Nor can 
I compare to BladeRF (the other USB-based

  tx-capable SDR).




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.

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

[Ron Economos]

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 
 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@gnu.org
 on
behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* 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.
>
>

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

[Marcus D. Leech]

On 30/09/2024 11:49, Ron Economos wrote:


The DVB-T2 transmitter is a continuous stream.

On x86, int8 gives a little help. int12 is worse than int16.

int12 requires some data "shuffling" on the CPU side that doesn't nicely 
fit into regular word sizes, so it's not a good idea

  unless you have USB bandwidth issues, but no CPU issues.


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 
 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@gnu.org
 on
behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* 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.
>
>

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

[Anıl Gürses]

>
> 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  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 
>> --
>> *From:* discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org
>>  on behalf
>> of Ron Economos 
>> *Sent:* Monday, September 30, 2024 5:27:19 PM
>> *To:* 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.
>> >
>> >
>>
>>

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

[Marcus D Leech]

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 iPhoneOn Sep 30, 2024, at 12:19 PM, Ron Economos  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 
  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 
 

Capture the Flag

[Federico 'Larroca' La Rocca]

Hi everyone,

For the fifth year in a row, we're organizing a little CTF during an
exposition event at our University (https://idm.uy/). Since it is
completely online (just like GNU Radio's CTF), we encourage people from all
over to join and play. The only caveat is that it is in Spanish, but many
English-speaking people have played it in the past.

If you're interested, you may read all the details at our webpage
https://ctf.idm.uy/ (or directly at
https://eva.fing.edu.uy/course/view.php?id=1557§ion=1#tabs-tree-start).
You may register with a group of up to three people by sending us a mail to
c...@fing.edu.uy.

The deadline to register is this Thursday, and the CTF begins this Friday!

best
Federico

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

[Ron Economos]

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.

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

[Ron Economos]

You could try DVB-T2 configurations that use less CPU. Both smaller FFT 
size and lower bitrate help. For example try the following test flow graphs:


vv009-4kfft.grc 27.588664 Mbps

vv010-2kfft.grc 14.364704 Mbps

vv011-1kfft.grc 6.169662 Mbps

If your receiver allows it, you can also use smaller channel bandwidths 
such as 5, 6, or 7 MHz. The bitrate will be scaled accordingly.


The DVB-T2 bitrate calculator is here.

https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c

Ron

On 9/29/24 22:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any 
hardware, “Probe Rate” block in GRC shows 15e6 samples per second at 
the output of the Tx (which needs about 9 Msps to work in real-time.)

Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested other 
SDR modules like LimeSDR.

But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with 
other blocks.

Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!

Re: unable to execute new installation

[Chris Gorman]

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris



On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:
>
> What does 7513 refer to? How do I find it?
>
> -Original Message-
> From: Volker Schroer
> Sent: Saturday, September 28, 2024 11:22 AM
> To: GNURadio Discussion List
> Subject: Re: unable to execute new installation
>
> Please stay on the list.
>
>
> First:
>
>   File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>  f"files to '{newpath}'.")
> UnboundLocalError: local variable 'newpath' referenced before assignment
>
> is definitely a bug in the python code.
>
> I proposed a fix. See #7513 on github.
>
> This pr may not fix the reason of your problems, but you should get a
> better error message.
>
> What is the result of
>
> gnuradio-config-info --prefix
>
> Why do you start gnuradio-companion from the source tree and not from
> the install directory?
>
>
> Am 28.09.24 um 15:06 schrieb Elmore’s:
> > I did perform the install command and I thought it worked. You also say
> > this is a bug. Thus I am confused.
> > Sent from my iPhone
>
>
>
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com
>
>

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

[Ron Economos]

The file gnuradio/gr-dtv/examples/README.dvbt2 contains links to TS 
files crafted with the correct bitrate for each example flow graph. For 
the vv011-1kfft.grc flow graph, it's:


https://www.w6rz.net/vv011-1kfft.ts

The correct invocation for dvbt2rate is:

./dvbt2rate 8 1 2 1966 48 1 1 0 0 3 0
FFT size = 1024
guard interval = 1/8
number of data symbols = 1966
number of FEC blocks = 48
code rate = 1/2
constellation = QPSK
frame size = normal
carrier mode = normal
pilot pattern = PP3
L1 constellation = BPSK

clock rate = 9142857.142857, TF = 249.956000 ms
Normal mode bitrate = 6169661.860487
High Efficiency mode bitrate = 6202654.704661

max symbols = 1984, max blocks = 48
symbols = 1982, max blocks = 48
cells = 1577708, stream = 1555200, L1 = 3344, dummy = 18944, unmodulated 
= 220


PAPR max symbols = 1984, max blocks = 48
symbols = 1982, max blocks = 47
cells = 1558048, stream = 1555200, L1 = 3344, dummy = -716, unmodulated 
= 220


I'll admit it's a little painful to use. 😳

Ron

On 9/30/24 06:58, Ali G. Dezfuli wrote:

Thanks Ron!
How can I make the related TS file? (e.g. for vv011-1kfft.grc)
The list in https://github.com/drmpeg/dtv-utils does not include QPSK!

On Mon, Sep 30, 2024 at 4:29 PM Ron Economos  wrote:

You could try DVB-T2 configurations that use less CPU. Both
smaller FFT size and lower bitrate help. For example try the
following test flow graphs:

vv009-4kfft.grc 27.588664 Mbps

vv010-2kfft.grc 14.364704 Mbps

vv011-1kfft.grc 6.169662 Mbps

If your receiver allows it, you can also use smaller channel
bandwidths such as 5, 6, or 7 MHz. The bitrate will be scaled
accordingly.

The DVB-T2 bitrate calculator is here.

https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c

Ron

On 9/29/24 22:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any
hardware, “Probe Rate” block in GRC shows 15e6 samples per second
at the output of the Tx (which needs about 9 Msps to work in
real-time.)
Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested
other SDR modules like LimeSDR.
But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up
with other blocks.
Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!

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

[Marcus D. Leech]

On 30/09/2024 01:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any 
hardware, “Probe Rate” block in GRC shows 15e6 samples per second at 
the output of the Tx (which needs about 9 Msps to work in real-time.)

Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested other 
SDR modules like LimeSDR.

But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with 
other blocks.

Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!


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.

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

[Ali G. Dezfuli]

Thanks Ron!
How can I make the related TS file? (e.g. for vv011-1kfft.grc)
The list in https://github.com/drmpeg/dtv-utils does not include QPSK!

On Mon, Sep 30, 2024 at 4:29 PM Ron Economos  wrote:

> You could try DVB-T2 configurations that use less CPU. Both smaller FFT
> size and lower bitrate help. For example try the following test flow graphs:
>
> vv009-4kfft.grc 27.588664 Mbps
>
> vv010-2kfft.grc 14.364704 Mbps
>
> vv011-1kfft.grc 6.169662 Mbps
>
> If your receiver allows it, you can also use smaller channel bandwidths
> such as 5, 6, or 7 MHz. The bitrate will be scaled accordingly.
>
> The DVB-T2 bitrate calculator is here.
>
> https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c
>
> Ron
> On 9/29/24 22:30, Ali G. Dezfuli wrote:
>
> When I run dvbt2 transmitter examples from gr-dtv without any hardware,
> “Probe Rate” block in GRC shows 15e6 samples per second at the output of
> the Tx (which needs about 9 Msps to work in real-time.)
> Next, I connected USRP B200mini, but it showed underruns.
> Talking to the community, they said UHD is heavy and suggested other SDR
> modules like LimeSDR.
> But the problem still exists using LimeSDR-USB!
> I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with other
> blocks.
> Details:
> HW: Orange Pi 5 plus (32GB)
> OS: Ubuntu 22.04
> GR: v3.10.11.0
>
> Thanks!
>
>

Re: unable to execute new installation

[Volker Schroer]

There is a typo in #7513, the correct fix is #7514

> Am 30.09.2024 um 18:28 schrieb Elmore Family :
> 
> Thanks for the info Chris.
> 
> Now my result is as follows: (Note: the only change is in the last 2 lines of 
> the message)
> 
> Running from source tree
> Could not retrieve GNU Radio configuration directory from GNU Radio. Trying 
> defaults.
> Could not retrieve GNU Radio persistent state directory from GNU Radio. 
> Trying defaults.
> Traceback (most recent call last):
> File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
>   from gnuradio.gr import paths
> ImportError: cannot import name 'paths' from 'gnuradio.gr' 
> (/usr/lib/python3/dist-packages/gnuradio/gr/__init__.py)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
> File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in 
>   run_main()
> File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in run_main
>   sys.exit(main())
> File "/home/pi/gnuradio/grc/main.py", line 297, in main
>   log_file = os.path.join(get_state_directory(), "grc.log")
> File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>   f"files to '{xdgand}'.")
> NameError: name 'xdgand' is not defined
> 
> Jim
> 
> -Original Message- From: Chris Gorman
> Sent: Monday, September 30, 2024 9:07 AM
> To: Elmore Family
> Cc: GNURadio Discussion List ; Volker Schroer
> Subject: Re: unable to execute new installation
> 
> Hello Jim,
> 
> Volker is referring to a github pull request (bug fix).  You can find
> his bug report number 7513 at
> https://github.com/gnuradio/gnuradio/pull/7513 .
> 
> Best regards,
> 
> Chris
> 
> 
> 
>> On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:
>> 
>> What does 7513 refer to? How do I find it?
>> 
>> -Original Message-
>> From: Volker Schroer
>> Sent: Saturday, September 28, 2024 11:22 AM
>> To: GNURadio Discussion List
>> Subject: Re: unable to execute new installation
>> 
>> Please stay on the list.
>> 
>> 
>> First:
>> 
>>  File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>> f"files to '{newpath}'.")
>> UnboundLocalError: local variable 'newpath' referenced before assignment
>> 
>> is definitely a bug in the python code.
>> 
>> I proposed a fix. See #7513 on github.
>> 
>> This pr may not fix the reason of your problems, but you should get a
>> better error message.
>> 
>> What is the result of
>> 
>> gnuradio-config-info --prefix
>> 
>> Why do you start gnuradio-companion from the source tree and not from
>> the install directory?
>> 
>> 
>> Am 28.09.24 um 15:06 schrieb Elmore’s:
>> > I did perform the install command and I thought it worked. You also say
>> > this is a bug. Thus I am confused.
>> > Sent from my iPhone
>> 
>> 
>> 
>> --
>> This email has been checked for viruses by AVG antivirus software.
>> www.avg.com
>> 
>> 
> 
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com