akellyirl / autocorr_freq_detect

An Arduino example of Autocorrelation for the detection of signal frequency

AutoCorr_Freq_detect

An Arduino example of Autocorrelation for the detection of signal frequency

Accurate Frequency Detection is important for many projects such as Guitar/Piano Tuners, Vibration Analyzers, Heartrate Monitors, MEMs Sensor Analysis and Laboratory Instruments. There have been many fine examples of projects that try to solve this problem but they all use Time Domain techniques; analyzing the signal for features such as : Zero-Crossings, Peak Detection, Slope Detection etc..

A Piano playing Middle-C (C4) looks very different from a Synthesizer Playing Middle-C (C4). Any good Time Domain algorithm will work well with the Piano waveform. But the Synthesizer waveform will not be identifiable that way because its very strong harmonic content makes the fundamental frequency undiscernable . It looks impossible to Identify the Frequency of this signal.

It is possible.

Using Autocorrelation it was measured to be 259.91Hz ... only 0.09Hz away from an Exact Middle C Frequency of 260Hz.

See more here: http://www.akellyirl.com/reliable-frequency-detection-using-dsp-techniques/

autocorr_freq_detect's Issues

Lower frequency coverage

Hello

I'd like to extend the low frequency capabilities to make this code useful for seismic projects, and changed the LENGTH to 1024, this allowed frequencies down to 18Hz before stopping. I'm unsure if there is another way to achieve this? Ideally I'd like to detect from (say) 5Hz upwards, frequencies higher than 1kHz have no real application for me.

Look forward to any thoughts.

Kind regards

T

Optimization ideas

I just came across this code and thought it really cool and found it to work on my 32 bit STM32L4 processor as written against the provided sample data files.

I wondered how fast it was and surprised to see on the 80 MHz processor it took 144ms to find the answer. Then I noticed the nested loop is running n-Squared across the whole sound sample! I can't guess how long it would take on an 8 bit 16 MHz - running the STM32 at 24 MHz the code takes 354 ms on the on sample.

Looking at optimizations I found two things the first biggest thing is to remove the "/256" division as the sum is accumulated. This results in the same answer as the intermediate result is changed in magnitude but returns the same calculation in the end for "freq_per=" and takes about 40% less time at 100 ms:
for(k=0; k < len-i; k++) sum += (rawData[k]-128)*(rawData[k+i]-128); // REMOVE THIS :: /256;

The second thing involves the repeated '-128' on that same line, as it is done on both values each time. On my STM32 I have enough RAM that I did this before entering the existing "for(i = 0" loop:

int16_t summs[sizeof(rawData)];
for (k = 0; k < len; k++) summs[k] = rawData[k] - 128; // x32 device works best with int16

Then the 144 ms becomes 65 ms when I use this modified line as the inner loop:
for (k = 0; k < len - i; k++) sum += ( summs[k] * summs[k + i] );

If RAM is too short for that second array the original can be modified like this before the "for(i = 0" loop:
int8_t *SrawData = (int8_t *)rawData;
for (k = 0; k < len; k++) SrawData[k] = rawData[k] - 128;

Then using this inner loop - which is not optimal on a 32 bit processor but should work well on an 8 bit processor:
for (k = 0; k < len - i; k++) sum += ( SrawData[k] * SrawData[k + i] );