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
<patchvonbr...@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
<patchvonbr...@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
<nbalka...@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-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
