This column is a “Part 2” and it’ll make much more sense if you read An Excelent fit, Sir! first. Well, I *hope* it will, anyway. In that column, we used Excel’s ‘solver’ functionality to bend a filter transfer function to our will. Or, rather, our *customer’s* will, since he is *much* more important than we are. Extra pop-quiz points for getting the pun in the title…

Recap: we computed a filter for use in flattening out the frequency response of a sensor with a frequency response looking like Figure 1:

**Figure 1**

We ‘turned the response upside down’; extended it (with orders to ‘come back downwards’ again); guessed some filter coefficients, and fine-tuned them with Excel’s solver. The light blue curve in Figure 2 shows what we got:

**Figure 2**

The ‘accuracy’ of our fit is shown in Figure 3. It’s rather wiggly; that just reflects the rather approximate way in which we eyeballed the required frequency response off Figure 1 in the first place.

**Figure 3**

**8% either way, that’s roughly 0.7 dB in real money.**

Now, our customer doesn’t want to buy big, expensive, high quality capacitors to build an active filter with this response (good, all the more of these rare beasts for me, buwahahah). So, having established the principle of optimizing in the analogue domain, let’s look at whether need to make any changes in order to use it to create a *digital* filter – which we’ll be able to implement on the Cypress PSoC 3.

Well, the first thing to do is to choose a sample rate. The noise bandwidth of our system will be dominated by this equalizing filter, whose response falls at 6 dB per octave above about 30 Hz. This means that the output noise will be essentially independent of the amount of decimation that we dial into PSoC3’s highly configurable high-performance delta-sigma ADC. If we set the intrinsic sample rate too high, we’ll use power unnecessarily, and may have to watch for arithmetic issues in the subsequent digital filter (more on that in future columns). If we set the sample rate too low, then the inherent response of the decimation filter may have to be accounted for (er, more on that in future columns too!). This decimation response gives both a slight response fall-off in the passband, and can also result in some residual aliasing; this is typical of all instrumentation-grade delta-sigma ADCs.

Well, we need not worry; if we pick a sample rate of 1 ksps, the droop in the passband is completely negligible, and the falling response of the sensor itself ensures that aliasing isn’t going to be an issue. Another more advanced digital filter design issue called ‘frequency warping’ can also be completely ignored (something for a future column, methinks).

Even-order harmonics of the AC line frequency will cause a modulation of the incident light level (dang! I’ve given the game away, yes, it *is* a PIR sensor). We can address this potential interferer with some extra filtering. So, just because we can, I’ve put in another lowpass filter section designed to be flat up to 10 Hz (our equalization limit), and I’ve also sneakily dropped in a notch (or ‘zero’, as we Filter Wizards tend to call them) at 100 Hz, which is where most of the trouble is going to be, in Europe anyway. I used a ‘Butterworth’-aligned section, which has a dissipation factor of sqrt(2); positioned the 3 dB point out of the way at 20 Hz, and instead of leaving the a2 coefficient at 0, I made it equal to 1/25, which gives a zero at sqrt(25) times the 20 Hz normalization frequency, i.e. 100 Hz. After a final ‘solve’, Excel gives:

We can’t put it off any longer; let’s make that move from the s-domain to the z-domain. A spreadsheet is certainly a nice warm place for the s-to-z transform to hide. If you feel like doing the algebra yourself, just substitute the *bilinear z transform* expression for s:

into equation [1] in the first installment of this article, and do the manipulation. Or, you can go and look it up in Lyons, time-poor engineer-styly (Understanding Digital Signal Processing, 2nd edition, pp 266-267). This gives the coefficients of powers of z in H(z), which translate more or less directly to the actual multiplication factors used in the digital filter sections, depending on the particular topology you use. The Digital Filter Block in PSoC3 can be programmed to implement many different forms of digital filter; we’ll save that detail for another day. What now remains in the last few hundred words is to work out the transfer function, and then run it through a simulator to show that it does indeed do what it “says on the tin”.

So that you can check your own work, here are the coefficients in standard equation form that I ended up with for the three filter sections in table 1 (your optimizations may be slightly different:.

**Table 1**

**The three filter sections in equation form. **

I’ll wheel out trusty LTspice to analyze the filter. The block I use is a z-domain biquad model that is actually built using transmission lines as delay elements. It runs cleanly and quickly in both time and frequency domains. I embed the whole circuit in ASCII schematic form in another worksheet in the Excel file; it picks up the design values directly from the s-to-z transform sheet. Just paste the worksheet back to a text file with .asc extension and it opens straight up with LTspice (Figure 7)

**Figure 7**

And, finally the suspense is over: here’s the response of the final filter (Figure 8). The notch at 100 Hz can clearly be seen, as can the fall to another notch at 500 Hz – half the sample rate – which is characteristic of a digital filter designed with the bilinear transform method:

**Figure 8**

**The final realized response.**

Space limitations mean this could only be a whistle-stop tour through this design approach. I’ll talk more about filter implementations on PSoCs from time to time. What filter problems do you wish *you* could solve in a single chip? – Kendall.