Discontinuous audio FFT processing using Teensy 3.1

Status
Not open for further replies.
randomrichard

randomrichard

Active member
I have used VB FFT deconvolution code from S W Smith's marvellous "Digital Signal Processing" book to process 1024 sample chunks of geophysical data and would like to transfer this function to the Teensy 3.1. Each sample chunk is obtained at intervals of between 0.25 and 5 seconds. The processing extracts timed events, such as acoustic echoes, that are saved for further analysis. I would be grateful to hear if anyone has modified the audio FFT example provided with Teensyduino by changing the windowed operation for a discrete one. I imagine it would be straightforward but am not sure at what coding level I should modify the program, whether in the analyse_fft1024.cpp file, or elsewhere.
 
Last edited:
Last edited:
Thanks for the advice, which I will pursue. My algorithm is in fact cross-correlation. It's nearly identical to convolution except for some data flipping. The system uses a shaped "chirp" output and correlates this chirp with returning signals to extract the times at which a facsimile of the chirp is seen. The output is sent about every second (0.25-5s) as the system moves across the ground. So the processing happens on discrete chunks of data rather than on continuously-updated windows, as in music. The ideal output is a set of timed delta functions giving the time/distance, and amplitude, of event targets. The processing load is obviously far less than with music. Similar systems are used in various devices; seismic survey systems, sidescan sonars, fishfinders, medical, etc.
 
What a great bit of kit! I have the following solution to my question for anybody out there with a similar need. Having set FFT up for microphone i.e. analog input, adding an int val[1024]; line, and adding a Serial.begin(9600); line in setup so I could upload to my PC, I revised the loop as follows below to give individual lines of data suitable for further DSP - which is where it gets interesting...

void loop()
{
delay(shotInterval);

if (myFFT.available()) {

for (int i=0; i<512; i++) // i defines number of bins output
{
val = int(myFFT.read(i) * 1000); // multiplier to give sufficient precision
}
for (int j=0; j<512; j++)
{
Serial.print(val[j], DEC);
Serial.print(" ");
}
Serial.println();
}
}
 
Last edited:
rrichard - wondering if you can post your full sketch? I'm not sure how similar your case is to my needs - but would like to see how you set up for the FFT to supply data.
 
Hi, I was a bit shy about printing the whole thing - it's more or less unchanged from the program provided by pjrc and I still have significant issues to resolve, mostly as to whether I can operate without array storage, at least until, the transmission to the PC. But I was surprised to find that recording just one set of bins every second or so was perfectly synchronised - no dropped data. Here it is:
TFFT.JPG
 
Thanks, I'm looking for a modified version that fits my setup. Looks like you have the mic coming in through the sound card - that I don't use. I thought you were manually feeding the data in to the FFT blocks and getting it to work on that data.

I'm looking for shorter sample times and not putting any more CPU work into the FFT than I need - but dropping to 256 means I need to drop the sample rate for equal accuracy - which of course extends the sample time in direct proportion. In order to do both I'd need to find a way to PREP the data before the FFT starts and alter the sample rate to have the faster return of the FFT_256 w/ wait for fewer samples and less math.

My thought is going to 8k sample rate and FFT_256 and maybe using the last 128 samples to start the next set of 256. This would be a real discontinuity to the Audio style continuous process. My 256_FFT's would be done twice as fast - have a smaller freq range, but the net Hz/bin up to 4k should give me what I need to find a few key fast acting sound events that I'll need to get best pinpoint of timing on I can. I could use the ADC LIB sampling to get my own data, but haven't seen how to have the FFT run on that data yet.
 
I've just realized that FFT doesn't give a complex number output, which is required by my correlation algorithm. It looks like your application may not have this problem. I may just have to write my own FFT/correlation code for Teensy 3.1 as a Teensyduino sketch; slow maybe, but I have loads of time. And I've just discovered that kpc's first ref, above, shows the way. Thanks kpc!
 
Last edited:
I found Real vs. complex FFT - that suggests part of the kpc optimization involves "using a complex fft for two real fft's simultaneously" to make it real only. On that page I found this link to other FFT sources So indeed you won't have a final complex FFT from this.

Indeed if I can get the samples taken quickly and FFT processed to get the freq distribution my testing so far suggests I'll have what I need in 'real terms' from the great and powerful Teensy.
 
Thank you so much, kpc, for the cross correlation code referred to in your reply to me on the 25th. After a steep learning curve I have finally done the obvious and installed your excellent code, which works!
Richard
 
Importing multiline integer files from PC to Teensy3.1

After several months investigating the Audio board I have realized that it has limited scope; 44.1ksps, inputs transferred to ARM memory only as C++ *.h files, focus on music.

I need to be able to upload chirp files sampled at arbitrary frequencies, say 10ksps, to perform FFT correlation with the code discussed above and have found no relevant examples to work on. It is vital for the correlation algorithm that the (anti)chirp used is identical to the audio chirp outputted by the Teensy, probably via the 12bit DAC, not the Audio Board. The nearest example to my need is the Communication\Serial Event, which I have modified to read a 1024 line file of unsigned 12bit numbers (e.g. 2175). Here is the, as yet incomplete, code I am trying to use:View attachment dacChirper.ino, which is supposed to receive a file from the PC using this VB code:VB.JPG. The VB sends a few hundred lines of file but then crashes, presumably because the Teensy's buffer is full (?). However, I have assigned plenty of buffer space without changing the crash mode. Has anyone succeeded in sending a substantial numerical file to (not from!) the Teensy? I can find no example in the forum.
 
randomrichard said:
Has anyone succeeded in sending a substantial numerical file to (not from!) the Teensy? I can find no example in the forum.
Click to expand...

Well, I can tell you many thousands of people have used the VideoDisplay example in OctoWS2811, which transmits 30 or 60 images per second from a PC to Teensy. That's packed binary data, not text, so not exactly the same thing. But if you're looking for a confirmation Teensy can receive large amount of data, OctoWS2811 would be a pretty good example.

This benchmark program sends data to Teensy also. Might be worth trying.

http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html
 
...just tested your sketch from above and sent a 500kb textfile to it (with a terminal-program "hterm"). Works fine.
Where can i find the "crashing" sketch ?

You're sending the received text back.... do you ever read the incoming data on the pc ? i can't see anything like that on your screenshot.
 
Last edited:
...you know that a newline on windows is two characters: LF+CR (\n\r) ?
you're checking \n only..perhaps you're interpreting some wrong ?
 
Status
Not open for further replies.
Back
Top