Re: Does "remez" work for anyone?

[Ozzy Lash]

On Wed, Dec 18, 2013 at 3:26 PM, Mike Miller <address@hidden> wrote:

On Wed, Dec 18, 2013 at 12:58:00 -0800, briankaz wrote:
> Thanks, I can get it to work now too!  This is fascinating.  You'd think if
> a much shorter FIR filter can be implemented than the one the user is
> requesting, remez would at least return SOMETHING!

Well you did ask it for a filter with 1025 coefficients, if it cannot
converge on such a filter then it should throw an error rather than
arbitrarily reducing the filter length, that's not how the algorithm
works.

FWIW, I get a "failure to converge" error from scipy's remez function
with your filter specs, and someone tells me Matlab's firpm also
prints a "failure to converge" error. So I do not think there is a
demonstrable problem with Octave's implementation with this filter
spec. Are you sure you are providing the right values to the function?
Perhaps your filter requirements are simply not suited to the
Parks-McClellan algorithm.

> But now I can at least get back to work...

That is the important part of course :)

--
mike

_______________________________________________
Help-octave mailing list
address@hidden
https://mailman.cae.wisc.edu/listinfo/help-octave

It looks like scipy has an order estimator for remez called remezord that will estimate the order of the filter you need.  I think Matlab has something similar.  The scipy implementation is at:

https://github.com/thorstenkranz/eegpy/blob/master/eegpy/filter/remezord.py

One of the methods is "kaiser".  I'm not sure if it is the same as the kaiserord.m from the signal processing package.  Using kaiserord.m for your filter, I get:

octave:34> kaiserord(f(2:3),[1 0],.0000001)
ans =  505

(although the deviation argument is just a guess based upon your weights of 87 and a million)

Bill