Query re simple digital bandsplit/crossover algorithm

I'm working on a Christmas present for my sister Beth based on a 1m
strip of 30 RGB LEDs (Beth doesn't believe in newsgroups, so my
posting here won't spoil the surprise <grin!>).  The end result --
currently -- will change colors in response to sound, either from a
microphone or (say) an iPod audio feed.  Yup, it's yet another
variant on Ye Olde Fashined Color Organ.

The idea is to sample the incoming audio at (say) 8kHz and determine
the level of sound present in various frequency bands, e.g. if I 
make it respond to a normal human voice:

  Red:      80-186Hz
  Green:    186-420Hz
  Blue:     420-1000Hz

but I could live with (say) (DC-180, 180-420, and 420-Nyquist).

There are some minor technical hurdles, such as switching the 12V 
LED strip from a 3V micro port pin (see: 2N2222) all of which I seem
to have made it past. What I'm currently stuck on is finding a 
simple, low-resource algorithm for translating a stream of samples 
into "volume" levels that I can use to drive my PWM LED logic.

Oh, did I mention...  I want to do this with a TI MSP430G2231
(LaunchPad) which features, in addition to the 10-bit A/D.  a
whopping 2k of flash, and 128 bytes of RAM.  It's not all bad,
though:  since I don't need exquisite calibration, I can run the
chip at up to 16MHz.

I'm currently reading up on Goertzel's algorithm, trying to
understand it well enough to develop a multi-accumulator version
that can track "activity" in multiple bins which I can sum.  As I
was working out some bin size calculations it occurred to me that
I'd seen the same band-splitting done years ago as a Hi-Fi (no,
Grasshopper, not "Wi-Fi") loudspeaker "crossover".

Is anyone aware of research on something similar to single-tone
detection (e.g.  Goertzel) but based on a limited number of
arbitrary-sized bins?  It's the kind of thing one might want in
(say) a spectrum analyzer:  "let me know about activity here, here,
or here". Google turned up a number of references, but they were
all designed for "re-routing" audio rather than simply providing
an index to activity.

Hints, pointers, and suggestions welcomed.

Thanks...


Frank McKenney
-- 
  It is one thing to say that I may be coerced for my own good which
  I am too blind to see: this may, on occasion, be for my benefit;
  indeed it may enlarge the scope of my liberty. It is another to
  say that if it is my good, then I am not being coerced, for I have
  willed it, whether I know this or not, and am free (or 'truly'
  free) even while my poor earthly body and foolish mind bitterly
  reject it, and struggle against those who seek however
  benevolently to impose it, with the greatest desperation.
                        -- Isaiah Berlin / Two Concepts of Liberty
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

Frnak McKenney <frnak@far.from.the.madding.crowd.com> writes:

> I'm working on a Christmas present for my sister Beth based on a 1m
> strip of 30 RGB LEDs (Beth doesn't believe in newsgroups, so my
> posting here won't spoil the surprise <grin!>).  The end result --
> currently -- will change colors in response to sound, either from a
> microphone or (say) an iPod audio feed.  Yup, it's yet another
> variant on Ye Olde Fashined Color Organ.
>
> The idea is to sample the incoming audio at (say) 8kHz and determine
> the level of sound present in various frequency bands, e.g. if I 
> make it respond to a normal human voice:
>
>   Red:      80-186Hz
>   Green:    186-420Hz
>   Blue:     420-1000Hz
>
> but I could live with (say) (DC-180, 180-420, and 420-Nyquist).
>
> There are some minor technical hurdles, such as switching the 12V 
> LED strip from a 3V micro port pin (see: 2N2222) all of which I seem
> to have made it past. What I'm currently stuck on is finding a 
> simple, low-resource algorithm for translating a stream of samples 
> into "volume" levels that I can use to drive my PWM LED logic.
>
> Oh, did I mention...  I want to do this with a TI MSP430G2231
> (LaunchPad) which features, in addition to the 10-bit A/D.  a
> whopping 2k of flash, and 128 bytes of RAM.  It's not all bad,
> though:  since I don't need exquisite calibration, I can run the
> chip at up to 16MHz.
>
> I'm currently reading up on Goertzel's algorithm, trying to
> understand it well enough to develop a multi-accumulator version
> that can track "activity" in multiple bins which I can sum.  As I
> was working out some bin size calculations it occurred to me that
> I'd seen the same band-splitting done years ago as a Hi-Fi (no,
> Grasshopper, not "Wi-Fi") loudspeaker "crossover".
>
> Is anyone aware of research on something similar to single-tone
> detection (e.g.  Goertzel) but based on a limited number of
> arbitrary-sized bins?  It's the kind of thing one might want in
> (say) a spectrum analyzer:  "let me know about activity here, here,
> or here". Google turned up a number of references, but they were
> all designed for "re-routing" audio rather than simply providing
> an index to activity.
>
> Hints, pointers, and suggestions welcomed.
>
> Thanks...
>
>
> Frank McKenney
> -- 
>   It is one thing to say that I may be coerced for my own good which
>   I am too blind to see: this may, on occasion, be for my benefit;
>   indeed it may enlarge the scope of my liberty. It is another to
>   say that if it is my good, then I am not being coerced, for I have
>   willed it, whether I know this or not, and am free (or 'truly'
>   free) even while my poor earthly body and foolish mind bitterly
>   reject it, and struggle against those who seek however
>   benevolently to impose it, with the greatest desperation.
>                         -- Isaiah Berlin / Two Concepts of Liberty

