IIR filter order
in [DSP]
|
Prev: volksfürsorge, rechtschutzversicherung, beruf versicherung, krankentagegeld versicherung, selbständige versicherung, privathaftpflicht,
Next: Difference between CDMA pilot channel acquistion and tracking
From: Rune Allnor on 26 Feb 2010 09:29 On 26 Feb, 15:17, Grant Griffin <nob...(a)example.com> wrote: > Rune Allnor wrote: > > On 26 Feb, 14:23, Grant Griffin <nob...(a)example.com> wrote: > > >> Think of this from the user's and programmer's point of view. The user > >> would like to be successful almost all of the time when working within > >> the specified limitations. So, the programmer would like to define some > >> sort of simple limitations which the user will be successful within. In > >> that vein, ScopeFIR's Parks-McClellan design is explicitly limited to > >> 16384 taps even though there is no intrinsic limitation on that > >> internally - it's just that PM designs often fail with a larger number > >> of taps. > > > So what? > > > There could be any number of reasons why any algorithm > > might fail. A lot of them have to do with the accuracy > > of the binary represnetation of numbers, while others > > might have to do with sensitive and/or oversimplified > > algorithms and what not. > > > The statement "PM designs fail for orders larger than N" > > might rely as much on such implementation-dependent > > factors, as on any intrinsic property of the algorithm > > itself. > > Hi Rune, > > It's good to hear from you. I guess I should be more specific. There > is an unstated premise in my point that I am using 8-byte IEEE > arithmetic, since ScopeFIR is implemented on Windows using a Microsoft > compiler that provides that as the most precise floating-point data > type. It was not intended as a universal statement for those (few) of > you who have more precise numeric representations to work with. Well, I understand that you want to use what resources you have. But do count in the fact that some of your users will be concerned about fixed-pt formats, limiting cycles and all that stuff. > > Unless you have tested a number of designs and measured > > statistics to support your claim, I'd suggest you leave > > the question open. > > If it helps, all of this is based on my measurements on the > aforementioned system. And that's after I tweaked the Parks-McClellan > algorithm to work on a larger number of taps - the original > implementation fails at a much smaller number of taps. > > > Instead, implement tests to see if the > > algorithm converges and / or the design meets the spec. > > That way you can inform the user about what *actually* > > happens, without imposing ad hoc restrictions. > > I'm not sure that you're thinking of this from the typical user's point > of view. .... > I guess it depends on your intended user. My products are intended to > be easy for the novice to use while being highly useful to the seasoned > pro, on a daily basis. Those are contardictions in terms. The novice usually wants something that just works, while the pro every now and then wants something that pushes the limits. If you want to serve both, you really need to think very cautiously. The novice don't want too much leeway; the pro don't want too many restrictions. > Obviously, that's a bit of a balancing act. So, > sometimes we have to save the user from himself, though sometimes not. > For example, I personally feel that any user who creates a FIR with > 16384 taps should rethink their design - I rarely use more than 256 or > 512 before going to a multirate design. However, there might be cases > where a seasoned pro has reasons to use many thousand. So I let the > novice do that, too. > > My theory has always been that users prefer something that works > reliably to something that doesn't, even if the latter has more > features. In this case, the feature is the maximum number of taps. > > Imagine that Word would let you open a document with an unlimited number > of pages, but would usually fail if that number of pages was greater > than 16384. So the Word folks might set a limit of 16384 pages. The > causual user would never have a document with 16384 pages so he would > never experience this limit. The seasoned professional who tried to > open a document with more than 16384 pages and received a message about > the limitation probably would understand that he should break his > documents into a set of smaller documents - like the Encyclopedia > Britannica folks do. ;-) Once upon a time somebody though that 640 kBytes of RAM was more than enough for computers... Rune
From: Vladimir Vassilevsky on 26 Feb 2010 10:57 Grant Griffin wrote: > I'm finally about ready to release an IIR filter design program called - > you guessed it - ScopeIIR (TM). That's great to hear. One more useful program. > It currently supports the basic design types of Butterworth, Chebyshev, > and Elliptic. Rather then supporting textbook types, it would be good to have design by brute force optimization, FDLS with optimization of parameters, FDLS design to minimum phase, linear phase approximation. > I'm trying to finalize the default and maximum IIR filter > order that the program will support. ???? Do you have a business plan on charging premium if someone needs anything different from default or higher then maximum ? > To help me do that, please tell me > about your experiences with IIR filter order, assuming the above types > and implementation via biquads, where applicable: > > - Minimum order: (I assume 1) = 0 > - The typical order you use for most problems = 2 > - The maximum order you've ever used in a real system = 64 > - The maximum order that you consider feasible to design using 8-byte > IEEE floating point ("double") > - The maximum order that you consider feasible to implement in various > numeric formats. I'm particularly interested in 8-byte and 4-byte IEEE, > and any fixed-point formats you've used (please specify). That entirely depends on the pole/zero positions wrt unit circle; It would be useful if the program will show what you are getting as far as design accuracy of the response and the quantization noise floor. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Al Clark on 26 Feb 2010 12:58
Grant Griffin <nobody(a)example.com> wrote in news:5fbdd$4b87cb38$407e2ca9$5534(a)EVERESTKC.NET: > steveu wrote: >>> I'm finally about ready to release an IIR filter design program called >>> - you guessed it - ScopeIIR (TM). >>> >>> It currently supports the basic design types of Butterworth, >>> Chebyshev, and Elliptic. I'm trying to finalize the default and >>> maximum IIR filter order that the program will support. To help me do >>> that, please tell me about your experiences with IIR filter order, >>> assuming the above types and implementation via biquads, where >>> applicable: >>> >>> - Minimum order: (I assume 1) >>> - The typical order you use for most problems >>> - The maximum order you've ever used in a real system >>> - The maximum order that you consider feasible to design using 8-byte >>> IEEE floating point ("double") >>> - The maximum order that you consider feasible to implement in various >>> numeric formats. I'm particularly interested in 8-byte and 4-byte >>> IEEE, and any fixed-point formats you've used (please specify). >> >> That seems a slightly odd set of questions. The main driver for word >> length is not the order of the IIR filter, but just how low in the band >> the poles and zeros sit. >> >> Steve >> > > Thanks for your input, Steve, but I guess I'm looking for something a > little more concrete. Please note that all of these questions ask for > experiences and opinions rather that an exact mathematical answer. For > example, the question of what is the maximum order that you've ever used > is answerable: what _is_ the maximum order that you've ever used? (I > never thought comp.dsp would be short of unsubstantiated experiences and > opinions. ;-) > > Think of this from the user's and programmer's point of view. The user > would like to be successful almost all of the time when working within > the specified limitations. So, the programmer would like to define some > sort of simple limitations which the user will be successful within. In > that vein, ScopeFIR's Parks-McClellan design is explicitly limited to > 16384 taps even though there is no intrinsic limitation on that > internally - it's just that PM designs often fail with a larger number > of taps. > > Of course, the possibility exists that the user could torture-test > ScopeIIR with an extreme design (either accidentally or on purpose) and > then the design and/or implementation process would fail even within the > specified limits on IIR filter order. > > So, I guess I'm looking for parameters that cover the common experience. > For example, the question of what order you have typically used is > needed to fill in a default value of order - which the user can change, > of course. So what might such a default value be? I'm currently using > 4. > > thanks, > > Grant I think you should have provisions for quantization of at least the following: floating point: 32 bit IEEE 40 bit IEEE (SHARC) 64 bit IEEE fixed point: arbitrary length to 64 bits It is not hard to write DF1 in fixed point with double precision. Here is an ADI ap note: http://www.analog.com/static/imported-files/application_notes/EE270v01.pdf You should then calculate the actual responses with the quantized values. Ideally this could also reflect filter topology at least for direct form biquads. Response with DF1 with 1st order error shapping would be nice as well. This would let you design a filter and actually know how well it will work. Al Clark www.danvillesignal.com |