Searching \ for 'Digital low-pass filter code' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/logic/dsps.htm?key=filter
Search entire site for: 'Digital low-pass filter code'.

Truncated match.
PICList Thread
'Digital low-pass filter code'
1998\03\05@142159 by Craig Webb

flavicon
face
Thanks everyone for the WWVB (Boulder or Fort Collins?) info on the 60kHz
time standard.

I am also interested in finding out if anyone has done digital low pass
filtering. I need fast code that can do about 4th order (and ideally up to
6th order) filtering on 13-bit signals. Does anyone have this or know where
I can find it?

Thanks.

C. Webb

1998\03\05@183804 by Tom Mariner

flavicon
face
Aside from the obvious of an accumulator being a low pass filter, we
normally hard code the time consuming parts of the digital filters,
presuming that your filter coefficients are not going to change. We either
pre-do the multiply of factors based on a trig function times a constant or
tweak the multiply. The former is done by doing the stage multiplication
off line and interpolating results of table look-ups. The latter is done by
skipping the bit tests on the multiplicand and straight-line coding the
shifts.

Obviously, the time per cycle of multiply and accumulates, as with
everything in DSP, is dependent upon your sample frequency. For mains
power, ya got a lotta time. For voice, you'd better be doing some real
tricky stuff in a PIC if you're doing the number of orders and resolution
that you are looking at. We have had great luck by varying the sample
frequency and type of filter until you get to coefficients that either
disappear or are very easy multiplies. You can do this type of iteration
easily with filter design packages, although normally the output is in
terms of C code or asm for the popular DSP's.

Tom

On Thursday, March 05, 1998 2:22 PM, Craig Webb [SMTP:spam_OUTlucidTakeThisOuTspamMAGNET.CA]
wrote:
> Thanks everyone for the WWVB (Boulder or Fort Collins?) info on the 60kHz
> time standard.
>
> I am also interested in finding out if anyone has done digital low pass
> filtering. I need fast code that can do about 4th order (and ideally up
to
> 6th order) filtering on 13-bit signals. Does anyone have this or know
where
> I can find it?
>
> Thanks.
>
> C. Webb

1998\03\06@125044 by Craig Webb

flavicon
face
Tom,

Thanks for the help. I'm running at about 2000 samps/sec (though I'd like to
run 8 channels!). We'll see how it goes. Some good suggestions though. How
many bytes would you use to keep good resolution at 13 bits? The person I'm
working with who has already written some LPF code said we need four byte to
keep precision. This seems a bit high to me.

Craig

At 05:39 PM 3/5/98 -0500, you wrote:
{Quote hidden}

1998\03\06@151055 by Matt Bonner

flavicon
face
Craig Webb wrote:

> Thanks for the help. I'm running at about 2000 samps/sec (though I'd like to
> run 8 channels!). We'll see how it goes. Some good suggestions though. How
> many bytes would you use to keep good resolution at 13 bits? The person I'm
> working with who has already written some LPF code said we need four byte to
> keep precision. This seems a bit high to me.
>
Craig,

I posted the following a number of months ago in response to a similar
question.

First, you have to know the "noise-free" counts of your system.  This is
typically your full scale signal divided by 6 times the rms noise - you
find the rms noise by calculating the standard deviation of a sample set
(I use a minimum of 1000 sample points).  Of course, this is only valid
if your noise is Gaussian - plot your sample set to see.  Where did that
"abritrary" value of 6 times come in?  If your data plot indicates that
your noise is Gaussian, one standard deviation is equivalent to the rms
noise.  Almost all of the data points will fall within +/-3.3 standard
deviations - use a factor of 6 (close enough to 6.6) to estimate the
peak-to-peak noise relationship to the rms noise.

NOW, you can use averaging to improve system resolution.  BTW, thermal
noise is typically the only true Gaussian noise that you're going to
find.

--Matt

1998\03\06@194108 by Tom Mariner

flavicon
face
Hello Craig,

That means that you have a maximum of 500 us to do all of your multiply and
accumulates needed for a filter. If fourth order (four fixed point
multiplies)  and 32 bit intermediate results, that seems like a lot to ask
a Pic to do, even at 20 MHz. At 20 MHz you are going to get 2500
instruction cycles in your sample time, not counting double cycle jumps.
Since the standard 16 x 16 = 32 multiply is 233 cycles, you do have some
time for other program tasks.

I would guess that you need some sort of speed up, like a straight line
multiply that is pre-done for the factors involved, presuming the filter
coefficients are going to be the same for your application. Sounds doable
but real tight, but I'll bet you can find a filter type and sample rate
that will let you perform some sort of very quick multiply (factor of 2,
etc.).

