Question on using Parks-McClellan in real time signal processing operation

I'm working on a multi-pass FIR method but will probably
reduce my process to the Parks-McClellan method
which can achieve equivalent results and is well known.

I need to gain a better understanding of how to use this
method in a real time signal processing process so I
am clear on how to maintain proper control over the entry
and exit times also well as signals.  I also interested in
alternative methods of treating the ends to shorten the delay.

My application is very similar to an actuarial operation
involving probability data and the process is running several
times per minute.

Any ideas from people using multi-pass FIRs and/or the
Parks-McClellan in a real time signal process, etc.

"Newport" <edwards2107@comcast.net> wrote in message 
news:1158946779.554329.31770@h48g2000cwc.googlegroups.com...
> I'm working on a multi-pass FIR method but will probably
> reduce my process to the Parks-McClellan method
> which can achieve equivalent results and is well known.
>
> I need to gain a better understanding of how to use this
> method in a real time signal processing process so I
> am clear on how to maintain proper control over the entry
> and exit times also well as signals.  I also interested in
> alternative methods of treating the ends to shorten the delay.
>
> My application is very similar to an actuarial operation
> involving probability data and the process is running several
> times per minute.
>
> Any ideas from people using multi-pass FIRs and/or the
> Parks-McClellan in a real time signal process, etc.
>

You're going to have to be clearer about this.  The Parks-McClellan program 
designs FIR filters.  That has nothing at all to do with real time signal 
processing really; nor multi-pass filtering, etc.

Perhaps you mean how might you design FIR filters on the fly?  Perhaps you 
are referring to adaptive filters?

"Entry and exit times" have no particular meaning that I know of.  What are 
you referring to?

"Treating the ends to shorten the delay" is also too obscure to cause a 
reasonable response.
It appears you'd like to have short transient times so the filter will 
settle more rapidly.  That does have a relationship to delay.  It also 
implies filter length.

I believe there are methods that use filters forward and back across the 
data to remove transients.  But this is obviously not a real time process 
and real delay can be whatever it takes.

One of the problems using Parks-McClellan on the fly is: what are you going 
to tell it you need?  How is this information extracted?  Normally adaptive 
filters fill the need instead of something more definitive like 
Parks-McClellan.

Fred 

Fred Marshall skrev:
> "Newport" <edwards2107@comcast.net> wrote in message
> news:1158946779.554329.31770@h48g2000cwc.googlegroups.com...
> > I'm working on a multi-pass FIR method but will probably
> > reduce my process to the Parks-McClellan method
> > which can achieve equivalent results and is well known.
> >
> > I need to gain a better understanding of how to use this
> > method in a real time signal processing process so I
> > am clear on how to maintain proper control over the entry
> > and exit times also well as signals.  I also interested in
> > alternative methods of treating the ends to shorten the delay.
> >
> > My application is very similar to an actuarial operation
> > involving probability data and the process is running several
> > times per minute.
> >
> > Any ideas from people using multi-pass FIRs and/or the
> > Parks-McClellan in a real time signal process, etc.
> >
>
> You're going to have to be clearer about this.  The Parks-McClellan program
> designs FIR filters.  That has nothing at all to do with real time signal
> processing really; nor multi-pass filtering, etc.

A similar question was asked some time ago:

http://groups.google.co.uk/group/comp.dsp/browse_frm/thread/79b008ed672ba67e/3869e047a1fc9b24?lnk=gst&q=remez+design&rnum=9#3869e047a1fc9b24

The confusion seems to be between *designing* a filter
and *using* a filter. 


Rune

Thank you for your response.  I immediately recognized that I've
asked too many unrelated questions.  Let me back up and deal
with one at a time.

I'm currently using a FIR which consist of a multi-pass moving average
method that required an odd number so their is ean exact center.  It
has been suggested that with the Parks-McClellan I could design a
method to run the passes in one run rather than the three I am using.

