On Fri, 10 Oct 2008 21:22:03 -0500, Manfred wrote:
> 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!
Indeed! I left out the term.
>>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!
It's the 'z' in the z transform. You _may_ complain about the math, but
see http://www.wescottdesign.com/articles/zTransform/z-transforms.html
(or my book, or any good DSP book) for details.
>>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.
I'm surprised that any computing language that claims to be "pro" doesn't
sup****t 32-bit integers, at least.
Multi-precision arithmetic isn't hard in assembly, and if you restrict
the gain in the above equation to being powers 1/2 then you can implement
the "* gain" part as an arithmetic right ****ft, which relieves you of the
need to do multi-precision multiplies.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
|
