Manfred wrote:
> Hi all!
>
> Tim,
>
>> You want a simple first-order lowpass IIR filter. You can implement it
>
> in one line of C:
>
>> output = gain * (input - output);
>
> Either there is some mistake in this, or I'm doing something wrong, but
> I'm not getting any attenuation of high frequency components with this.
It puzzled me too, but I've learned to question myself before I question
Tim. Try the exponential averager I described. Making k small produces
the greatest reduction of highs. You might start with k = 1/2. All
fractions of the form (2^n - 1)/2^n, where (for 16 bit words) 1 < k < 15
allows efficient computation.
>> A 20Hz cutoff is pretty high for a sampling rate of 50Hz -- you're not
>> going to get much attenuation of your noise.
>
> The sampling rate is 100Hz. I might lower the cutoff further. But the
> previous implementation of this controller, done in the analog world,
used
> 20 Hz with good results. But that was a third order filter.
To measure entire periods, the sample rate should be 50 Hz. There is no
assurance that alternate half cycles have the same duration.
>> Keep in mind that as you lower the filter bandwidth you'll have to back
>
>> off your pro****tional and integral gains to keep the loop stable.
>
> I know. That's also why I don't want to lower the cutoff frequency too
> much.
>
>> You may also find that you need to use more than 16 bits in the filter
> to
>> maintain enough precision
>
> That would be a problem, because in the programming language I'm using,
I
> only have 16 bit integers, and no carry bit.
The assembly routine to filter in extended precision is rather
straightforward. The technique we call fraction saving around here may
allow you to limit the amount of code that needs extended precision.
http://www.dspguru.com/comp.dsp/tricks/alg/dc_block.htm
describes a
high-pass filter with fraction saving.
...
> I'm not using interrupts, but indeed I have some jitter because I'm
> sampling the zero crossing inside a waiting loop. The loop is only two
> instructions long, but that still gives a jitter of 4 microseconds. Not
> much, but maybe noticeable.
>
> The jitter caused by the distortion of my 50Hz signal is much larger
than
> that, anyway.
*Measure whole cycles!*
> A related point is that I don't have a stable sampling frequency at all.
A
> sample is taken whenever a zero crossing happens (4 times per revolution
of
> the machine). When the speed varies, the sampling will also happen at
> uneven intervals. I'm aware that this can lead to weird feedback
problems,
> as all the control is tied to the same sampling, but I count on fixing
any
> instability by simply slowing down the control response. If I can get a
> control action at up to 3Hz, it's good enough! More would be welcome,
but
> is not really necessary, given the large inertia of this machine.
...
> Jerry,
>
>> I think that he counts some
>> high-frequency oscillator during the interval between zero crossings to
>
>> determine the period of his waveform, the result of each measurement
>> being a number; a bunch of bits.
>
> Exactly this is what I'm doing. The counter runs at 1MHz,
> quartz-controlled, and is inside the PIC too. So, if the half wave of my
> signal is as long as it should be, I get 10000 counts.
>
>> Where should the capacitor go?
>
> Precisely. It has nowhere to go, and that's why I landed here, looking
for
> info to finally get my feet wet with DSP!
>
>> A simple low-pass filter might suffice.
>
> At least it should help somewhat.
>
>> The conventional symbols used
>> for digital data streams are x[n] for the input data and y[n] for the
>> result, where n is the number of the sample in the sequence.
>
> Good to know. I didn't. And this is in part while it's so hard to get
into
> DSP by googling for things: Almost every text one can find assumes that
the
> readers know such basics!
>
>> A unity-gain first-order filter is y[n] = k*x[n] + (1-k)*y[n-1]. It is
>> called an exponential averager; k is less than but close to 1.
>
> OK. I tried it, and this indeed works, and attenuates the high frequency
> signals! Thanks!
>
> Now what has to be done to increase the order of this filter? As I
stated
> above, the active filter in my previous (analog) controller used a third
> order filter, with good results.
Higher order filters are a bit more complex and you either crank a
little math or use a design program to give the coefficient values.
Numerical instabilities with only 16 bits become far more likely.
>> There is
>> usually an adequate choice of k that will allow the multiplications to
>> be accomplished with a ****ft and a subtraction.
>
> I tried it on the PC, in BASIC, where I have the benefit of floating
point
> math. It seems that about 0.7 would be good for my application, but when
> implementing this on the PIC, I might need to go to 0.5 for simplicity
in
> integer math. I think the response time this gives would still be
> acceptable. But a higher order would be nice!
..75 is fairly easy.
> I suppose a higher order is obtained by cascading such filters, or is
> there a more elegant way?
Second-order filters (a pair of conjugate complex poles) are implemented
directly. Higher-order filters are best implemented as cascades.
>> I think your problem may be due in part to a (probably unwarranted)
>> assumption that there are no even harmonics in your generated waveform.
>
>
> Indeed I'm uncertain whether to sample at 100Hz, or just at 50Hz, using
> full waves. The analog controller runs at 100Hz with good results, but
of
> course with its 20Hz 3rd order filter that doesn't mean much. It is
> sampling at 100Hz only to reduce the ripple at the filter output.
>
>> Even harmonics will cause alternate half cycles to have different
>> periods. You should measure the period of an entire cycle by triggering
>
>> on positive- or negative-going zero crossings, not both.
>
> I can try that easily. Maybe it would be best to try with a running
> average over the last two half cycles. This would cancel the effects of
> even harmonics, and I still would have a new value 100 times per second,
> although with an effective delay of 10ms.
If there were no other errors, that would surely work. You would
effectively be re****ting full cycles twice per cycle. (No need to divide
by 2. Just double the reference count and halve your gains.)
> And I also have to try a much wider range of gains than I'm trying now,
> but the integer math is limiting me in that. I need to write a better PI
> routine first!
>
> Thanks to you all! I got good info and several ideas to try. More ideas
> are welcome of course, as is an equation for a higher order low pass
> filter!
Try this:
http://www.dsptutor.freeuk.com/IIRFilterDesign/IIRFiltDes102.html
The assumed sample rate is fixed at 8000/sec, but what really matters is
the ratio of cutoff frequency to sample rate. To design for an actual
sample rate of 100/sec, multiply the desired cutoff by 80. A fixed-point
implementation won't be easy.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
** Posted from http://www.teranews.com
**
|