Frank, I would take the easy way out and just take the power out of
three FIRs. For this application, they would probably be short, and at
~8 KHz sample rate not too much of a load on the MSP. You could keep the
coefficients in FLASH. But it's a matter of goals. If you want to
implement and learn about Goertzel, go ahead and choose that route. If
you want to knock it out in a couple hours, FIRs.

--Randy
-- 
Randy Yates                      % "The dreamer, the unwoken fool - 
Digital Signal Labs              %  in dreams, no pain will kiss the brow..."
mailto://yates@ieee.org          %  
http://www.digitalsignallabs.com % 'Eldorado Overture', *Eldorado*, ELO

On 11/09/2010 05:53 AM, Frnak McKenney wrote:
> I'm working on a Christmas present for my sister Beth based on a 1m
> strip of 30 RGB LEDs (Beth doesn't believe in newsgroups, so my
> posting here won't spoil the surprise<grin!>).  The end result --
> currently -- will change colors in response to sound, either from a
> microphone or (say) an iPod audio feed.  Yup, it's yet another
> variant on Ye Olde Fashined Color Organ.
>
> The idea is to sample the incoming audio at (say) 8kHz and determine
> the level of sound present in various frequency bands, e.g. if I
> make it respond to a normal human voice:
>
>    Red:      80-186Hz
>    Green:    186-420Hz
>    Blue:     420-1000Hz
>
> but I could live with (say) (DC-180, 180-420, and 420-Nyquist).
>
> There are some minor technical hurdles, such as switching the 12V
> LED strip from a 3V micro port pin (see: 2N2222) all of which I seem
> to have made it past. What I'm currently stuck on is finding a
> simple, low-resource algorithm for translating a stream of samples
> into "volume" levels that I can use to drive my PWM LED logic.
>
> Oh, did I mention...  I want to do this with a TI MSP430G2231
> (LaunchPad) which features, in addition to the 10-bit A/D.  a
> whopping 2k of flash, and 128 bytes of RAM.  It's not all bad,
> though:  since I don't need exquisite calibration, I can run the
> chip at up to 16MHz.
>
> I'm currently reading up on Goertzel's algorithm, trying to
> understand it well enough to develop a multi-accumulator version
> that can track "activity" in multiple bins which I can sum.  As I
> was working out some bin size calculations it occurred to me that
> I'd seen the same band-splitting done years ago as a Hi-Fi (no,
> Grasshopper, not "Wi-Fi") loudspeaker "crossover".
>
> Is anyone aware of research on something similar to single-tone
> detection (e.g.  Goertzel) but based on a limited number of
> arbitrary-sized bins?  It's the kind of thing one might want in
> (say) a spectrum analyzer:  "let me know about activity here, here,
> or here". Google turned up a number of references, but they were
> all designed for "re-routing" audio rather than simply providing
> an index to activity.
>
> Hints, pointers, and suggestions welcomed.

