Jerry,
> Try the exponential averager I described.
I tried, but with that low order filtering I run into delay-induced
instability before it really takes out the noise. So the benefit is less
than the cost.
> 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.
Yes, that's right. I knew those things once, in the distant past...! Need
to get those neurons in gear again. ;-)
> To measure entire periods, the sample rate should be 50 Hz. There is no
> assurance that alternate half cycles have the same duration.
I have done that now, and indeed it helped somewhat.
> 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.
But I'm programming this in a BASIC-like moderately high level language!
> *Measure whole cycles!*
Doing it now! By still detecting every zero crossing but averaging the
last two samples.
> 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.
Sounds a bit scary!
> .75 is fairly easy.
Yes.
> Second-order filters (a pair of conjugate complex poles) are implemented
> directly. Higher-order filters are best implemented as cascades.
OK. That's not much different from the analog world.
>> 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.)
It's what I did, and it works well and helps some. Funnily, though, it
helped more with the prototype on my desk, driven from a signal generator,
than with the real thing driven from the hydro turbine! The signal
generator, a very modest affair built around an 8038 IC, has worse sine
wave symmetry than the 10 kilowatt alternator!
> Try this:
> http://www.dsptutor.freeuk.com/IIRFilterDesign/IIRFiltDes102.html
It asks me to install yet another plugin before I can use it. Will try
tomorrow. My internet connection is very slow (via cellphone, in a rural
place with marginal coverage), so downloading plugins is a major
undertaking.
> A fixed-point implementation won't be easy.
That's a downer...
Tim,
>>> output = gain * (input - output);
>If Jerry doesn't understand it, I didn't explain it well.
>
>Take gain = 0.1, input is constant 1, and output starts at 0. Then you
>should get:
>
>step output
>0 0
>1 0.1
>2 0.19
>3 0.271
>n 1 - 0.9^n
It doesn't work!!!!
But with that sequence of numbers, at least I easily found WHY it doesn't
work. You forgot a term in the equation! It really should be
output = output + gain * (input - output)
Then it works as advertised!
>Gin up a filter with a transfer function (z + 1)/(z - d), with d close to
>1. That'll let you update at 100Hz while rejecting the noise at 50Hz,
>yet still giving you good response at somewhat lower frequencies.
And what's the "z" there? Excuse my lack of routine in DSP!
>Then get another programming language!
I should. You are right in that. But the learning curve...
> If it's C, and it's remotely ANSI
>C compatible, then 'long' will be 32 bits.
It's nothing like C. It's PicBasic Pro. It works very well for many tasks,
but definitely it wasn't designed for DSP nor any math-intensive tasks!
>You can extend precision in most any programming language if you can
>stand the tedium -- but it's often easier to do things in assembly.
I have found it most practical to use assembly for bitwise operations,
control, and such, but a high level language for math. Of course, that
assumes that the high level language actually has floating point math,
which is NOT the case with PicBasic Pro!
That said, I also have to admit that the older I get, the more I tend to
prefer high level languages over assembly! But I did my duty in assembly,
when I was younger. Among many other things, I wrote a full radioteletype
BBS program, with software modulation and demodulation, in 6502 assembly -
it ran on an Atari 800XL! Which also gives away roughly how many years ago
I did that... But the best was writing a data conversion program, directly
in DEC PDP-8 machine language! I had to assemble the machine code on
paper,
for lack of a real assembler program. That was done in octal format, not
hexadecimal...
Still, despite my old-age-induced preference for high level languages,
it's clear that for speed and controllability, nothing else matches
assembly.
Manfred.
|
