Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: Discontinuous audio FFT processing using Teensy 3.1

  1. #1
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35

    Discontinuous audio FFT processing using Teensy 3.1

    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 by randomrichard; 03-24-2015 at 11:09 PM.

  2. #2
    Senior Member
    Join Date
    Jan 2015
    Location
    frisia
    Posts
    285
    I would go for an ofline fft, without the audio library. For a starter, maybe the hints in my post in this thread will help
    https://forum.pjrc.com/threads/28035...ll=1#post67587

    Another example in this thread, where an fft is used for crosscorrelation. This might come a bit closer, since you mention convolution.

    What do you mean by
    changing the windowed operation for a discrete one
    Last edited by kpc; 03-24-2015 at 11:46 PM.

  3. #3
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35
    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.

  4. #4
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35
    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[i] = 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 by randomrichard; 03-26-2015 at 03:53 PM.

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,709
    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.

  6. #6
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35
    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:
    Click image for larger version. 

Name:	TFFT.JPG 
Views:	162 
Size:	88.7 KB 
ID:	3970

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,709
    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.

  8. #8
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35
    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 by randomrichard; 03-26-2015 at 09:21 PM.

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,709
    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.

  10. #10
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35
    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

  11. #11
    Member randomrichard's Avatar
    Join Date
    Feb 2015
    Location
    UK
    Posts
    35

    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:dacChirper.ino, which is supposed to receive a file from the PC using this VB code:Click image for larger version. 

Name:	VB.JPG 
Views:	90 
Size:	46.5 KB 
ID:	6418. 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.

  12. #12
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    Quote Originally Posted by randomrichard View Post
    Has anyone succeeded in sending a substantial numerical file to (not from!) the Teensy? I can find no example in the forum.
    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...l_receive.html

  13. #13
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    - Is the file you are sending ASCII ?
    - a crash means that you have a bug in your code.

    show us your code.

    inputs transferred to ARM memory only as C++ *.h files,
    ??? No.!!

  14. #14
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    ...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 by Frank B; 02-20-2016 at 12:03 AM.

  15. #15
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    ...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 ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •