Ideas? Detecting a narrow frequency within an audio signal

Hi Gordon,

Why not use a microcontroller with an ADC for this? On this website⇒ http://www.earlevel.com/main/2012/11/26/biquad-c-source-code/ , and this nice widget Biquad calculator v2 | EarLevel Engineering you can find C code for a simple biquad filter, and you can also make a tunable notch with that. If you're using an arm core you can even use the CMSIS-DSP blocks for biquads.

This solution will be quite cheap, and very tunable.

Hi vslluiter,

Thank-you for pointing to biquad filters and for providing the good resourse links. This seems like a very good place for me to start. Because I am already familiar with analog circuitry, I was thinking in those terms, but I see that the microprocessor-based approach offers many benefits to the application, first of which is simpler electronic fabrication. I am new to DSP so I will have a bit of a learning curve ahead of me!

Thanks again, super helpful.

cheers,

Gordon

Play with the link that V sent by all means (its a good start) but you may have some problems because the example code there is done using double length floats which will be somewhere between slow and dead slow on a low cost micro. (If you can stretch to an ARM Cortex M4 then you'll be OK. ARM have a free DSP library you can use.)

If the basic idea seems to be working for you then the next step is to implement the filters in fixed point if you can't afford an M4 - it's perfectly doable but harder to find example code.

And of course if you only need one filter running with a reasonable sample rate you may get away with doubles even on an M3 clocked at a meager 24Mhz.

If you do need to use fixed point then let us know and I'll give you an example.

MK

Play with the link that V sent by all means (its a good start) but you may have some problems because the example code there is done using double length floats which will be somewhere between slow and dead slow on a low cost micro. (If you can stretch to an ARM Cortex M4 then you'll be OK. ARM have a free DSP library you can use.)

If the basic idea seems to be working for you then the next step is to implement the filters in fixed point if you can't afford an M4 - it's perfectly doable but harder to find example code.

And of course if you only need one filter running with a reasonable sample rate you may get away with doubles even on an M3 clocked at a meager 24Mhz.

If you do need to use fixed point then let us know and I'll give you an example.

MK

I'm definitely familiar with the challenges of floating point ops on a low cost microprocessor. One simplification I am considering is keeping the sample rate low. If I can keep my max frequency under 1000 hz, then I should be able to sample at 2000 hz, correct?

I'll look into ARM Cortex M4. Right now any of the ARM Core processors are new territory for me. Do you think M0 might be feasible?

Thanks again!

Gordon

Oversampling by only a factor of two won't work, for two reasons (or pedantically three).

Pedantic first  - if you oversample by a factor of two it will take you an infinite time to resolve the signal, so you need to oversample by 2 and bit.

In reality the bit needs to be quite big or you get bitten by the need for an amazingly good anti-alias filter and the numbers in any digital signal processing will often be com very ill-conditioned so the filters (even digital ones) won't be stable.

Go for oversampling by a factor of 10 for starters, then you'll need an active filter before the micro's adc which is flat to 1kHz and -at least 50dB by 5kHz - about 20dB per octave so a 4 pole filter will do it.

Lets assume each of your bandpass filters is 4th order so it needs 6 multiplies and 4 adds per sample, and 5 bands at once makes 30 multiplies and 20 adds = 300k per second.

I've just done some code that does 160k 4th order filters per second  = 640k filter orders per second (new unit of measure just invented here !) compared with the 200k you need. My code runs on a STM32F103xx at 72MHz and only gets a bit less than 50% of the processor, ST do M0s which would run at 24MHz and possibly just about cope. (I had to run the filter code from RAM with max compiler optimisation and some coding trickery but still all in C).

If I were you for only 25-100 off I'd use an M3 - about £1 more than an M0 but pin compatible if you ever need to make lots but much higher chance of it all working.

Debugging this stuff is horrible - I started off with a CortexM4 with the maximum possible RAM so I could capture data from it's ADC and experiment with processing it off line.

If you use ST family parts the M0, M3 and M4  are almost pin for pin replacements (you can design a common board where M4s get 2 capacitors instead of shorts).

MK

Michael Kellett wrote:

 

Play with the link that V sent by all means (its a good start) but you may have some problems because the example code there is done using double length floats which will be somewhere between slow and dead slow on a low cost micro. (If you can stretch to an ARM Cortex M4 then you'll be OK. ARM have a free DSP library you can use.)

If the basic idea seems to be working for you then the next step is to implement the filters in fixed point if you can't afford an M4 - it's perfectly doable but harder to find example code.

And of course if you only need one filter running with a reasonable sample rate you may get away with doubles even on an M3 clocked at a meager 24Mhz.

If you do need to use fixed point then let us know and I'll give you an example.

 

MK

Hi Michael,

I've used this approach in a class where we used the KL25Z boards (Cortex-M0, 48MHz). We were processing EMG data, and did 5th order filters in doubles on 4 input channels at 700Hz update rate. So depending on the highest frequency the original poster wants to use, this could be feasible.

The CMSIS-DSP / arm-dsp functions (https://www.keil.com/pack/doc/CMSIS/DSP/html/group___biquad_cascade_d_f1.html) are using floats, and do not provide a way to calculate the coefficients, but you could do that with the calculator on the earlevel website. Do beware that there's no convention on which sign the input- and output coefficients have, and from memory the output-to-summation coefficients are inverted in sign between the Earlevel widget and the CMSIS-DSP implementation.

I like the Earlevel library because you don't have to calculate the coefficients beforehand. If ghicks uses the code he can just as well find-and-replace all doubles for floats. We're not doing any hifi-audio stuff here.

ghicks: if you're starting in the mbed environment (www.mbed.org), you can use the mbed-dsp library (mbed-dsp - a mercurial repository | mbed), which uses the CMSIS-DSP library (confusing!!). Code example below.

michaelkellett: the CMSIS-DSP library also has Q15 and Q31 fixed point implementations. Sweet!

Here's an example of how to use the CMSIS-DSP approach, it's something I built for the classes I gave. You'll have to assign a coefficien array and a memory states array to a filter.

EMG_HIDScope - a mercurial repository | mbed

Michael Kellett wrote:

 

Oversampling by only a factor of two won't work... Go for oversampling by a factor of 10 for starters, then you'll need an active filter before the micro's adc...

 

I've just done some code that does 160k 4th order filters per second  = 640k filter orders per second (new unit of measure just invented here !) compared with the 200k you need. My code runs on a STM32F103xx at 72MHz and only gets a bit less than 50% of the processor, ST do M0s which would run at 24MHz and possibly just about cope... ...If I were you ... I'd use an M3 - about £1 more than an M0...

 

Debugging this stuff is horrible - I started off with a CortexM4 with the maximum possible RAM so I could capture data from it's ADC and experiment with processing it off line.

...

Hi Michael,

Thanks for the clear explanation about the need to oversample... yes, of course the input low-pass filter can't be perfect, I hadn't thought that through. Also thanks for your "filter orders per second" calculation, it gives me a handle on the scale of processing power that is needed. I think I can adjust the parameters of my project to lower the processing load — for example, I may not need to observe five frequencies simultaneously, I can switch between them, like tuning a radio.

I'm not reassured to hear that "debugging this stuff is horrible", but it is good to know what to expect. To this point I've only worked with Atmel AVR processors, so I can see I've got a much to learn just getting to the "Hello World" point with ARM processors.

...Gordon

It's not the fault of the processor that the debugging is hard - the problem is that when you are processing long streams of data the normal debugging tools don't help much. Analog Devices had some nice tools that worked with their DSP chips which enabled you to plot sampled data in little graphs in the debugger in real time but there is nothing like this on micros.

The problem is when you have an event in the data that you would like to detect you can't step though the process because the rest of the data is long gone while you step through one sample and there is nowhere to store it. I usually develop the signal processing algorithm in MATLAB just using data acquired by the thing I'm developing.

The projects I've done this kind of stuff on recently are ultrasonic range finding things  - where typically the signal is has to be detected within 0.5mS or less and there might be 6400 samples in a measurement but the micro (for production) only has the ability to store maybe 1000 samples.

Re ARM v AVR for debugging - it's better with ARM(Cortex) I think.

MK

Regarding the debugging of these filters: at audio frequencies you can easily use one DAC of a board to output data after your filter. that way you can take a "realtime" look at the signal output of the filter.

Regarding debugging of AVR or ARM: it all depends on your toolchain. For AVR there are nice tools available within Atmel Studio (watches, breakpoints, stepping). If you're using Linux you'll have to figure a lot out by yourself, but it is possible using GDB. Most probably you'll need an AVR Dragon (at least) to get a debugging interface like JTAG or debugwire.

In all ARM core's there's debug functionality. For quick test stuff (not optimized for performance) I use the mbed environment quite a lot. it's easy to get a board (the beforementioned KL25Z is $12), and the compiler is online. Within minutes you've flashed your first blinky. The issue with debugging is that you'll only be able to use "printf's" and toggling leds or something like it to see what's going on. BUT if you go to the free trial version of Keil, you can do on-chip debugging on this $12 board, no other hardware needed. As you can judge by the emphasis, I really like this