(Excerpt from the New Webster International Dictionary of DSP Synonyms 
for the Newbie:

FFT: useful magic

Goertzel's Algorithm: useful magic
)

Goertzel's algorithm is nothing but a second-order lowpass IIR filter 
with a damping ratio of zero, used for a finite amount of time so that 
the response does not have a chance to build to infinity.

Instead of using IIR filters with zero damping ratio, using lots of them 
because they're of zero damping ratio, and struggling mightily -- both 
at design time and at run time -- with the fact that they're of zero 
damping ratio, why not use one filter with three outputs to distinguish 
the three frequency bands?

If one filter gives you the heebee-jeebees, consider a lowpass filter to 
distinguish red, a highpass filter to distinguish blue, and a bandpass 
filter to distinguish green?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Frnak McKenney wrote:

> I'm working on a Christmas present for my sister Beth based on a 1m
> strip of 30 RGB LEDs

> The idea is to sample the incoming audio at (say) 8kHz and determine
> the level of sound present in various frequency bands, e.g. if I 
> make it respond to a normal human voice:
> 
>   Red:      80-186Hz
>   Green:    186-420Hz
>   Blue:     420-1000Hz
> 
> but I could live with (say) (DC-180, 180-420, and 420-Nyquist).
> 
> Oh, did I mention...  I want to do this with a TI MSP430G2231

> I'm currently reading up on Goertzel's algorithm, trying to
> understand it well enough to develop a multi-accumulator version

No need to do any Goertzels or filters.
A basic frequency counter is all that required.
Just make a hystogram of periods; lit the LEDs accordingly.
You might need to add RC highpass in front of the comparator to 
compensate for the spectral skew.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Tim Wescott <tim@seemywebsite.com> wrote:
(big snip)

> Instead of using IIR filters with zero damping ratio, using lots of them 
> because they're of zero damping ratio, and struggling mightily -- both 
> at design time and at run time -- with the fact that they're of zero 
> damping ratio, why not use one filter with three outputs to distinguish 
> the three frequency bands?
 
> If one filter gives you the heebee-jeebees, consider a lowpass filter to 
> distinguish red, a highpass filter to distinguish blue, and a bandpass 
> filter to distinguish green?

I would have thought that, if they are normalized right, you
can subtract the blue and red from the input to get green.
That means only two filters instead of three, and you know that
the sum of the three is equal to the input. 

-- glen

On 11/09/2010 03:37 PM, glen herrmannsfeldt wrote:
> Tim Wescott<tim@seemywebsite.com>  wrote:
> (big snip)
>
>> Instead of using IIR filters with zero damping ratio, using lots of them
>> because they're of zero damping ratio, and struggling mightily -- both
>> at design time and at run time -- with the fact that they're of zero
>> damping ratio, why not use one filter with three outputs to distinguish
>> the three frequency bands?
>
>> If one filter gives you the heebee-jeebees, consider a lowpass filter to
>> distinguish red, a highpass filter to distinguish blue, and a bandpass
>> filter to distinguish green?
>
> I would have thought that, if they are normalized right, you
> can subtract the blue and red from the input to get green.
> That means only two filters instead of three, and you know that
> the sum of the three is equal to the input.

I was trying to keep it simple.  Without a bit of work you'd find odd 
things happening at the band edges of the filters.

In theory you could do it with one filter kernel, and just bring the 
red, green and blue channels out using cleverly weighted output taps.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On 11/09/2010 04:11 PM, Tim Wescott wrote:
> On 11/09/2010 03:37 PM, glen herrmannsfeldt wrote:
>> Tim Wescott<tim@seemywebsite.com> wrote:
>> (big snip)
>>
>>> Instead of using IIR filters with zero damping ratio, using lots of them
>>> because they're of zero damping ratio, and struggling mightily -- both
>>> at design time and at run time -- with the fact that they're of zero
>>> damping ratio, why not use one filter with three outputs to distinguish
>>> the three frequency bands?
>>
>>> If one filter gives you the heebee-jeebees, consider a lowpass filter to
>>> distinguish red, a highpass filter to distinguish blue, and a bandpass
>>> filter to distinguish green?
>>
>> I would have thought that, if they are normalized right, you
>> can subtract the blue and red from the input to get green.
>> That means only two filters instead of three, and you know that
>> the sum of the three is equal to the input.
>
> I was trying to keep it simple. Without a bit of work you'd find odd
> things happening at the band edges of the filters.
>
> In theory you could do it with one filter kernel, and just bring the
> red, green and blue channels out using cleverly weighted output taps.
>
Unless you just used 1st-order filters for the red vs. green and the 
green vs. blue -- then odd things probably wouldn't happen at the band 
edges.

