Basic info needed regarding filters (FIR)

Google "fir filter."

Quickie starter dose:

A signal, like a sound, can be expressed as a series of samples, each an n-bit integer. CD music is stored this way.

A filter changes the math. A lowpass filter reduces high frequencies, cuts the treble. If you have a stream of samples coming in, you can store the last N of them in a list and process the list to do all sorts of filtering.

A Finite Impulse Response (FIR) filter takes the list of recent samples, multiplies each one by some individual factor, and sums them to make the output.

Filter_output =

(Latest sample * Factor1) + (1st oldest sample * Factor2) + (2st oldest sample * Factor3) +

etc, as far as you want to go.

One simple lowpass filter is a boxcar integrator, where all the factors are 1. The output is just the sum (or average, if you prefer) of the last N samples.

OK, google+wikipedia will get you the gory details. Good luck.

Coffee's ready.

John

"Finite" because if you kick it with an impulse (one lone non-zero sample in a long string of zero samples) the output only lasts for a finite period of time.

Contrast this to the Infinite Impulse Response (IIR) filter which has feedback, and whose response to an impulse is, theoretically at least, infinitely long.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

One of my guys was telling me about the new-new thing, the "wave digital filter." That's a simulation of a real physical filter, like an LC or a system of coupled masses, like a Collins mechanical filter or some such. The key difference here is that every coupling is bilateral, which gives the filter the quasi-magical sensitivity benefits that passive LC filters have.

I have for a long time been designing integrator-based "IIR" analog lowpass filters, state-variable and biquads, and then simulating them with integer math in a uP, in embedded systems. That's a class of filters you don't see much in the books, but are efficient resource-wise and work well, and tend to have reasonable coefficients that can usually be done with just shifts.

John

There was an article on the basics of FIR filters in a recent* Circuit Cellar magazine article.

*Within the past couple of months.

--
Paul Hovnanian	paul@hovnanian.com
-----------------------------------------------------------------------
Procrastinators: The leaders for tomorrow.

It is certainly possible to do digital filters which work like a Spice simulation of analog filters. It is nothing wrong about this approach although it is very inefficient and prone to the specific numeric problems.

If the coefficients are done by shifts, most likely it is a dull fulter with very loose requirements.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Well, this just works, and seems fairly efficient to me:

.SBTTL . ANALOG LOWPASS FILTERS

; INPUT SAMPLES ARE TAKEN AT THE 139-HZ RATE AND SOFTWARE LOWPASS ; FILTERED. THE FILTER IS A 4-POLE, STATE-VARIABLE (INTEGRATOR-BASED) ; GADGET WITH A 'TRANSITIONAL' (EG, HOMEBREW) TRANSFER FUNCTION.

NODE 1 NODE 2 NODE 3 | | | IN

-->--(+)--[K1:INT]---(+)--[K2:INT]-->--(+)--[K3:INT]---(+)--[K4:INT]-->--OUT | | | | | | | | | | | | | ^---(-1)--- | | ^---(-1)--- | | | | | | | | | '------

Here is the basic realpole filter which is simpler and appears to have almost identical response:

const u8 order = 4;

s32 LPF(s32 x) { static s32 z[order];

for(u8 i = 0; i < order; i++) x = z[i]+= (x - z[i])>>6;

return x; }

Making digital filter as the simulation of an analog filter is rarely a good idea.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

This seems like an odd assignment. Unless this is a class in FIR filter design, the tap coefficients should be given to you. Seems to me you will need to know about full adders at a minimum, assuming the tap coefficients are just a bit or two.

For N wide data and 4 taps, you need 4 N wide D ffs. The data is run from register to registier like a FIFO. Data is pulled from each register, multiplied by the tap coefficient, then summed. Unless you are going to build a stupid amount of logic, the multiplications will probably have only one or two bits, so the multiplies are really additions with the data properly shifted. There are overflow issues to consider.

I've sold over 3000 of the temperature controllers that use this filter. So why is it not a good idea? Why so dogmatic?

More important, my filter has comments and yours doesn't.

John

McDonalds serves somewhat 10 billion meals per year. But this fact doesn't make those meals taste any better or worse :)