Other factors, of course include the steepness of the filter and the
sensitivity to amplification before the start of the filter frequency. I
have found that many types of filters, (Chebychev, etc.) give a gain
before the filter starts rolling off. If your application is sensitive to
this you may want to look at elliptical or some other type.

Tom

On Friday, March 06, 1998 10:55 AM, Craig Webb [SMTP:lucidspamKILLspamMAGNET.CA]
wrote:
> Tom,
>
> Thanks for the help. I'm running at about 2000 samps/sec (though I'd like
to
> run 8 channels!). We'll see how it goes. Some good suggestions though.
How
> many bytes would you use to keep good resolution at 13 bits? The person
I'm
> working with who has already written some LPF code said we need four byte
to
> keep precision. This seems a bit high to me.
>
> Craig
>
> At 05:39 PM 3/5/98 -0500, you wrote:
> >Aside from the obvious of an accumulator being a low pass filter, we
> >normally hard code the time consuming parts of the digital filters,
> >presuming that your filter coefficients are not going to change. We
either
> >pre-do the multiply of factors based on a trig function times a constant
or
> >tweak the multiply. The former is done by doing the stage multiplication
> >off line and interpolating results of table look-ups. The latter is done
by
> >skipping the bit tests on the multiplicand and straight-line coding the
> >shifts.
> >
> >Obviously, the time per cycle of multiply and accumulates, as with
> >everything in DSP, is dependent upon your sample frequency. For mains
> >power, ya got a lotta time. For voice, you'd better be doing some real
> >tricky stuff in a PIC if you're doing the number of orders and
resolution
{Quote hidden}

60kHz
> >> time standard.
> >>
> >> I am also interested in finding out if anyone has done digital low
pass
> >> filtering. I need fast code that can do about 4th order (and ideally
up
> >to
> >> 6th order) filtering on 13-bit signals. Does anyone have this or know
> >where
> >> I can find it?
> >>
> >> Thanks.
> >>
> >> C. Webb
> >
> >

1998\03\07@042243 by Martin Nilsson

picon face
Matt Bonner <EraseMEmbonnerspam_OUTspamTakeThisOuTSUNADA.COM> wrote:

> Craig Webb wrote:
>
> > Thanks for the help. I'm running at about 2000 samps/sec (though I'd like to
> > run 8 channels!). We'll see how it goes. Some good suggestions though. How
> > many bytes would you use to keep good resolution at 13 bits? The person I'm
> > working with who has already written some LPF code said we need four byte to
> > keep precision. This seems a bit high to me.
> >
...
{Quote hidden}

True, but there is another problem as well. The numerical computation
in a digital filter is often ill-conditioned, and intermediate results
need to be stored with higher precision. How much depends on the
particular filter formula used, but according to my experience, a
doubling is not uncommon. 2 * 13 bits = 26, which is 3 bytes, plus
half a nibble.  I would say Craig's colleague's recommendation is very
reasonable.

Martin Nilsson                           http://www.sics.se/~mn/
Swedish Institute of Computer Science    E-mail: mnspamspam_OUTsics.se
Box 1263, SE-164 29 Kista                Fax: +46-8-751-7230
Sweden                                   Tel: +46-8-752-1574

1998\03\09@193641 by Matt Bonner

flavicon
face
Martin Nilsson wrote:
>
> Matt Bonner <@spam@mbonnerKILLspamspamSUNADA.COM> wrote:
>
> > Craig Webb wrote:
> >
> > > How
> > > many bytes would you use to keep good resolution at 13 bits? The person
I'm
> > > working with who has already written some LPF code said we need four byte
to
> > > keep precision. This seems a bit high to me.
> > >
> ...
> > First, you have to know the "noise-free" counts of your system.
[snip..]

> True, but there is another problem as well. The numerical computation
> in a digital filter is often ill-conditioned, and intermediate results
> need to be stored with higher precision. How much depends on the
> particular filter formula used, but according to my experience, a
> doubling is not uncommon. 2 * 13 bits = 26, which is 3 bytes, plus
> half a nibble.  I would say Craig's colleague's recommendation is very
> reasonable.
>
You're right - I was trying to point out that you have to be careful
using "rule-of-thumb" computations (if, in fact, it was rule of thumb).
(Craig wasn't sure how his colleague had come up with the number "4".)
One of most common mistakes I seen in data acquisition design is the
conception that you can double your accuracy by doubling your resolution
through oversampling and filtering.  In one design I analysed, it would
have taken about 50 oversamples (before filtering) to increase the
accuracy of a 14b system to 16b (and the A/D was a 20b delta-sigma).
Maybe somebody can point me to a ultra low noise military
instrumentation amp?

--Matt

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...