DSP FIR filter component coefficients

[canary_wharfe]

Just wondering why the number of coefficient taps is limited to 12? Surely for reproducing steep band limited filters without artifacts and a low noise floor we need to use many more coefficients than 12. Some of the filter design programs I've seen required as much as a 100 or more coefficients. These are useable in fast 32 bit processors. Is there a reason for limiting the taps to just 12 and is there a way to expand to a higher number?

[BenR]

Hello,

It's mainly down to how many we code in to the properties window. I can certainly add more. How many would you like to see?

Do you need the co-efficients to be editable reather then fixed via properties?

[canary_wharfe]

HI Ben

Thanks for the response.

The number of taps on an FIR is really down to the cutoff of the stopband relative to the passband (filter steepness), the level of attenuation and the amount of ripple tolerated.

As a rule of thumb lets take an audio filter where you want the passband to be 20Hz to 20000Hz and the stopband 25000Hz at which point the signal attenuation is 100dB (which is comfortably within a 16bit audio system). So the difference between the top of the passband and the stopband is 5000Hz. Let's assume our sampling frequency is ball park 100,000Hz (96KHz is a common enough sampling signal). No clever stuff like decimation is used. Using a ball park calculator "Fred Harris' rule of thumb" (which actually comes pretty much close to what you would get with a linear phase filter)

Ntaps=Atten/(22∗Bt)

where:

Atten is the desired attenuation in dB,
Bt is the normalized transition band Bt=(Fstop−Fpass)/Fs,

Fstop and Fpass are the stop band and pass band frequencies in Hz and
Fs is the sampling frequency in Hz.

So Atten is 100 (dB)
Fstop-Fpass is 5000 (ie. 25000-20000)
Fs is 100000 so Bt=5000/100000

Plugging in the figures we get Ntaps = 100/(22*5000/100000) = 90.9 or 91 which is way more than the dozen taps facilitated in the Flowcode properties window. As the sampling Fq goes up then the Ntaps goes up.

Now in real life other techniques (like decimation, selective sampling) all play a part in reducing the number of coefficients needed but the point is I would have thought 12 coefficents is way too small to be useful and 100 coefficients would probably cover most of what people would need to do for basic straightforward filtering. My definition of straightforward filtering is providing a steeper filter with higher attenuation and lower ripple than can be easily achieved in the analogue domain with numerous active op-amp circuits.

I would have thought in order to allow for a higher number of coefficients to be inserted in the FIR properties window box it would be more effective to have a tick box option that allows for "insert / use text file". And then the user can simply have the coefficients listed say as an array in a Notepad text file. Then the Flowcode properties box just asks for the name and path of the stored file. Perhaps it could be linked to a C-code icon that stiplulates the number of coefficients to be sourced from the Notepad array. Or perhaps it's easier to just increase the options box tap number and let the user type the coefficients into the properties. 100 coefficients is a lot of typing and of course the memory buffer of the system needs to be able to handle the processing.

Personally I'm not bothered about having the coefficients editable in the properties box. With that number of taps someone would almost certainly have to use a separate coefficient design application and simulator to graph the shape of the filter in advance. I just want to be able to type the fixed values in to the properties window.

Anyway you asked what I think is a useful number of coefficents and I'm just giving you my two penny worth based on some of the digital filter coefficient simulation calculators I have used. I'll let others chime in and give their two penny worth.

[BenR]

Hello,

Great info there thanks that's much appreciated.

I'll have a play and see what I can do to. Maybe something like a comma seperated text field?

Relying on external files is a good idea but can potentially get messy, especially if things need to change on the fly.

Hmmm

[canary_wharfe]

Hi Ben.

I've just had a look at the GUI user guide for the FIR section of ASN Filter Designer which is a heavyweight digital filter design program and I have copied some relevant parts (below) referring to the number of taps. You will see that it suggests that my earlier input of 100 taps is probably the bottom end of engineering requirements. As a point of reference note that this DSP FIR design tool and simulator can construct up to 499 filter orders and 200 coefficients is probably more than enough for streaming applications.

