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
