change filter freq. w/o glitches

Challenge: 
An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from 
one frequency to another without causing (considerable) overshoot.
Changes in amplitude and phase should be smooth.
There's not much processor time left for additional calculations. 
Therefore I watch out for a tiny but smart solution.

Approach:
I chose DF1 form because it stores only those values which enter or 
leave the filter. (Input values are independent of coefficient 
changes, output signal values are at least bounded and somehow 
predictable.)
Seems to be closer to the goal than with DF2 or others.

When switching occurs, storage elements hold "wrong" values. 
That is why ringing, overshoot etc. occurs.
"Preloading" with the correct values would completely avoid any 
distortion, but I guess it cannot be done because of the infinite 
recursion.

Compensation by running old and new filter set in parallel (with 
input of the old one grounded) and adding the output signals 
improves the behaviour but not in all cases. And, it's expensive 
(time).

What I do currently, is this:
Filter coefficients are changed without taking care of the stored 
values. After the filter output there's a limiting stage which 
compares input and output values and takes the lower one.

But this approach is not satisfying. 
Any hints / ideas are welcome.


Bernhard

-- 
before sending to the above email-address:
replace deadspam.com by foerstergroup.de

Bernhard Holzmayer wrote:

> But this approach is not satisfying. 
> Any hints / ideas are welcome.

Computational intensive:
Run two filters in parallel, with equal delay.
Fade between one output to the other.

bye,

-- 
   Piergiorgio Sartor

Bernhard Holzmayer wrote:
> Challenge:
> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from
> one frequency to another without causing (considerable) overshoot.
> Changes in amplitude and phase should be smooth.
> There's not much processor time left for additional calculations.
> Therefore I watch out for a tiny but smart solution.