I am sorry if you didn't understand 3 lines of trivial C code without comments. It would be a good idea to do some learning before suggesting the advanced digital filter topologies...

VLV

Selling things for high prices to high-end customers, in volume, for years, bug-free, means we're doing exactly what we want to do. Any other criterion for engineering quality is, literally, academic.

I've made a solemn vow to never code in C. But comments don't explain code, comments explain what code is for and what it does. Your filter is just a heap of code. I have no idea what it's response is like, and would have to analyze or simulate it to determine that.

So, what is its frequency response?

John

On a sunny day (Sat, 24 Nov 2007 09:07:35 -0800) it happened John Larkin wrote in :

Any particular reason?

Why whining about the Evil Empire of Bill Gates then?

Yes. C++ is lot better.

Here:

1/64 H(Z) = (---------------) ^ 4 63 1 - --- Z^-1 64

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Mostly because it looks like monkeys with typewriters. And because I like bare metal programming, where I'm in control of every byte of data and every byte of code.

I spent a couple of hours yesterday reprogramming the periodic interrupt structure of an embedded thing I'm working on. Most of the time was figuring out the ghastly TPU programming, where the vectors would be, the timing math, led blink patterns, associated user serial commands, stuff like that. The time to do it wouldn't matter much whichever language I coded in, and I spent more time typing comments than typing code.

Uncommented C, or any other uncommented program for that matter, must be literally decoded, and often simulated, before anyone but the author can understand what it does or wht it does it. Six months later, he won't be much better off than a stranger.

I dislike mostly the culture around C. Vlad's example is a good case. It's as terse as possible, as C was designed to be. Compare that to my assembly code, which is deliberately opened up for visibility, not to mention unfolded for speed.

John

Because it's slow, bloated, and bug-ridden, from a company run by sociopaths who crush competition out of sheer ruthlessness.

Funny! I write apps that run in, typically, 4-6 kilobytes of eprom and

2K of ram, manage a few FPGAs and a VME or serial/ethernet interface, run thousands of interrupts per second, and have guaranteed response times in the 100 usec sort of range, 100% of the time. And never crash.

So, what is its frequency response?

John

I think that is just familiarity. I got the gist of the C code straight away, without really needing to think about it. I haven't written CPU32 code for ~15 years. So with assembler you need the comments just to figure out *what* the code is doing. Whereas with simple C code, the comments tell you *why*, and what the goal is. They can be at a higher level.

--

John Devereux

On a sunny day (Sat, 24 Nov 2007 09:54:13 -0800) it happened John Larkin wrote in :

OK, but to others ASM may look like that. And I started writing with binary actually. Pencil and paper, and byte for byte in an EPROM Was quite good at binary 8080 at one point.

Sure. OTOH if you need to write something bigger, like for example a subtitle editor (that I happened to write) that does audio, video, text, fonts, animations etc... Cis a better solution then binary or ASM, also for the fact there are many libraries one can use. You give up some control of generated code, but gcc is very reliable. You can always look at he generated code if needed.

True, when I program PICS for example I do it is ASM, and those things are often precision things (well in my case, count clockcycles to ge the timing right etc).

Na, you can write C in a very understandable way, but many do not. You can make it as cryptic as you want. Use real variable names that make sense, use spaces, good identination, add comments, but it is like any language, the more you use it the better you read it. Greek looks cryptic to me, but not to the Greek.

Portability, especially with Unix, recompile on an other processor: runs. As available memory increases, each week a new core almost, some Unix like standard exists, porting or rewriting ANM becomes problematic. I know, I have written some programs 3 times for 3 differrent processors.

Is tha twhy yo udo not use Linux? It is written 100% in C.

It was very readable to me,

Well, there is math, there is the implementation of math in software, and in hardware.

I can write a lowpass in Verilog too in one line, would you then draw it as diagram? I think not.

I suppose you could use the bilnear transform to map it into the S domain, then do a spreadsheet to see the response.

Learning basic C isn't that difficult. The object oriented flavor is another story.

Comments explain what code is supposed to do. Whether or not it actually behaves as described is a different matter.

If I don't think that the behaviour of a piece of code is sufficiently clear, my first response would be to consider re-writing the code rather than adding comments.

Of course, that's much more feasible in a high-level language than in assembler.