FIR Cookbook?
in [DSP]
|
From: Rune Allnor on 13 Dec 2006 14:14 Ron N. skrev: > Rune Allnor wrote: > > Compare it to learning how to drive a car. .... > I tend to think of DSP filters as fancy optimizations on > what I attempted to do using a few R's and C's out of > the junk bin when I was a kid. So I prefer to start dirt > simple, and only use fancier methods when a more > optimal solution is desired than some simple and > transparent implementation will provide. A lot of people have that background. Others -- me among them -- don't. In my twisted world, DSP is mathematics applied to solve real-world problems. Whatever connection there is to hands-on RLC cirquits is mainly of historical ineterst, and any analogies quickly become obsolete. Even worse, sticking to obsolete frames of reference inhibit development and insight, and even prevents people from learning the most elementary basics. For instance, I had a very simple idea for a very sensitive target detector for passive sonar. I made a quick'n dirty simulation and made some color plots where I demonstrated how it was easy to trick the "usual" system and slip past undetected. Then I applied my own detector to the same data set and the detector lit up like a christmas tree. I was not able to explain to the people who would have wanted to know about these things, because they were unable to think in terms other than RLC cirquits. Which, of course was why I had succeeded where people who had attempted to do the same the past 40 years had failed: Everybody else worked from sensor models based on RLC cirquits; I worked from abstract mathematical models of the scenario. The situation very quickly became very awkward: I did not want to -- I was, for that matter, not able to -- explain what I had done in RLC terms. The other party sensed that I was alluding to them being incompetent, which was not necessarily my intention. However, the fact remained that I plainly refused to offer an explanation of terms they expected or found reasonable, as well as they were not able to comprehend the explanation I *did* offer. When I taught the sonar 101 course in university, we discovered another weakness with "intuitive" models. In particular, the piezoelectric tranducers turned out to cause big problems. The PZ elements can be expressed as a electric equivalent, involving a "negative capacitance", i.e. a term that appeared as a capacitor but with the oposite sign. The author of our textbook had gone to great lengths to explain the workings of the PZ elements in terms of the electric equivalent. The explanation was pertinent inasmuch as anyone who wants to use those elements will need to use them as part of an electrical system. As a pedagogical tool the electronic equivalent failed. The students did not know enough electronics to understand the equivalent. So we basically presented one model the students did not understand, and then replaced it with another model the students did not understand. Comaprisions between analog cirquits and DSP is like comparing automobiles with horse cars: At one point in time they were necessary, since they related new material to the widely accepted frame of reference. These days both automobiles and DSP have torn firmly away from their resective historical roots, and both comparisions are equally obsolete. Rune
From: Al Clark on 13 Dec 2006 14:15 Jerry Avins <jya(a)ieee.org> wrote in news:MKednSmsG_32th3YnZ2dnUVZ_vPinZ2d(a)rcn.net: > jeff227 wrote: >>> Writing an FIR filter is very easy. It takes a few lines of code. >> >> >> Yes, looping through an array IS easy but that's not designing a FIR >> filter. The key (and the challenge) is coming up with the >> coefficients. There are numerous programs available (like Matlab) >> that can calculate coefficients but I was looking for a routine to >> generate them on the fly at run time. >> >> That's what this thread is about.\ > > I forget. How many filters do you need? Storing the coefficients for a > few dozen might use less memory than the program to calculate them. > One filter with a complex shape might be replaced with a cascade of > simpler shapes, each drawn from a library in ROM. that could reduce > the needed memory even more. > > Jerry I agree with Jerry that its often practical to precalculate coeffiecients and save in ROM since ROM is usually cheap and available. I have done this with literally hundreds of different filters for a product that appears to have variable tuning. I used two different coefficient arrays and started a DMA to transfer coefficients when I was tuning. When the coefficient table was complete, I ping ponged the memory so that the next sample used the new coefficients. In my case all filters were the same length and linear phase. If you are going to calculate on the fly, you were probably want to use a windowing method to calculate the coefficients. This approach is routely discussed in many DSP texts. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
From: Scott Seidman on 13 Dec 2006 14:23 "Rune Allnor" <allnor(a)tele.ntnu.no> wrote in news:1166037249.815688.56110@ 79g2000cws.googlegroups.com: > Comaprisions between analog cirquits and DSP is > like comparing automobiles with horse cars: This is taking an interesting path. I fully agree that DSP stands alone. That said, the analog circuit concepts that a "classical" signals guy might know are nothing more than applied differential equations. If an engineer doesn't "grok" the applied differential equations, then things like the mechanical system describing the piezotransducer you mention will be difficult to grasp. So, IMHO, the modern engineer with any breadth (i.e., who at some point must interface with a physical world) will need to know both fields. As an aside, the negative capacitance amplifier is an everyday tool for neuroscientists who use glass electrodes (not that they understand why, but it makes for interesting conversation). -- Scott Reverse name to reply
From: Rune Allnor on 13 Dec 2006 14:35 Scott Seidman skrev: > So, IMHO, the modern engineer with any breadth (i.e., who at some point > must interface with a physical world) will need to know both fields. Sure. But he needs to learn *without*analogies* throwing spanners in the works. The sonar people did not understand my simple trick, which was based on a very clean analysis of the interaction between physics, the sensor configuration and the maths. They wanted to get the detour via RLC cirquit analogies, that were not at all relevant to the context. Rune
From: jeff227 on 13 Dec 2006 14:52
>If you are going to calculate on the fly, you were probably want to use a >windowing method to calculate the coefficients. This approach is routely >discussed in many DSP texts. Yes. I have now worked up, with all of your help and inputs, exactly what I was hoping to find. It is a very simple Windowed Sinc FIR with coefficients calculated at run time. It maintains the same corner frequency and bandwidth regardless of sample rate (within Nyquist limits). It may not be brilliant or optimal but it works well and is simple and fast to compute. The first "trick" to making it scale to any sample rate was to scale the number of taps. Because nTaps is an integer, the bandwidth and corner frequency will deviate slightly at certain sample rates. These variations are small, however, and not a problem in my audio application. I prefer this approach to pre-calculating and storing coefficients for the simple reason that it will accommodate ANY sample rate, not just the common ones. It also allows the filter cutoff to be moved at run time. |