You could apply a 1st-order lowpass to each coefficient
(filter the filtercoeffs). If this is done as background process,
triggered every 4 (8, 16 ...) samples, it doesn't cost very much.
This works for 1st and 2nd order filters (DF1, kanonical #1,
less good for DF2 / kanonical #2). With orders higher than 2,
poles run temporarily outside the unitcircle.
(This applys not to cascaded filters of order 2).

Regards
Mattias

Hello Bernhard,

Some time ago I encountered a problem similar to yours. 

The simple solution is to run the old and the new filters in parallel
and mix their outputs slowly changing the proportion. However that might
be expensive.  

The permanent modification of the IIR filter coefficients by small
amount on every clock cycle is not good because the filter can
occasionally run into unstable operation area.

You can change the filter from old to new by several intermediate steps.
The overshoots are going to be smaller by the number of steps.

The good, but expensive solution is to switch the filter to new
coefficients and modify memories in the way the output response is
continuos. That should be done separately for feedback and feedforward
filter paths. For Chebyshev-1 feedforward path the feedforward memory is
multiplied by the difference in feedforward gain. In the feedback path,
the memories are modified to match first two points of impulse response.
      
Vladimir Vassilevsky, Ph.D.

DSP and Mixed Signal Design Consultant

http://www.abvolt.com


Bernhard Holzmayer wrote:
> 
> Challenge:
> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from
> one frequency to another without causing (considerable) overshoot.
> Changes in amplitude and phase should be smooth.
> There's not much processor time left for additional calculations.
> Therefore I watch out for a tiny but smart solution.
> 
> Approach:
> I chose DF1 form because it stores only those values which enter or
> leave the filter. (Input values are independent of coefficient
> changes, output signal values are at least bounded and somehow
> predictable.)
> Seems to be closer to the goal than with DF2 or others.
> 
> When switching occurs, storage elements hold "wrong" values.
> That is why ringing, overshoot etc. occurs.
> "Preloading" with the correct values would completely avoid any
> distortion, but I guess it cannot be done because of the infinite
> recursion.
> 
> Compensation by running old and new filter set in parallel (with
> input of the old one grounded) and adding the output signals
> improves the behaviour but not in all cases. And, it's expensive
> (time).
> 
> What I do currently, is this:
> Filter coefficients are changed without taking care of the stored
> values. After the filter output there's a limiting stage which
> compares input and output values and takes the lower one.
> 
> But this approach is not satisfying.
> Any hints / ideas are welcome.
> 
> Bernhard
> 
> --
> before sending to the above email-address:
> replace deadspam.com by foerstergroup.de

In article 4984413.0sRMePMuDS@holzmayer.ifr.rt, Bernhard Holzmayer at
holzmayer.bernhard@deadspam.com wrote on 06/24/2003 08:40:

> Challenge: 
> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from
> one frequency to another without causing (considerable) overshoot.
> Changes in amplitude and phase should be smooth.
> There's not much processor time left for additional calculations.
> Therefore I watch out for a tiny but smart solution.
> 
> Approach:
> I chose DF1 form because it stores only those values which enter or
> leave the filter. (Input values are independent of coefficient
> changes, output signal values are at least bounded and somehow
> predictable.)
> Seems to be closer to the goal than with DF2 or others.
> 
> When switching occurs, storage elements hold "wrong" values.
> That is why ringing, overshoot etc. occurs.
> "Preloading" with the correct values would completely avoid any
> distortion, but I guess it cannot be done because of the infinite
> recursion.
> 
> Compensation by running old and new filter set in parallel (with
> input of the old one grounded) and adding the output signals
> improves the behaviour but not in all cases. And, it's expensive
> (time).
> 
> What I do currently, is this:
> Filter coefficients are changed without taking care of the stored
> values. After the filter output there's a limiting stage which
> compares input and output values and takes the lower one.
> 
> But this approach is not satisfying.
> Any hints / ideas are welcome.

how about "slewing" the coefficients?

r b-j

In article 3EF88453.200B77CC@abvolt.com, Vladimir Vassilevsky at
vlv@abvolt.com wrote on 06/24/2003 13:03:

> Hello Bernhard,
> 
> Some time ago I encountered a problem similar to yours.
> 
> The simple solution is to run the old and the new filters in parallel
> and mix their outputs slowly changing the proportion. However that might
> be expensive.  
> 
> The permanent modification of the IIR filter coefficients by small
> amount on every clock cycle is not good because the filter can
> occasionally run into unstable operation area.

that depends on the form.  the DF1 with complex conjugate poles will not run
into unstable areas if the startpoint and endpoint are both stable.  slewing
can be made slow enough so that artifacts of the slewing won't be large.

r b-j

In article bd9p99$pboug$1@ID-168735.news.dfncis.de, Mattias Schick at
mattias.schick@lawo.de wrote on 06/24/2003 11:04:

> Bernhard Holzmayer wrote:
>> Challenge:
>> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from
>> one frequency to another without causing (considerable) overshoot.
>> Changes in amplitude and phase should be smooth.
>> There's not much processor time left for additional calculations.
>> Therefore I watch out for a tiny but smart solution.
> 
> You could apply a 1st-order lowpass to each coefficient
> (filter the filtercoeffs). If this is done as background process,
> triggered every 4 (8, 16 ...) samples, it doesn't cost very much.

this is very good advice.  it is very efficient to choose the sample "chunk"
or block size in such a way so that you can slew coefficients once per chunk
or block.  the larger the block, the slower the slewing has to be.  check
out the limit cycle problem in the slew filters so that coefs don't get
stuck on slightly incorrect values (the DC-blocking filter trick i have
suggested at dspguru has the solution to that problem).

> This works for 1st and 2nd order filters (DF1, kanonical #1,
> less good for DF2 / kanonical #2). With orders higher than 2,
> poles run temporarily outside the unitcircle.

not if they were complex conjugate, and i doubt it if they were real also.

oh, perhaps you mean that the orders higher than 2 are not cascaded biquad
sections and then, in that case, you are certainly correct.

> (This applys not to cascaded filters of order 2).

duh.  i gotta read through the whole post before responding.

:-\

r b-j

"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:4984413.0sRMePMuDS@holzmayer.ifr.rt...
> Challenge:
> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched from
> one frequency to another without causing (considerable) overshoot.
> Changes in amplitude and phase should be smooth.
> There's not much processor time left for additional calculations.
> Therefore I watch out for a tiny but smart solution.
>
> Approach:
> I chose DF1 form because it stores only those values which enter or
> leave the filter. (Input values are independent of coefficient
> changes, output signal values are at least bounded and somehow
> predictable.)
> Seems to be closer to the goal than with DF2 or others.
>
> When switching occurs, storage elements hold "wrong" values.
> That is why ringing, overshoot etc. occurs.
> "Preloading" with the correct values would completely avoid any
> distortion, but I guess it cannot be done because of the infinite
> recursion.
>
> Compensation by running old and new filter set in parallel (with
> input of the old one grounded) and adding the output signals
> improves the behaviour but not in all cases. And, it's expensive
> (time).
>
> What I do currently, is this:
> Filter coefficients are changed without taking care of the stored
> values. After the filter output there's a limiting stage which
> compares input and output values and takes the lower one.
>
> But this approach is not satisfying.
> Any hints / ideas are welcome.
>
>
> Bernhard
>

You've received some good suggestions.  One that hasn't been mentioned that
may be good would be this:

As a variant to low-pass filtering the coefficients or slewing their values
in a brute-force numerical scheme (with the problem of pole movement that's
been mentioned), would your application support storing a number of filters
so that as you select the next filter, you slew the filter response instead
of *directly* changing the coefficients?  This way, the coefficients could
be a table lookup and the coefficient changes would be appropriate for the
filter response.  That is, the filter coefficients would change according to
the value of coefficient that's needed for a good filter.  Otherwise, if you
operate on the coefficients directly, the filter could look strange part way
through I would think.

Example:  A high-pass filter that needs to move from 0.4(fs/2) to 0.8(fs/2).
Could you design and save filters at increments of 0.01(Fs/2) across the
range and switch from one to the next until the desired high pass filter is
reached?

There's been no mention of filter impulse response vs. change rate.  If you
use the scheme suggested above, is it OK to switch filters at a rate that's
greater than 1 change per effective length of the impulse response?  I
rather suspect not.  And, I have no idea - haven't tried it.  That by itself
would be an interesting study.  Probably someone has done it.

Fred

Lots of good hints!

Since it seems helpful, I'll give some more details below: 

> Challenge:
> An IIR high-pass filter (Cheby1, 2.order, DF1) must be switched
> from one frequency to another without causing (considerable)
> overshoot. Changes in amplitude and phase should be smooth.
> There's not much processor time left for additional calculations.
> Therefore I watch out for a tiny but smart solution.
> 
> Approach:
> I chose DF1 form because it stores only those values which enter
> or leave the filter. (Input values are independent of coefficient
> changes, output signal values are at least bounded and somehow
> predictable.)
> Seems to be closer to the goal than with DF2 or others.
> 
> When switching occurs, storage elements hold "wrong" values.
> That is why ringing, overshoot etc. occurs.
> "Preloading" with the correct values would completely avoid any
> distortion, but I guess it cannot be done because of the infinite
> recursion.
> 
> Compensation by running old and new filter set in parallel (with
> input of the old one grounded) and adding the output signals
> improves the behaviour but not in all cases. And, it's expensive
> (time).
> 
> What I do currently, is this:
> Filter coefficients are changed without taking care of the stored
> values. After the filter output there's a limiting stage which
> compares input and output values and takes the lower one.

Background:
For direct replacement of an analog filter solution, I have to 
design a digital solution which behaves as similar as possible like 
the analog implementation (at least not worse).
Signal source is a demodulator which provides orthogonal vector 
components, which are treated as individual channels in parallel
(X and Y components of the signal vector).
signal frequency range: DC - 20kHz
sliding filter freq. range: 1Hz .... 16kHz
sampling frequency is 48kHz
I'm working with a Sharc DSP (21161), currently on EZ-KIT base.
24bit floating point samples/coefficients/code.

Filtering is done with two application specific higher-order 
butterworth filters (high pass and low pass) which are adjustable, 
but not changing during measurements.
Then there's this Cheby-Filter, which is moving during measurements.
Measurement speed (there's an input for it) defines the cutoff 
frequency of this filter; this means, fc is application dependent.
Although I don't take it into account up to now: speed is changing 
smoothly because masses must be accelerated, thus filter movement 
is a bit predictable. 

I can do a table lookup to find the coefficients (that's how it's 
done in the analog solution). Table entries can be logarithmically 
spaced. 
Another approach, which I prefer, is: I retrieved a polynomial 
approximation of the coefficients over frequency and evaluate the 
polynomials when speed changes.

There is some time available to apply the improvement (slewing or 
whatever): the filter is currently moved every 100ms.
I could imagine to apply some interpolation algorithm on the filter 
coefficients. 

After this filtering we mainly search for peaks on the signal 
vector, within a certain phase sector. 
Therefore it's important that filter movement doesn't influence 
vector phase (signal independency ?) and that no peaks are 
introduced which might be interpreted as peaks coming from the 
signal.

Bernhard
 

-- 
before sending to the above email-address:
replace deadspam.com by foerstergroup.de

robert bristow-johnson wrote:

> In article 3EF88453.200B77CC@abvolt.com, Vladimir Vassilevsky at
> vlv@abvolt.com wrote on 06/24/2003 13:03:
> 
>> Hello Bernhard,
>> 
>> Some time ago I encountered a problem similar to yours.
>> 
>> The simple solution is to run the old and the new filters in
>> parallel and mix their outputs slowly changing the proportion.
>> However that might be expensive.
>> 
>> The permanent modification of the IIR filter coefficients by
>> small amount on every clock cycle is not good because the filter
>> can occasionally run into unstable operation area.
> 
> that depends on the form.  the DF1 with complex conjugate poles
> will not run
> into unstable areas if the startpoint and endpoint are both
> stable.  slewing can be made slow enough so that artifacts of the
> slewing won't be large.
> 
> r b-j

indeed, slewing coefficents might be a very straight-forward 
solution. thanks for the hint.

I checked different structures because I wanted to develop 
polynomial approximations for online calculation of the 
coefficients.
DF1 showed a very secure behaviour: it will not become instable when 
interpolating between coefficients.

However, usability depends if the interpolation of coefficients can 
be done easy and fast enough because it must be done at every 
sample. 

Bernhard


-- 
before sending to the above email-address:
replace deadspam.com by foerstergroup.de