I'm unaware of the other design benefits of Park-McClellan such as
various treatments to the ends but it is important for me to be able to
exlore alternatives.  My data sample consist of about 450 elements of
data and I'm currently using a window size of  31 with 3 passes.

If Park-McClellan is not useful for exploring aggresive smoothing
alternatves and treatment to the ends -- I have no further question on
it and can repost of the real time issue later or via email with
someone open to discussing multi-pass moving in a real time process
which would be ideal.



> You're going to have to be clearer about this.  The Parks-McClellan program
> designs FIR filters.  That has nothing at all to do with real time signal
> processing really; nor multi-pass filtering, etc.
>
> Perhaps you mean how might you design FIR filters on the fly?  Perhaps you
> are referring to adaptive filters?
>
> "Entry and exit times" have no particular meaning that I know of.  What are
> you referring to?
>
> "Treating the ends to shorten the delay" is also too obscure to cause a
> reasonable response.
> It appears you'd like to have short transient times so the filter will
> settle more rapidly.  That does have a relationship to delay.  It also
> implies filter length.
>
> I believe there are methods that use filters forward and back across the
> data to remove transients.  But this is obviously not a real time process
> and real delay can be whatever it takes.
>
> One of the problems using Parks-McClellan on the fly is: what are you going
> to tell it you need?  How is this information extracted?  Normally adaptive
> filters fill the need instead of something more definitive like
> Parks-McClellan.
> 
> Fred

Newport skrev:
> Thank you for your response.  I immediately recognized that I've
> asked too many unrelated questions.  Let me back up and deal
> with one at a time.
>
> I'm currently using a FIR which consist of a multi-pass moving average
> method that required an odd number so their is ean exact center.  It
> has been suggested that with the Parks-McClellan I could design a
> method to run the passes in one run rather than the three I am using.

What do you mean by "multi-pass"? Are all passes in the "forward"
direction? Or do you filter back and forth?

> I'm unaware of the other design benefits of Park-McClellan such as
> various treatments to the ends but it is important for me to be able to
> exlore alternatives.  My data sample consist of about 450 elements of
> data and I'm currently using a window size of  31 with 3 passes.

I assume you are concerned about end transients, or maybe
wrap-around effects. It is impossible to give advice without
knowing more about what you try to do, the methods you use,
and what you hope to achieve from the processing.

For instance, a narrow transient band between passband and
stopband in a filter is obtained at the expence of longer end
transients.

> If Park-McClellan is not useful for exploring aggresive smoothing
> alternatves and treatment to the ends -- I have no further question on
> it and can repost of the real time issue later or via email with
> someone open to discussing multi-pass moving in a real time process
> which would be ideal.

The terms "multi-pass" and "real time" are contradictions in terms
in the usuall terminology. Be aware that lots of people interpret
the term "multi-pass" as "forward-backward" filtering, which
is hard to achieve in real time since it requires that one keeps
a block of data in memory for a certain amount of time.

If this is *not* what you do, please explain in a little bit more
detail, and we may be able to help out.

Rune

In my case a centered moving averages with a window length of 31
would use each pass to sharpen the results be incrementally
decrease low frequency noise.

My particular method can easily filter over 1000 elements in this
fashion offline in under 1 second -- regardless of the fact that it
filtering via an iterative process -- it is fast enough for my purposes
online.  Again the passes are over the same data.

> What do you mean by "multi-pass"? Are all passes in the "forward"
> direction? Or do you filter back and forth?
>
> > I'm unaware of the other design benefits of Park-McClellan such as
> > various treatments to the ends but it is important for me to be able to
> > exlore alternatives.  My data sample consist of about 450 elements of
> > data and I'm currently using a window size of  31 with 3 passes.

First my data obtain robust results for the purpose that I am using it.
I only need two features for consistent results 1) agressive smoothing.
This is currently being provided by the multi-pass moving average.
2) Shortening response by weighting the front end differently.

