Integrator filter with delayless feedback path

[aciddose]

The results in circuit simulation packages are still quite different from the real thing. If you look at Stinchcombe's MS-20 filter study and then at a real MS-20, the resonance looks completely different than his simulations suggest.

he must have really f**ked up because my spice simulations and bench versions of the filter look identical.

[aciddose]

I then proceed to build the same stuff on breadboard, and it turns out that some of my resistors need to be "fine-tuned" by about an order of magnitude (mostly stupid and obvious newbie mistakes, but that's not really the point) before it actually starts working properly... and by the time I get it working nice on breadboard, (and copy the changes to Spice) it no longer works in Spice...

might be the same issue. there are effects that an ideal spice simulation won't simulate for you.

it's like writing a naive SVF in software and expecting it to work. you didn't factor in aliasing, you didn't factor in nyquist, you didn't factor in any of that other stuff and so unsurprisingly it doesn't work.

spice is dsp as well. there are techniques to minimize the effects in some cases, but you're still dealing with all the standard sampling caveats.

in addition to that many spice models don't factor in the behavior of a complete system. from the power source all the way down to the output's destination. you have to factor in loads, interactions and feed-backs throughout the system.

it's also easy to simply use the wrong models. most models of the lm13700 for example aren't designed to aid in simulation of filter circuits. instead, i use four different spice sub-circuits that i designed myself which give far more accurate results in different situations where a specific model is required.

as well as that, spice doesn't factor in manufacturing variations. read your data-sheets. assume worse than worst-case. 200%? i think not. aim for 400%. 500%. go as far as you reasonably can.

some variations are minimized by using the correct circuits. are you feeding the current source pin with a resistor? feed it with a current source and you'll suddenly get the correct results. are the inputs biased? did you bypass the supplies? are the loads correct on outputs?

etc etc...

[Urs]

The results in circuit simulation packages are still quite different from the real thing. If you look at Stinchcombe's MS-20 filter study and then at a real MS-20, the resonance looks completely different than his simulations suggest.

he must have really f**ked up because my spice simulations and bench versions of the filter look identical.

Do you still have that? - Would be interesting to compare your results to our MS-20s

[ralphb]

First of all, I would like to thank everybody who posted in this thread. I learned a lot! So thanks!

I'm left with some questions though:

So, I've tried the bilinear integrators. Using bilinear transformed H(s)=1/s in transposed DF II:

Code: Select all

out = buf + f * in
buf = f * in + out

I've pored over this, but for the life of me cannot figure out where it came from.

I thought the (unoptimized) DF II for a one-pole filter looked like this:

Code: Select all

y[n] = a0 * (x[n] - b1*w[n-1]) + a1 * w[n-1]
w[n] = x[n] - b1*w[n-1]
with x[n] = in, y[n] = out, w[n] = buf, as far as I understand neotecs posts.

Doing the bilinear transform for H(s) =1/s I get

Code: Select all

a0 = 1/(1+c)
a1 = 1/(1+c)
b1 = (1-c)/(1+c)
with c = cot(w*T/2)

Which is very different from neotecs result. Perhaps I am overlooking something? Or maybe the integrator is not a filter, i.e. has a different DF II implementation?

Also, this discussion has made me realize how much I don't know about one-pole filters. Where did you guys learn about them? My DSP books don't really have what I need to understand the stuff in this thread.

[aciddose]

The results in circuit simulation packages are still quite different from the real thing. If you look at Stinchcombe's MS-20 filter study and then at a real MS-20, the resonance looks completely different than his simulations suggest.

he must have really f**ked up because my spice simulations and bench versions of the filter look identical.

Do you still have that? - Would be interesting to compare your results to our MS-20s

i don't have any of the models anymore since i stopped playing with the korg-35-based filters and modified the design a bit to produce my own variation without many of the issues of the korg-35.

a few of the very significant factors are in the type of transistors used, type of capacitors (i don't remember which match the ms-20), type of opamp, power supply, input source and output load. things get a lot more interesting when you have to consider the fact some capacitors exhibit leakage, non-linear behavior based upon input voltage and so on.

when you model the filter itself you generally chop that block out of the circuit. if you want to get realistic results assuming you use a signal generator in the circuit, an ideal supply and a high-impedance amplifier to buffer the output, you need to do that in real life too.

the actual circuit in the ms-20 definitely does not meet any of these criteria. the input and output are heavily loaded, the power supply can't keep up with the circuits in there especially the oscillators. the transistors are obscure japanese types.

also, when you're using a time-base like 1us, you need to keep the frequencies you're dealing with very low such as 50-500hz. if you want to get accurate results at frequencies like 25khz you need to use much smaller time-slices. it's also a bad idea in linear circuits running at high frequency to use variable time-slices. in addition to that, some of the more simple simulation methods cause high-frequency oscillation which will simply destroy the high-frequency accuracy of the simulation. so you need to use more advanced methods, the simplest of which would be high-order gear integration. most common spice simulators do not offer the advanced features required to model non-linear elements in linear circuits at high frequencies.

because of the high gain of the vcf and vca the opamp is very important. even the 4558 tends to filter too much of it's own feedback away and results in cuts and peaks in the output. the spice models for such parts are not entirely accurate, they're designed to be very simplified and very fast. when i modeled the korg-35 circuits and bench-tested against the simulation i had to use discrete opamp models i built myself, tweaked to match the bench circuits. i never have bothered to tweak transistor/diode models and so even though i'm perfectly satisfied with the results i got then, you may not. i don't know how much accuracy you're looking for.

[neotec]

I've pored over this, but for the life of me cannot figure out where it came from.

I thought the (unoptimized) DF II for a one-pole filter looked like this:

Code: Select all

y[n] = a0 * (x[n] - b1*w[n-1]) + a1 * w[n-1]
w[n] = x[n] - b1*w[n-1]
with x[n] = in, y[n] = out, w[n] = buf, as far as I understand neotecs posts.

Doing the bilinear transform for H(s) =1/s I get

Code: Select all

a0 = 1/(1+c)
a1 = 1/(1+c)
b1 = (1-c)/(1+c)
with c = cot(w*T/2)

Which is very different from neotecs result. Perhaps I am overlooking something? Or maybe the integrator is not a filter, i.e. has a different DF II implementation?

Also, this discussion has made me realize how much I don't know about one-pole filters. Where did you guys learn about them? My DSP books don't really have what I need to understand the stuff in this thread.

So...

Code: Select all

Having a 1 pole integrator (not a lowpass filter):

        1
H(s) =  -
        s

Assuming:

        a0*s + a1
H(s) =  ---------
        b0*s + b1
        
Doing the bilinear transform you get:

    1   z - 1
s = - * -----
    k   z + 1

k = tan(PI*fc/fs)

       (a1*k + a0) + z^-1 * (a1*k - a0)
H(z) = -------------------------------
       (b1*k + b0) + z^-1 * (b1*k - b0)

so our digital coeffs are:
    
a0' = 1*k + 0 = k
a1' = 1*k - 0 = k
b0' = 0*k + 1 = 1
b1' = 0*k - 1 = -1

Transform into DFII (transposed) (divide all coeffs by b0'):

output = x[0] + input * a0'
x[0] = input * a1' - output * b1'

and this is:

output = x[0] + input * k
x[0] = input * k + output

and this can be written as:

out = buf + in * k
buf = out + in * k

Here's the DFI version:

y[1] = y[0]
x[1] = x[0]
x[0] = input
y[0] = a0' * x[0] + a1' * x[1] - b1' * y[1]

results in:

y[0] = k * x[0] + k * x[1] + y[1]


Now you have an integrator: integ(x).

To build a one pole lowpass filter from an integrator you simply need a negative feedback path:

in ->-+-[integrator]-+->- out
      |              |
      |              | 
      ---<--[*-1]--<-|

which results in the following transfer function:

         1
H(s) = -----
       s + 1

so: 

lowpass(x) = integ(x - lastOut)

See wikipedia for Closed loop transfer function (The explanation why you can build a lowpass from an integrator with negative feedback).

See here for a blog post about the type of bilinear transforms I use.

[Z1202]

Code: Select all

To build a one pole lowpass filter from an integrator you simply need a negative feedback path:

in ->-+-[integrator]-+->- out
      |              |
      |              | 
      ---<--[*-1]--<-|

which results in the following transfer function:

         1
H(s) = -----
       s + 1

so: 

lowpass(x) = integ(x - lastOut)

Correction:

lowpass(x) = integ(x - lowpass(x))

or

lowpass(x) = y
where
y = integ(x - y)

Which is exactly where ZDF techniques come in.

Regards,
{Z}

[neotec]

Code: Select all

To build a one pole lowpass filter from an integrator you simply need a negative feedback path:

in ->-+-[integrator]-+->- out
      |              |
      |              | 
      ---<--[*-1]--<-|

which results in the following transfer function:

         1
H(s) = -----
       s + 1

so: 

lowpass(x) = integ(x - lastOut)

Correction:

lowpass(x) = integ(x - lowpass(x))

or

lowpass(x) = y
where
y = integ(x - y)

Which is exactly where ZDF techniques come in.

Regards,
{Z}

Yep, I know ... since it was me who started this thread. But I did not want to confuse ralphb

And of course, that's the point where the feedback solving comes in.

[ralphb]

Code: Select all

lowpass(x) = y
where
y = integ(x - y)

Which is exactly where ZDF techniques come in.

Regards,
{Z}[/quote]

Yep, I know ... since it was me who started this thread. But I did not want to confuse ralphb :D 

And of course, that's the point where the feedback solving comes in.[/quote]

That part I found simple compared to the other stuff! :-)

What's the best place to learn about this? Textbooks? Articles? How did you guys figure it out?

[xoxos]

so, basically..

you are able to take "feedback" out of the nomenclature for the filter by discretising the feedback as an prerequisite.....

[Tzarls]

Nope. He's taking the usual 1 sample delay out of the feedback path. The feedback is still there, but it's delayless (hence the "delayless feedback" part of the name).

[ralphb]

So...

Code: Select all

Having a 1 pole integrator (not a lowpass filter).....

neotec, thanks for clearing that up, very informative. For some reason I had not caught that your DFII was *transposed*, in fact, I had forgotten that was possible.

Did you make any headway with the highpass filter?

I've been looking into mystran's suggestion of controller/observer forms, but I still haven't figured all of the math out. I'm guessing that approach was also used in Open303's TeeBeeFilter, but the discussion of that seem to have happened in a different thread that I can't find.

[neotec]

Did you make any headway with the highpass filter?

Yep, after going through all the stuff again, I finally have got a 24dB resonant highpass filter ... my filter feedback path calculations were faulty^^

[rola]

Did you make any headway with the highpass filter?

Yep, after going through all the stuff again, I finally have got a 24dB resonant highpass filter ... my filter feedback path calculations were faulty^^

Can you show how to make a one pole highpass filter?

[neotec]

Can you show how to make a one pole highpass filter?

A one pole high pass filter can simply be done by subtracting the low pass filtered signal from the input:

Code: Select all

high = input - low(input)

so:

Code: Select all

double process(double input)
{
  double low = (b + f * input) / (1 + f);
  double high = input - low;
  b = low + f * high;
  return high;
}