usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsfc64 help needed
Hi all,
I recently changed my host application to complex double. I had to change
my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I have
only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void buffer
pointer to
skip the sse2 code?
TIA
Nikos
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com wrote:
Hi all,
I recently changed my host application to complex double. I had to change
my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I have
only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void buffer
pointer to
skip the sse2 code?
TIA
Nikos
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision float
has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from
the ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to
change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it,
I have only 1196 maxsamples, and crashes. I don't need the sse2
code for my conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void
buffer pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet() where
b was evaluated to nil and therefore out_buffs were allocated to nil. It
would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision float
has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from the
ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to change
my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I have
only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void buffer
pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet()
where
b was evaluated to nil and therefore out_buffs were allocated to nil.
It would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio uses
it. FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech
patchvonbraun@gmail.com wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should *Just work*.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to
the output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision
float has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming
from the ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're
just slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas
<nbalkanas@gmail.com> wrote:
Hi all,
I recently changed my host application to complex double. I
had to change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as
before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't
like it, I have only 1196 maxsamples, and crashes. I don't
need the sse2 code for my conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the
void buffer pointer to
skip the sse2 code?
TIA
Nikos
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Yes it is, But input is always double:(
BR
Nikos
On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet()
where
b was evaluated to nil and therefore out_buffs were allocated to nil. It
would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio uses it.
FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision float
has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from the
ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to
change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I
have only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void
buffer pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 11/05/2025 22:45, Nikos Balkanas wrote:
Yes it is, But input is always double:(
BR
Nikos
Nope.
https://www.fftw.org/fftw3_doc/Precision.html
The FFTW3F routines used in Gnu Radio take in single-precision (32-bit)
and output single-precision (32-bit). In most CPUs,
the 64-bit floating-point pathways are slower than 32-bit pathways,
which is why FFTW3 has a version of the libraries that
process single-precision floating-point exclusively. This has been
true literally for at least two decades of FFTW3, since I
started using and contributing to Gnu Radio in 2004.
Anyway, it's entirely up to you, but there's really no reason to use
double-precision floats to process data that on the
wire are only 16 bits.
On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech
patchvonbraun@gmail.com wrote:
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach
the _recv_one_packet() where
b was evaluated to nil and therefore out_buffs were allocated to
nil. It would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio
uses it. FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech
<patchvonbraun@gmail.com> wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2
code:(
After commenting it out, uhd still crashes. The conversion
output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should *Just work*.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex
floats to the output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even
single-precision float has more precision and dynamic range
than is
actually represented by the 16-bit values on the wire,
coming from the ADCs. By moving to double-precision,
unless you
have a library that only supports double-precision math,
you're just slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas
<nbalkanas@gmail.com> wrote:
Hi all,
I recently changed my host application to complex
double. I had to change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv
same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts
doesn't like it, I have only 1196 maxsamples, and
crashes. I don't need the sse2 code for my conversion. I
only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can
pass the void buffer pointer to
skip the sse2 code?
TIA
Nikos
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Thx.I will check it:)
On Mon, May 12, 2025 at 5:53 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:45, Nikos Balkanas wrote:
Yes it is, But input is always double:(
BR
Nikos
Nope.
https://www.fftw.org/fftw3_doc/Precision.html
The FFTW3F routines used in Gnu Radio take in single-precision (32-bit)
and output single-precision (32-bit). In most CPUs,
the 64-bit floating-point pathways are slower than 32-bit pathways,
which is why FFTW3 has a version of the libraries that
process single-precision floating-point exclusively. This has been true
literally for at least two decades of FFTW3, since I
started using and contributing to Gnu Radio in 2004.
Anyway, it's entirely up to you, but there's really no reason to use
double-precision floats to process data that on the
wire are only 16 bits.
On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet()
where
b was evaluated to nil and therefore out_buffs were allocated to nil. It
would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio uses it.
FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision float
has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from the
ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to
change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I
have only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void
buffer pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
You are right. fftw says that in float precision, it accepts float inputs
to the API.
I assume they mean the libfftwf.so library and the fftwf_* API.
I didn't specify precision in my build. So I got libfftw.so (as opposed to
libfftwf.so or libfftwl.so).
This simplified Makefiles and source code:) I/O with fftw_complex is still
16 B.
A quick and dirty test with libfftw3.so and complexf I/O resulted with
memory corruption.
I'll have to investigate this better and use the libfftwf.so library and
fftwf api, when I have more time.
I will update this thread when I do:)
Thx again,
Nikos
On Mon, May 12, 2025 at 6:10 AM Nikos Balkanas nbalkanas@gmail.com wrote:
Thx.I will check it:)
On Mon, May 12, 2025 at 5:53 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:45, Nikos Balkanas wrote:
Yes it is, But input is always double:(
BR
Nikos
Nope.
https://www.fftw.org/fftw3_doc/Precision.html
The FFTW3F routines used in Gnu Radio take in single-precision (32-bit)
and output single-precision (32-bit). In most CPUs,
the 64-bit floating-point pathways are slower than 32-bit pathways,
which is why FFTW3 has a version of the libraries that
process single-precision floating-point exclusively. This has been
true literally for at least two decades of FFTW3, since I
started using and contributing to Gnu Radio in 2004.
Anyway, it's entirely up to you, but there's really no reason to use
double-precision floats to process data that on the
wire are only 16 bits.
On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet()
where
b was evaluated to nil and therefore out_buffs were allocated to nil. It
would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio uses
it. FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision float
has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from
the ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to
change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I
have only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void
buffer pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Dear Marcus,
I updated my Makefiles and sources to work with libfftw3f.so API and
fftwf_complex (from fftw3.h)
Default fftw3 installation with no subscripts is for double, fftw3l is for
long double and fftw3f is for float:)
Rescaning 1000 targets from saved packets in the filesystem (no usrp):
fftw3: 31 ms
fftw3f: 19 ms
Time includes the fs I/O to read ~8 MB same for both cases. cpu benefit is
clear and always reproducible.
Things are not as reproducible or clear with live signals. Additional
benefit to uhd for shorter conversions.
fftw3: 3.298 s 18 detections
fftw3f: 3.279 s 18 detections
I will keep the float fftwf version.
HTH
Nikos
On Mon, May 12, 2025 at 6:57 AM Nikos Balkanas nbalkanas@gmail.com wrote:
You are right. fftw says that in float precision, it accepts float inputs
to the API.
I assume they mean the libfftwf.so library and the fftwf_* API.
I didn't specify precision in my build. So I got libfftw.so (as opposed to
libfftwf.so or libfftwl.so).
This simplified Makefiles and source code:) I/O with fftw_complex is
still 16 B.
A quick and dirty test with libfftw3.so and complexf I/O resulted with
memory corruption.
I'll have to investigate this better and use the libfftwf.so library and
fftwf api, when I have more time.
I will update this thread when I do:)
Thx again,
Nikos
On Mon, May 12, 2025 at 6:10 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Thx.I will check it:)
On Mon, May 12, 2025 at 5:53 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:45, Nikos Balkanas wrote:
Yes it is, But input is always double:(
BR
Nikos
Nope.
https://www.fftw.org/fftw3_doc/Precision.html
The FFTW3F routines used in Gnu Radio take in single-precision (32-bit)
and output single-precision (32-bit). In most CPUs,
the 64-bit floating-point pathways are slower than 32-bit pathways,
which is why FFTW3 has a version of the libraries that
process single-precision floating-point exclusively. This has been
true literally for at least two decades of FFTW3, since I
started using and contributing to Gnu Radio in 2004.
Anyway, it's entirely up to you, but there's really no reason to use
double-precision floats to process data that on the
wire are only 16 bits.
On Mon, May 12, 2025 at 5:38 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 11/05/2025 22:27, Nikos Balkanas wrote:
Thx Marcus,
I worked it out 2 days ago. Just my memory allocation.
I am passing input buffer with a global pointer.
I was using global stack allocation. When I switched to
malloc, it just works fine:)
Here is what happened: Input buffs didn't reach the _recv_one_packet()
where
b was evaluated to nil and therefore out_buffs were allocated to nil.
It would be helpful
to check allocations like these and issue a warning.
Input, however, still reached the convert_chdr_1_to_fc64_1_guts but
outputs and therefore output were evaluated to NULL.
With NULL output it was sent through the guts function.
Even commenting out the switch and sending it through
the generic chdr_sc16_to_xx crashed it with no output buffers:(
I am not quite sure why b is not evaluated in _recv_one_packet()
and is available downstream in convert_chdr_1_to_fc64_1_guts
with a global stack allocation. Unstable code?
Anyway, I need the complex double for libfftw3. Its
input data is (fftw_complex) aka 16 B, no matter
what precision I use. It comes out in float, long double
and quad flavors, but input is the same.
And it blows Opencl fft I was using by 10x!
on the filesystem, less with live signals,
but still faster:) And signal power is hotter:)
BR
Nikos
FFTW3 is available in a single-precision instance -- Gnu Radio uses
it. FFTW3F.
On Mon, May 12, 2025 at 4:24 AM Marcus D. Leech <
patchvonbraun@gmail.com> wrote:
On 10/05/2025 07:17, Nikos Balkanas wrote:
It turns out that the problem is not just bypassing the sse2 code:(
After commenting it out, uhd still crashes. The conversion output
buffers are not created in _recv_one_packet()
Any ideas why they don't?
TIA
Nikos
This should Just work.
What happens if you use rx_samples_to_file and specify:
--type double
This should write out double-precision (64-bit) complex floats to the
output file. You should be able to use that example
code as a bit of a template.
Also, I have to ask, why double precision? Even single-precision
float has more precision and dynamic range than is
actually represented by the 16-bit values on the wire, coming from
the ADCs. By moving to double-precision, unless you
have a library that only supports double-precision math, you're just
slowing down your computations for no good reason.
On Sat, May 10, 2025 at 7:56 AM Nikos Balkanas nbalkanas@gmail.com
wrote:
Hi all,
I recently changed my host application to complex double. I had to
change my stream_args to
fc64. I pass my void pointer to uhd_rx_streamer_recv same as before:
ptr = (void **)&zin;
Unfortunately, the convert_chdr_1_to_fc64_1_guts doesn't like it, I
have only 1196 maxsamples, and crashes. I don't need the sse2 code for my
conversion. I only use 1024 complex
samples/packet for fft. I am very happy with the
generic chdr_sc16_to_xx.
Does anyone have any fc64 experience and how one can pass the void
buffer pointer to
skip the sse2 code?
TIA
Nikos
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com