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!
>
>> 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.
Look at http://www.newmicros.com/;
nmiy0020 in particular. Use two
timers, one to count positive-going cycles, the other, negative. That
way you avoid the a +/-one-count uncertainty twice.
C is available, but you'll love Forth if you have the background you
seem to.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
** Posted from http://www.teranews.com
**
|