Of course weighting the front end differently will have a similar
effect
of shortening the filter length. So I'm interested in exploring the
effects "on my data" of using 100% of filter length up to the center
point and treating various portions of the front ends as missing data
with the exception of the most recent data point or so.  While I have
heard this is common practice in DSP -- I'm unclear on how to
optimize parameters to find the design that provides the best
solution over alternative treatments of the ends.


> I assume you are concerned about end transients, or maybe
> wrap-around effects. It is impossible to give advice without
> knowing more about what you try to do, the methods you use,
> and what you hope to achieve from the processing.
>
> For instance, a narrow transient band between passband and
> stopband in a filter is obtained at the expence of longer end
> transients.
>
> > If Park-McClellan is not useful for exploring aggresive smoothing
> > alternatves and treatment to the ends -- I have no further question on
> > it and can repost of the real time issue later or via email with
> > someone open to discussing multi-pass moving in a real time process
> > which would be ideal.
>
> The terms "multi-pass" and "real time" are contradictions in terms
> in the usuall terminology. Be aware that lots of people interpret
> the term "multi-pass" as "forward-backward" filtering, which
> is hard to achieve in real time since it requires that one keeps
> a block of data in memory for a certain amount of time.
>
> If this is *not* what you do, please explain in a little bit more
> detail, and we may be able to help out.
> 
> Rune

I was involved in a project where we used Parks-McClellan filter desing 
software with X-Windows  sliders to filter data under operator control.  It 
worked in real time on an Indy with an 8 Khz sample rate.  It worked 
reasonable well. We used 64 taps with a stop band attentuation of 6- dB and 
0.1 dB passband ripple.

In article <AMOdnYAkmau2WYnYnZ2dnUVZ_uidnZ2d@centurytel.net>, "Fred Marshall" 
<fmarshallx@remove_the_x.acm.org> wrote:
>
>"Newport" <edwards2107@comcast.net> wrote in message 
>news:1158946779.554329.31770@h48g2000cwc.googlegroups.com...
>> I'm working on a multi-pass FIR method but will probably
>> reduce my process to the Parks-McClellan method
>> which can achieve equivalent results and is well known.
>>
>> I need to gain a better understanding of how to use this
>> method in a real time signal processing process so I
>> am clear on how to maintain proper control over the entry
>> and exit times also well as signals.  I also interested in
>> alternative methods of treating the ends to shorten the delay.
>>
>> My application is very similar to an actuarial operation
>> involving probability data and the process is running several
>> times per minute.
>>
>> Any ideas from people using multi-pass FIRs and/or the
>> Parks-McClellan in a real time signal process, etc.
>>
>
>You're going to have to be clearer about this.  The Parks-McClellan program 
>designs FIR filters.  That has nothing at all to do with real time signal 
>processing really; nor multi-pass filtering, etc.
>
>Perhaps you mean how might you design FIR filters on the fly?  Perhaps you 
>are referring to adaptive filters?
>
>"Entry and exit times" have no particular meaning that I know of.  What are 
>you referring to?
>
>"Treating the ends to shorten the delay" is also too obscure to cause a 
>reasonable response.
>It appears you'd like to have short transient times so the filter will 
>settle more rapidly.  That does have a relationship to delay.  It also 
>implies filter length.
>
>I believe there are methods that use filters forward and back across the 
>data to remove transients.  But this is obviously not a real time process 
>and real delay can be whatever it takes.
>
>One of the problems using Parks-McClellan on the fly is: what are you going 
>to tell it you need?  How is this information extracted?  Normally adaptive 
>filters fill the need instead of something more definitive like 
>Parks-McClellan.
>
>Fred 
>
>

"Newport" <edwards2107@comcast.net> wrote in message 
news:1159016874.615027.218930@i3g2000cwc.googlegroups.com...
> Thank you for your response.  I immediately recognized that I've
> asked too many unrelated questions.  Let me back up and deal
> with one at a time.
>
> I'm currently using a FIR which consist of a multi-pass moving average
> method that required an odd number so their is ean exact center.  It
> has been suggested that with the Parks-McClellan I could design a
> method to run the passes in one run rather than the three I am using.
>
> I'm unaware of the other design benefits of Park-McClellan such as
> various treatments to the ends but it is important for me to be able to
> exlore alternatives.  My data sample consist of about 450 elements of
> data and I'm currently using a window size of  31 with 3 passes.
>