TBH If I was looking at making this area of Flowcode more conducive with fitting in with other engineering tools involving standard filter designs on the upmarket ARM and PIC processors (which I think would be well received in educational markets as well) and if you are going to put a bit of work into scaling up the capability of the FIR component, then I would respectfully suggest that you keep your work to the minimum and immediately implement a 200 tap capability into the component. If only to save the hassle of someone later asking you for a 150 node tap if and when you have set the limit at 100. I would be go for the belt and braces approach of max 200 coefficients knowing that in all liklihood you will have covered virtually everything the majority of people would or could achieve with FIR inside a DSP based microcontroller chip. IOW if you are going to make a feature change, do it just once so you don't have to keep revisiting it again in the future. Anything higher than 200 is really getting into the realms of custom high end FPGAs and other specialist applications I would have thought. But again if anyone else has opinions then by all means chime in.

A comma limited table (usually a vertical column of coefficients in the text file) would be ideal if you decide to go down that route.
Of course just extending the Flowcode option box vertically would achieve the same effect, although that does mean a looooong option box window to fit that number of coefficients :_)

Here follows the extract from the ASN Filter Desiner manual

"The FIR (finite impulse response) filter designer is implemented via the Parks-McClellan algorithm, and allows for
the design of the following filter types:
Lowpass
Highpass
Bandpass
Bandstop
Multiband
Hilbert transformer
Differentiator

The Parks-McClellan algorithm offers a degree of flexibility over other FIR design methods, in that each band may
be individually customised in order to suit the designer's requirements.

Filter orders of up to 499 may be constructed (in the professional version), where this is limited to 200 for streaming
audio applications. As with the IIR filters, an FIR's zeros may be modified by the P-Z editor ( Method dropdown list
changes to User defined ), including the ability of adding poles and converting it into an IIR filter - see section
8 for more details.

Features:
> Higher order FIR designs (>100 coefficients): In order to speed up plotting performance, updates to the P-Z chart are
postponed until the left mouse button is released.
> The order estimation of the Parks-McClellan algorithm may sometimes underestimate the filter order
required for the given specifications. Therefore, in order to automatically increases the order estimate
by 2 (overestimation) you may uncheck the minimum checkbox."

[canary_wharfe]

Ben

Decided to create a real integer performance FIR low pass filter this afternoon and thought I would share the results compared with the theoretical floating point coefficients. The integer performance is what you would see in the real world using 12 and 16 bit integer coefficients programmed into a microcontroller. I decided to create a low pass filter with a perfect passband up to 20KHz using 96KHz sampling using a steep stop band shelf going down at 22KHz. The sweet spot in the design tool was with a Blackman Harris window function at 141 taps or coefficients. The filter was able to attenuate all out of band aliasing down to -75dB which actually isn't bad considering that the integer coefficients are actually rounded approximations of the required precise floating point calculations.
It was actually possible to decrease the number of taps and maintain the -75dB level for the 16 bit integer design but reducing the taps simply makes the filter roll off at a more shallow rate. What we get with the 141 taps is a roll off of around 2 to 3 KHz which would be almost impossible to achieve in the analog domain. We get an additional 25dB of attenuation simply moving from 12 bit to 16 bit integers. Anyway I just wanted to share these with you because the filter design number of coefficients had to be somewhere between 100 and 150 taps and this substantiates what I wrote earlier about increasing the number of taps in the Flowcode FIR component.

[canary_wharfe]

Here is the filter spec image

[stefan.erni]

Hi Ben, Hi canary_wharfe

I am also working on filters with my own coefficients. I can create these coefficients with Matlab.
It would be useful if I could insert these coefficients with copy/ paste into a field.

( in the same way as with the Flowcode component webserver managed the HTML page)

regards

Stefan

[canary_wharfe]

Stefan

I love that idea. If Flowcode had a window where we could copy paste the coefficients into then it would be very user friendly. The question then becomes what format should the data be in? Like hex with a leading 0x or a $ denoter or simply plain digits? If entering integer digits we also need to denote negative as well as positive numbers.

[BenR]

Hello,

Thanks for all the input here I really appreciate it and it certainly helps us to deliver a better product.

I've had a go and think I've managed to get somewhere so you can now enter an unlimited number of taps into the FIR and IIR coefficients text fields. Each tap value will add a 32-bit float value into ROM usage and a value matching the filter output buffer size to the RAM usage.

So 100 tap points with a 16-bit output buffer would use 400 bytes of ROM and 200 bytes of RAM.

The coefficients must be entered in a comma seperated format such as

1, 2, 3.5, 4

or

1,
2,
3.5,
4

Have a go and see how you get on. I've checked the generated code looks ok and that it compiles but haven't done much more in terms of in depth testing with it yet.