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
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
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
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/st
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 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
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
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
>
> 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 instructio
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.
ht
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
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 larg
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
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?
>
> -Ori
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
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 un
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
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 confi
18 matches
Mail list logo
