Four Channel Frequency Detection, Suggestions Please.

Status
Not open for further replies.
I am creating an instrument with four strings and I would like to detect the frequency of the note being played on each individual string using four separate pickup coils. I am looking for high accuracy and quick response as the strings will be auto-tuning based on the detected frequency. I am unsure of an acceptable sample rate as the auto-tuning has not been implemented yet.

Below are two options I currently envision, but would like to hear the community thoughts on if there are better approaches or the best of the two in terms of sample rate and accuracy. I am also balancing my time and lack of interest of implementing algorithms from scratch.

4x ATmega328P and 4x LM386 with the arduinoFFT library connected to a master MCU via SPI.
(I tested a single implementation and it works with my pickup, but a 64ms sample rate might be slow and from reading the forums the arduinoFFT has a limited accuracy of about 2.5hz (unconfirmed))

2x Teensy 3.2 using adcs and notefreq (using the YIN algorithm which was Paul suggests is better for instrument frequency detection over FFT) connected together via UART or SPI. The YIN algorithm appears to be very accurate from the tuba recording tests that were posted a while back. (Edit: The running example is promising, but there are some odd reading patterns. But they might be cause by an improperly bias input).

Thanks.
 
Last edited:
Last time I tested, YIN used nearly all the CPU power of Teensy 3.2, just to analyze a single audio channel. To run 4 channels concurrently, you're probably going to need the CPU power of Teensy 4.0.

So far, ADC input isn't supported on Teensy 4.0, so you'll need the audio shield. Quad I2S is also not yet supported on Teensy 4.0, but I2S2 is. To use 2 audio shields to get 4 signal inputs, you'll need to route the I2S signals to I2S2 on the 2nd audio shield.

YIN does have some latency. There may be some parameters you can edit within the code, but don't expect miracles (though YIN is already pretty miraculous at finding the fundamental when you have strong overtones).
 
I have a newer version (https://github.com/duff2013/AudioTuner) than the stock Teensy one that can reduce the cpu load by resampling the input signal at a lower sample rate and low pass filter (FIR) that signal for aliasing. This is done by CMSIS decimate function which has a FIR filter input built in to it with the default coefficients in the examples worked but are less than ideal. The only code difference is that in the begin function you have to add the FIR filter coefficients, size of filter (must be even) and decimation factor which is the ratio of Audio library sample divided by the decimation sample rate so for example you use ~22050Hz sampling rate the factor would be 2 as seen in the examples. If you lower the sampling to 11025Hz decimation factor would be 4 i.e.(~44100/11025).

Depending on your frequency range, specifically the lowest frequency you plan to monitor you can change the number of incoming Audio Blocks being used which will speed up the algorithm if you use a lower number.

These speedups come with disadvantages though in that lowering the sample rate (decimate) in the algorithm you lose some information and the FIR size will increase the cpu load if you use a lot of coefficients.
 
Status
Not open for further replies.
Back
Top