ApproxFFT() in the RAK18032 WisBlock audio ultrasonic microphone module

Hi everyone,
At present, we are using RAK19001(Wisblock Base) + RAK4630(Wisblock Core) + RAK18032(Wisblock) Sensor) run HighRatePDMSerialPlotterFFT. Ino code met questions about sample point selection.
From the ApproxFFT’s official documentation, we know that ideally, it would be 2^n, which could be 2, 4, 8, 16, 32, 64, 128,… However, the maximum number of samples is limited by available memory.For Arduino nano, FFT of more than 256 sample not possible due to mamory limitation.The memory of Arduino nano is 2KB, while the MCU memory used by RAK4630 is 256KB. Through the process of increasing the sampling points successively, we found that when the sampling points were 2048, the program card would not run.
We just want to confirm whether it’s because of the RAK4630 memory that we can only handle the ApproxFFT with a maximum sample point of 1024 or is it because of something else? If there are other reasons, how should the corresponding ApproxFFT code be changed?

Hi,

What have you changed in the example code to modify the number of sample points?
(I have not done this and want to be sure my change is the same as yours).

Also - what is the sample rate you are trying to use?

Firstly, we modified the BUFFER_SIZE in the int approxBuffer[BUFFER_SIZE]; code section of the HighRatePDMSerialPlotterFFT.ino file. The BUFFER_SIZE macro definition variable exists in the audio.h file of the RAKwireless-Audio-library. Secondly, we adjusted the RAW_BUFFER_SIZE macro definition in the PDM.cpp file. The sampling rate we used is 100 kHz.

Thanks for sharing the changes you made.
If you increased the buffer size, but run at lower frequency (eg 48kHz) does it work for you? The reason I ask is that we have been looking into a problem at 100 kHz which may be the actual problem you are seeing.

We reduced the sample rate(eg 48kHz, 16kHz) , imported the code into rak4630, and the program was still stuck, which didn’t work very well.

Thanks - I have reproduced the problem you are seeing and we are looking into it.
Are you able to use a sample size of 1024 and a rate of 48kHz while we investigate a buffer of 2048 and a rate of 100kHz?

Thank you for your continued attention to this issue. The 1024 sample size and 48kHz rate can be used normally, and there is no program jam phenomenon, and the data can be printed normally.