Home > Tracks >

Pragmatic Methods to Decide Filter Requirements

Chris Bore - Watch Now

While digital filter design – given a filter specification - is very well covered in numerous works, the essential practical question of how to arrive at the filter specification from the application is largely ignored: so the practicing engineer is faced with a well developed design methodology, but very little information to guide in specifying what to design. Similarly, there is little information available to guide decisions on the hardware platforms that are suitable to implement such a specification – including balancing issues such as numeric precision, speed, cost and power consumption – to assess whether the requirement may be met in a cost effective way: so the practicing engineer has limited guidance in deciding whether the application requirement may be met at all given practical constraints. The result is that engineers have limited ability to quickly assess whether a filtering requirement can be met: and digital filters very often under- or over-perform and are often implemented on needlessly costly or power-hungry hardware platforms. This talk addresses these twin gaps in the filter designer’s toolbox and outlines, with specific methods and examples, how the specification for a digital filter may be arrived at from consideration of the application aim and requirement. It also describes, again with specific methods and examples, how to arrive at a specification for the hardware platform necessary to implement such a filter. It does not address the issue of designing such a filter, which is very well covered in numerous texts elsewhere.

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

SlightlyChaotic
Score: 0 | 4 weeks ago | 1 reply

Hi Chris, thanks for the talk, I'm listening for the second time. I never thought beyond the FFTs I was told to implement until now! This is very eye-opening for me.
I have a mathematics background, but not an engineering one, so I have a question, if it's not too late. at about time 14:41 of your presentation. You take 7 mV RMS and 200 Ohms of resistance and come up with 35 uW of power. But the formula is (Vrms^2)/R = Watts. That tells me (0.007)(0.007)/200 = (49x10^-6)/(2x10^2) = 24.5x10^-8 W
Can you help me with this? Thanks.
Actually, looking more, it looks like a question of whether you square the Vrms, or not, to get power. There seems to be conflicting definitions of RMS on your slide, unless I am missing something.

ChrisBoreSpeaker
Score: 0 | 3 weeks ago | no reply

This is one of those times when I 'thank' you for pointing out a mistake :-)
The equations on the slide are correct (P=Vrms^2/R) but the numbers are wrong. The arguments up to the numbers, and after the numbers, are valid but there is a disconnect where the equations are evaluated numerically. I don't know why this was but I will drill back through the slides from which I simplified this talk to find out.

'Thank you' :-)

KhaledDSP
Score: 0 | 4 weeks ago | 2 replies

Thanks a lot for this interesting presentation that brought me back to the basics.
I have a short question here, why did you choose to estimate an FIR filter rather than an cascade of biquads ?

ChrisBoreSpeaker
Score: 0 | 3 weeks ago | no reply

I see you found the answer: yes, IIR filters aren't really susceptible to estimating quantization effects because they are recursive so the errors can grow, and are signal dependent. That doesn't mean you shouldn't consider or use them - just that you should simulate rather than estimate to quantify arithmetic precision - which puts you in the situation of having access to a computer, whereas I chose to think about a telephone or elevator conversation. The FIR being in general less efficient also means it is a safe estimate - again, apart from arithmetic precision.

KhaledDSP
Score: 0 | 4 weeks ago | no reply

I just heard the answer in the Q&A session. IIRs are indeed non linear and can be unpredictable but modern calculation techniques can guaranty a stable IIR as long as coefficients are not changing in real time, especially in the audio domain which I come from.

Stephane.Boucher
Score: 1 | 1 month ago | 3 replies

I am curious to know what attendees think of the speech to text feature that Chris used for his presentation. Do you think this is helpful and something other speakers should consider for future conferences?

Vladimir.Nesterov
Score: 0 | 4 weeks ago | 1 reply

Even though these automatic subtitles mess up DSP terminology, they helped me few times during the video.

ChrisBoreSpeaker
Score: 0 | 4 weeks ago | no reply

Yes, but I quite liked the alchemist angle to designing philtres :-)

suds
Score: 0 | 1 month ago | no reply

I normally prefer subtitles, but I found these automated ones a bit distracting due to delay / inaccuracy.

pb
Score: 0 | 1 month ago | no reply

Very helpful :)

HardRealTime
Score: 0 | 1 month ago | no reply

Even late at night (11pm) your talk kept me engaged

john.edwards
Score: 1 | 1 month ago | no reply

A great resource for anyone new to DSP.
Thanks Chris,
John

Moses
Score: 0 | 1 month ago | 1 reply

Very insightful presentation. I come from a digital communications background where we use software-defined radios with an already-decided bit depth and processing power. I wonder if it were possible to reuse the techniques you presented in my domain.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

It's very common for bit depth and hardware to be pre-determined. That can be for good reasons - but it is worth thinking it through because cost reductions or other efficiencies may show up. In SDR I think it is often that someone used a hardware platform once and that sort of drifted into becoming a standard - also because that platform was already instrumented with appropriate peripherals, which is something I did not address.

