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: Grant Griffin on 25 Feb 2010 22:33 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). thanks, Grant -- _____________________________________________________________________ Grant R. Griffin Publisher of dspGuru http://www.dspguru.com Iowegian International Corporation http://www.iowegian.com See http://www.iowegian.com/img/contact.gif for e-mail address
From: steveu on 26 Feb 2010 00:05 >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
From: Grant Griffin on 26 Feb 2010 08:23 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 -- _____________________________________________________________________ Grant R. Griffin Publisher of dspGuru http://www.dspguru.com Iowegian International Corporation http://www.iowegian.com See http://www.iowegian.com/img/contact.gif for e-mail address
From: Rune Allnor on 26 Feb 2010 08:37 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. Unless you have tested a number of designs and measured statistics to support your claim, I'd suggest you leave the question open. 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. It's not your business, as programmer, to prevent somebody who wants to implement a 670 order Elliptic filter in 8-bit fixed-point arithemetics from doing so. Just include the tests and diagnostics that reports back to the user what he *actually* gets. And let the documentation hint at why these things happen. Rune
From: Grant Griffin on 26 Feb 2010 09:17
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. > > 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. However, that's part of my job. Luckily, I'm fairly pedestrian as far as my DSP design work goes so that isn't too hard for me. > > It's not your business, as programmer, to prevent somebody > who wants to implement a 670 order Elliptic filter in 8-bit > fixed-point arithemetics from doing so. Just include the > tests and diagnostics that reports back to the user what he > *actually* gets. And let the documentation hint at why these > things happen. Are you suggesting that users read documentation? ;-) 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. 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. ;-) > > Rune thanks, Rune, Grant -- _____________________________________________________________________ Grant R. Griffin Publisher of dspGuru http://www.dspguru.com Iowegian International Corporation http://www.iowegian.com See http://www.iowegian.com/img/contact.gif for e-mail address |