{
   ...
   // microphone signal is in "input"
   gb = input - red;
   red = red + gainLow * gb;
   blue = gb - green;
   green = green + gainHigh * blue;
   // Red channel is in 'red', blue in 'blue', green in 'green'
   // note that they are still waves, so you'll need to extract
   // longer-term averages (or just let the lights flicker at
   // the audio rate, which probably isn't a bad thing).
   ...
}

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

> On 11/09/2010 04:11 PM, Tim Wescott wrote:
> 
>> On 11/09/2010 03:37 PM, glen herrmannsfeldt wrote:
>>
>>> Tim Wescott<tim@seemywebsite.com> wrote:
>>> (big snip)
>>>
>>>> Instead of using IIR filters with zero damping ratio, using lots of 
>>>> them
>>>> because they're of zero damping ratio, and struggling mightily -- both
>>>> at design time and at run time -- with the fact that they're of zero
>>>> damping ratio, why not use one filter with three outputs to distinguish
>>>> the three frequency bands?
>>>
>>>
>>>> If one filter gives you the heebee-jeebees, consider a lowpass 
>>>> filter to
>>>> distinguish red, a highpass filter to distinguish blue, and a bandpass
>>>> filter to distinguish green?
>>>
>>>
>>> I would have thought that, if they are normalized right, you
>>> can subtract the blue and red from the input to get green.
>>> That means only two filters instead of three, and you know that
>>> the sum of the three is equal to the input.
>>
>>
>> I was trying to keep it simple. Without a bit of work you'd find odd
>> things happening at the band edges of the filters.
>>
>> In theory you could do it with one filter kernel, and just bring the
>> red, green and blue channels out using cleverly weighted output taps.
>>
> Unless you just used 1st-order filters for the red vs. green and the 
> green vs. blue -- then odd things probably wouldn't happen at the band 
> edges.
> 
> {
>   ...
>   // microphone signal is in "input"
>   gb = input - red;
>   red = red + gainLow * gb;
>   blue = gb - green;
>   green = green + gainHigh * blue;
>   // Red channel is in 'red', blue in 'blue', green in 'green'
>   // note that they are still waves, so you'll need to extract
>   // longer-term averages (or just let the lights flicker at
>   // the audio rate, which probably isn't a bad thing).
>   ...
> }

THIS IS 7 LINES OF CODE THAT ALL IT TAKES:

static s16 z[5];

void RGB_Filter(s16 x)
{
x -= z[0];
z[0] += x >> 1;
z[1] += (abs(x) - z[1])>>8; // High
x = z[0] - z[2];
z[2] += x >> 3;
z[3] += (abs(x) - z[3])>>8;   // Mid
z[4] += (abs(z[3])- z[4])>>8; // Low
}

WHAT COULD IT BE ANY SIMPLER THEN THIS?

Bla-bla-bla, kernel, Goetzel...



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Tue, 09 Nov 2010 11:22:10 -0500, Randy Yates <yates@ieee.org> wrote:
> Frnak McKenney <frnak@far.from.the.madding.crowd.com> writes:
    [...]
>> The idea is to sample the incoming audio at (say) 8kHz and determine
>> the level of sound present in various frequency bands, e.g. if I 
>> make it respond to a normal human voice:
>>
>>   Red:      80-186Hz
>>   Green:    186-420Hz
>>   Blue:     420-1000Hz
>>
>> but I could live with (say) (DC-180, 180-420, and 420-Nyquist).
    [...]
>> Oh, did I mention...  I want to do this with a TI MSP430G2231
>> (LaunchPad) which features, in addition to the 10-bit A/D.  a
>> whopping 2k of flash, and 128 bytes of RAM.  It's not all bad,
>> though:  since I don't need exquisite calibration, I can run the
>> chip at up to 16MHz.
    [...]