The only thing I see here is that a multipass filter can be re-cast as a 
single pass filter.
The simplest way to do it is to calculate the unit sample response of the 
multipass filter.  This yields what would be the unit sample response of the 
whole thing and, as such, may be treated as a single-pass filter.  Maybe 
that would be useful for you to do anyway.

That filter (whether deemed multi-pass or single-pass) will have a frequency 
response which you can assess.
Then, if you like it, or, if you would like to modify it, then you can use 
Parks-McClellan to design a single-pass filter with the characteristics you 
want (i.e. frequency response).
That is about all it will do for you.  It has nothing at all to do with 
"ends" unto itself.  That's something you will have to deal with separately.

It's unclear if you are using the same filter 3 times or 3 different filters 
for the multipass.  In linear systems context I would prefer to call it a 
3-stage or N-stage filter where each stage would be a "pass" on the data and 
might look something like this:

h1(t), h2(t) and h3(t) are the 3 filters.
First the data is "passed", i.e. convolved with h1(t).
Then, the result is convolved with h2(t)
Then, the next result is convolved with h3(t).
The filters are "cascaded" or "in series".

If the filters operate on the data in sequence without delay, then the 
composite filter will have a unit sample response (assuming that all the 
filters have length N):

hc(t) = h1(t) + h2(t-N) + h3(t-2N)

for h1(t) = h2(t) = h3(t) = [1 1 1]

then the composite with N=3 would be:

h2(t-N) = [0 0 0 1 1 1]

h3(t-2N) = [0 0 0 0 0 0 1 1 1]

hc(t) = [1 1 1 1 1 1 1 1 1]

If the filters are different I'm sure you can see how this would work out...

Note that a cascaded or multipass filter has a unit sample response with a 
length equal to the sum of the lengths of the unit sample responses of the 
individual filters.  So, if the lengths are equal at N and the number of 
passes or stages is M, the length is M*N.
It may well be possible to get better filtering characteristics with a 
length M*N filter than by simply repeating the same filter M times.  Thus 
the suggestion re: Parks-McClellan or any other good filter design program.

Fred 

Fred, thanks for your comments once again

I'm using a 3-stage or N-stage filter where each stage would be a
"pass" on the data as you indicated.  And I just checked a few
things related to your suggestion that the filter being equivalent
to one M*N.  The results suggest this is correct.   However, one
of the benefits of the multi-pass is that I do not have to wait M
times as long to accumulate data to start the process.

I've also noticed that most treatments to the ends have an effect
similar to shortening the filter length and is not adding value.  So
I have no further issues with Parks-McClellan or treatment to
the ends.

My only other issue is related to tracking and control technique
used in real time signal processing.  To test how my FIRs behaves
I've noticed that is is very important to set up a process where it is
used on a row by row basis.  For example if I have a time series
that is accumulating at the rate of several data points per minute
it would not take long before the series has several hundred
data points.

Now the simplest solution appears to be to associate each signal
with an entry time and to avoid running the process on anything
other than the filter window --- otherwise the coefficients will
change given how the smoothing process could different triggers
signals as the data is repeated being process.

I'm looking for more details to confirm this the solution I mentioned
is correct and also for the typical solutions in DSP that help control
real time signal processing.


