# pocketfft delivers wrong values

does anyone understand how to use the pocketfft by martin reinecke?

Basically it's just this snipped of code:

rfft_forward(rfft_plan plan, double c[], double fct);

I understood,

1. that the plan needs to be created to the "internal" planning of the algorithm,

2. the array c[] is input data and will be overwritten with output data, but what stands the double fct for?

I recorded some data with my embededd system (STM32f446RE with a sensor) and did a reference fft in python ( that one works ) which differs alot from the pocketfft and I dont understand why

Is my code maybe wrong somehow?

double resultD[SIZE];
for (i=0; i < SIZE; i++){
resultD[i] = (double)result[i][1];
}

rfft_plan plan = make_rfft_plan(SIZE);
rfft_forward(plan, resultD, 1.);
destroy_rfft_plan(plan);

n = sprintf( buffer, "%s\n", "X" );
HAL_UART_Transmit(&huart2, buffer, n, 1000);

for(i = 0; i < SIZE; i++) {
n = sprintf( buffer, "%f\n", resultD[i] );
HAL_UART_Transmit(&huart2, buffer, n, 1000);
}



In blue u can see the reference fft with python, in red the fft from the µC and the code above.

It differs in amplitude and it's shifted.

Therefor I think it's not about just a scaling factor

• Thanks for adding the plot (please add it to your question by editing your question next time; it's not an "answer"). It looks like the Python (blue) plot is using an FFT size twice the length of the pocketfft one. Try changing rfft_plan plan = make_rfft_plan(SIZE); to rfft_plan plan = make_rfft_plan(2*SIZE); and see if they better align.
– Peter K.
Aug 1, 2022 at 15:24
• unfortunately playing with rfft_plan plan = make_rfft_plan(2*SIZE); did not help here. Is it maybe possible that two different ffts deliver such different results?
– jp21
Aug 2, 2022 at 6:40

I'm the author of pocketfft. The fct parameter is simply a factor which is multiplied to the result of the transform call. You can use this to get normalized transforms (pocketfft will do unnormalized transforms if you use fct=1).

Concerning the results: the output format of pocketfft's rfft_forward call is a specific "half-complex" format which can be difficult to interpret. If you show me the part of the code that computes the Python reference FFT, I should be able to describe how the results can be matched.

Hello Martin Reinecke,

I have the same issue as jp21. The results of my fft with pocketfft differs from what i found in matlab. I am using:

double result_double[2*N];

cfft_plan plan = make_cfft_plan(N);

cfft_forward (plan, result_double, 1.);

destroy_cfft_plan (plan);


from the result_double, how to extract the N real points and the N imaginary points?