CoryClark
Score: 0 | 1 month ago | 2 replies

Great talk, nicely done Chris. Love all the "figures of merit" for estimation purposes. Will slides be available for download?

Stephane.Boucher
Score: 1 | 1 month ago | no reply

Check on the left-hand side, under 'Slides'.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Yes they should be on line now

Leonard
Score: 0 | 1 month ago | 1 reply

Chris , it would be nice if the slides had talking points on them as well as just the pictures

ChrisBoreSpeaker
Score: 0 | 1 month ago | 1 reply

I can provide that to Stephane - will try to do so early next week

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Actually, I see I already did - the downloadable slide set is interspersed with text points.
For more depth and detail, watch Taylor and Francis... :-)

woodpecker
Score: 0 | 1 month ago | no reply

Excellent talk, Chris.
Every DSP beginner should watch this one !
Many thanks

SlightlyChaotic
Score: 0 | 1 month ago | no reply

Thanks very much

Danilo
Score: 0 | 1 month ago | 1 reply

Cool thing.
I will definitely need to go thru this session once again, with slides on the second screen.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Me too :-)

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply
ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Thank you all for watching...

SanjeevSarpal
Score: 0 | 1 month ago | 1 reply

Regarding implementation: modern processors have come a long way since the days of the 8051! Using Arm's CMSIS-DSP library and a modern C complier, the challenge of efficient implementation on a Cortex-M device has been greatly simplified. These modern mcus are low power and DSP ready. Even the new Cortex-M55 can apparently do ML! This means that we can focus on the application, and not have to break our heads with an effcient implementation.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

That's true sometimes - but I am usually looking at devices to cost a few dollars at most, and often to run on battery for weeks: so there the cost efficiencies do come into play very much. I agree that when cost or power consumption or size are not critical considerations then we can relax. Also on fast systems - ultrasound or radaio at 250 MHz sample rate for example - computation speed again becomes significant.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Correction: it's not the state variables so much as the accumulated MAC for each sample...

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Strictly speaking, 16 bit arithmetic - as we will see later when I look at DSP processors with extended arithmetic precision

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

I set the coefficients to have a bit depth similar to the sample

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

The sample bit depth is determined by the input SNR...

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

I also used to find it quite cool to leap out at students with a brief requirement and ask them to guesstimate things like filter bandwidth, processing gain, on the spot - a bit like times tables or mental arithmetic that you ought to be able to do in your head

SanjeevSarpal
Score: 0 | 1 month ago | 1 reply

Agreed! The good old sanity check is a must that many overlook.

stephb
Score: 0 | 1 month ago | 1 reply

FYI: At the top right of a post in the forum, you'll see a curved arrow. This is a reply button to be used when replying to someone's else question or comment.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

cool

ChrisBoreSpeaker
Score: 0 | 1 month ago | 1 reply

Yes, I agree - here I am dealing with quick estimates, for example during a phone call or conversation or meeting: also, these offer a sanity check on design tools.

stephb
Score: 0 | 1 month ago | no reply

FYI: At the top right of a post in the forum, you'll see a curved arrow. This is a reply button to be used when replying to someone's else question or comment.

SanjeevSarpal
Score: 0 | 1 month ago | no reply

Certainly some useful tips, Chris! I agree that translating the real world specification to a DSP specification is a must. However, there are several design graphical tools available that can speed up the whole process, as my experience has been that the filter specifications need to be fine-tuned to the dataset. In many cases it's not always apparent at the beginning as to what design prototype (IIRs) you need.

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

An even simpler estimate is to use the fact that a filter's duration is about the inverse of its bandwidth: T = 1/ENBW - so at the sample rate Fs we can estimate how many coefficients from the sample interval dt=1/Fs: thus N = T/dt = Fs/ENBW

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

Here, for simplicity, I am using minimal estimates to avoid having to always refer to headroom - in realioty we would bear in mind headroom at all stages

ChrisBoreSpeaker
Score: 0 | 1 month ago | 1 reply

Here, I am assuming the 3 mV noise cited earlier.

Stephane.Boucher
Score: 0 | 1 month ago | no reply

For people who will be watching 'on-demand', I'd suggest adding in your comment a reference to the time in the video where your comment applies. For example: @21:54, ...

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

As with the DFT, a filter collects noise only in its band ENBW so processing gain for a filter is ENBW/BW

ChrisBoreSpeaker
Score: 0 | 1 month ago | no reply

In this specification, I omitted the noise....

Stephane.Boucher
Score: 0 | 1 month ago | no reply

Don't forget to join Chris for a live Q&A about this talk at 8:30 EST. The link to the zoom meeting can be found in the left column on this page: https://www.dsponlineconference.com/session/Live_Discussion_Pragmatic_Methods_to_Decide_Filter_Requirements

OUR SPONSORS