> That is about all it will do for you.  It has nothing at all to do with
> "ends" unto itself.  That's something you will have to deal with separately.
>
> It's unclear if you are using the same filter 3 times or 3 different filters
> for the multipass.  In linear systems context I would prefer to call it a
> 3-stage or N-stage filter where each stage would be a "pass" on the data and
> might look something like this:
>
> h1(t), h2(t) and h3(t) are the 3 filters.
> First the data is "passed", i.e. convolved with h1(t).
> Then, the result is convolved with h2(t)
> Then, the next result is convolved with h3(t).
> The filters are "cascaded" or "in series".
>
> If the filters operate on the data in sequence without delay, then the
> composite filter will have a unit sample response (assuming that all the
> filters have length N):
>
> hc(t) = h1(t) + h2(t-N) + h3(t-2N)
>
> for h1(t) = h2(t) = h3(t) = [1 1 1]
>
> then the composite with N=3 would be:
>
> h2(t-N) = [0 0 0 1 1 1]
>
> h3(t-2N) = [0 0 0 0 0 0 1 1 1]
>
> hc(t) = [1 1 1 1 1 1 1 1 1]
>
> If the filters are different I'm sure you can see how this would work out...
>
> Note that a cascaded or multipass filter has a unit sample response with a
> length equal to the sum of the lengths of the unit sample responses of the
> individual filters.  So, if the lengths are equal at N and the number of
> passes or stages is M, the length is M*N.
> It may well be possible to get better filtering characteristics with a
> length M*N filter than by simply repeating the same filter M times.  Thus
> the suggestion re: Parks-McClellan or any other good filter design program.
> 
> Fred

"Newport" <edwards2107@comcast.net> wrote in message 
news:1159036127.156295.214220@m73g2000cwd.googlegroups.com...
> Fred, thanks for your comments once again
>
> I'm using a 3-stage or N-stage filter where each stage would be a
> "pass" on the data as you indicated.  And I just checked a few
> things related to your suggestion that the filter being equivalent
> to one M*N.  The results suggest this is correct.   However, one
> of the benefits of the multi-pass is that I do not have to wait M
> times as long to accumulate data to start the process.
>
> I've also noticed that most treatments to the ends have an effect
> similar to shortening the filter length and is not adding value.  So
> I have no further issues with Parks-McClellan or treatment to
> the ends.
>
> My only other issue is related to tracking and control technique
> used in real time signal processing.  To test how my FIRs behaves
> I've noticed that is is very important to set up a process where it is
> used on a row by row basis.  For example if I have a time series
> that is accumulating at the rate of several data points per minute
> it would not take long before the series has several hundred
> data points.
>
> Now the simplest solution appears to be to associate each signal
> with an entry time and to avoid running the process on anything
> other than the filter window --- otherwise the coefficients will
> change given how the smoothing process could different triggers
> signals as the data is repeated being process.
>
> I'm looking for more details to confirm this the solution I mentioned
> is correct and also for the typical solutions in DSP that help control
> real time signal processing.
>
>

I'm bottom-posting as is our habit on comp.dsp.....

I don't see what difference it makes in terms of when you can start 
processing.  After all, the real issue is when you are *finished* 
processing, no?

If the processing is much faster than real time or the data input rate then, 
yes, you need to have all the necessary samples available - in the limit if 
the processing is going to continue without any interrupts.  If it's "batch" 
processing then, yes, you need to have all the necessary samples available. 
But, how is that different if you already have the batch size set?

It takes just as long to process either way I believe.

I don't understand your "row by row" comment....  I sense you have questions 
about the relationship between sampling, buffering and processing but your 
concerns and constraints aren't very clear to me.  A few hundred samples 
seems small as buffer sizes go....

What you may want to do is decide how much processing overlap there should 
be if you're doing batch processing - i.e. processing on chunks of samples 
rather than doing continuous processing sample-by-sample.  That will tell 
you something about your timing relationships, buffer sizes, etc.

Here is one continuous way to do it:

Get a sample
Treat it as a new sample into the filter.
Compute one filter output sample.
Get another sample......

In this way there is only one starting transient and then continuous output 
that is already preconditioned to the "end" / beginning.
If you can process faster than real time then this *may* be a good way to do 
it.  And, maybe not.  Nice if the sample intervals are uniform.

Fred