I thought (without really confirming this) that the rpi zero is 32 bit and hence it will work much faster with single precision math hence decided on single precision fft?
The fftw? library didn't build the single precision directly, you had to first build the double precision version and then build the single precision, hence the mixup.
With RPI, now that the GPU FFT library is available, the proper thing to do would be to use that, I saw someone had written a wrapper around it to be a drop-in replacement for the fftw. This will shave off many cycles from the cpu consumption.
Interestingly, I ran gprof on sbitx, the timr spent on fftw is minor. Most of the cpu cycles were spent in other loops in rx_process that copy samples and bins around. There must be some DMA kind of a way to do this.
On Sun, Oct 22, 2023, 1:09 AM Mark Erbaugh <mark.election@...> wrote:
I noticed that the stock firmware uses both the standard (double) and float FFTW3 libraries. The install instructions have you build both library versions. It looks like the float libraries are only used in fft_filter.c, the standard libraries are used elsewhere. Is there a reason that fft_filter.c doesn't use the standard library?
FWIW, I modifed the code to use the standard library in fft_filter and build the program with just the standard library and everything seemed to work.
Then, I changed all the code to use just the float library. It seems to work also and at least on receive (I haven't tried transmit), it seems to sound fine. Does the program need the precision of the standard library? Does using the float library speed up the FFT process? -- 73, Mark, N8ME