>> I'm currently reading up on Goertzel's algorithm, trying to
>> understand it well enough to develop a multi-accumulator version
>> that can track "activity" in multiple bins which I can sum.

> Frank, I would take the easy way out and just take the power out
> of three FIRs.  For this application, they would probably be
> short, and at ~8 KHz sample rate not too much of a load on the
> MSP.  You could keep the coefficients in FLASH.  But it's a matter
> of goals.  If you want to implement and learn about Goertzel, go
> ahead and choose that route.  If you want to knock it out in a
> couple hours, FIRs.
> 
> --Randy

Thanks for the reply, Randy.

Ah, filters.  I was under the impression (translation:  I've never
coded one) that filters were complex and cycle-intensive little
beasties; one of TI's app notes speaks of 600- and 700-instruction
filters, and fitting three of those into 2k seemed a bit much.

Guess I need to go back and check my assumptions.


Frank
-- 
  Necessity is the plea for every infringement of human freedom. It
  is the argument of tyrants; it is the creed of slaves.
                             -- William Pitt
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

On Tue, 09 Nov 2010 08:27:18 -0800, Tim Wescott <tim@seemywebsite.com> wrote:
> On 11/09/2010 05:53 AM, Frnak McKenney wrote:
    [...]
>> The idea is to sample the incoming audio at (say) 8kHz and determine
>> the level of sound present in various frequency bands, e.g. if I
>> make it respond to a normal human voice:
>>
>>    Red:      80-186Hz
>>    Green:    186-420Hz
>>    Blue:     420-1000Hz
>>
>> but I could live with (say) (DC-180, 180-420, and 420-Nyquist).
    [...]
>> Oh, did I mention...  I want to do this with a TI MSP430G2231
>> (LaunchPad) which features, in addition to the 10-bit A/D.  a
>> whopping 2k of flash, and 128 bytes of RAM.  It's not all bad,
>> though:  since I don't need exquisite calibration, I can run the
>> chip at up to 16MHz.
>>
>> I'm currently reading up on Goertzel's algorithm, trying to
>> understand it well enough to develop a multi-accumulator version
>> that can track "activity" in multiple bins which I can sum.

Hi, Tim. Thnaks for jumping in.
 
> (Excerpt from the New Webster International Dictionary of DSP
>  Synonyms for the Newbie:
>  FFT: useful magic
>  Goertzel's Algorithm: useful magic
> )

It is said that the secret of Magic is knowing the True Names of
things...  a bit like using a 'Web search engine.  <grin!>
  
> Goertzel's algorithm is nothing but a second-order lowpass IIR
> filter with a damping ratio of zero, used for a finite amount of
> time so that the response does not have a chance to build to
> infinity.

O...kay. (He says, trying to sound intelligent.)
 
> Instead of using IIR filters with zero damping ratio, using lots
> of them because they're of zero damping ratio, and struggling
> mightily -- both at design time and at run time -- with the fact
> that they're of zero damping ratio, why not use one filter with
> three outputs to distinguish the three frequency bands?

Um, ignorance?  I speak as one whose original design (okay,
"concept") included three opamps and a bunch of Rs and Cs.
 
> If one filter gives you the heebee-jeebees, consider a lowpass
> filter to distinguish red, a highpass filter to distinguish blue,
> and a bandpass filter to distinguish green?
 
Oh, I'm fine with filters; if you don't see what you want on the
'scope, you unsolder a part or two and replace it.  It's _digital_
filters that worry me.  <grin!>

Okay.  You, Randy, and looking at my used-to-be-Goertzel pseudocode
have convinced me that, to get what I want, I need to go back and
study up on simple filters.  Thanks. (I think. <grin!>)


Frank
-- 
  Just as a physical body can continue to live, despite containing
  a certain amount of microorganisms whose prevelaence would destroy
  it, so a society can survive a certain amount of forces of
  disintegration within it. But that is very diffeent from saying
  that there is no limit to the amount, audacity, and ferocity of
  those disintegrative forces which a society can survive, without
  at least the will to resist.
                      -- Thomas Sowell / Intellectuals and Society
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)