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.
I wanted to let you know that we have been able to get 100kHz working. I have tested it as best as I can, but don’t have a speaker for the higher frequencies. (it recognizes them, but I’m not certain on the frequency measurement)
We are currently working out how to best this released the changes (not sure how long this will take us).
Problem solving this is a good thing. Here is the RAK18032 ultrasonic sensor that confirms the 100kHz sampling rate can perform FFT calculation of more than 1024 sampling points in the rak4630 chip, right? We would like to know, is the FFT calculation software mainly changed here？
Hi,Where did the main.cpp shown in your picture come from? What functions does it mainly implement? Here I only have the FFT code and some corresponding library files. If it’s convenient for you, could you please package the entire code for us to verify?
Hi,
We are working on releasing the update, but are investigating the higher clock rate failure (higher than 100kHz) before we release it.
main.cpp is in the main nrf52 library:
/Arduino15/packages/rakwireless/hardware/nrf52xx/1.3.3/cores/nRF5