DSPRelated.com
Forums

Filters for frequency inputs

Started by Les Cargill May 29, 2015
Suppose I have a frequency input* which produces a repeating
oscillating error:

*as in strobe from a stator on a motor or some such.

60 45 60 45 60 45 60 45

Presume I am measuring a very stable sig gen of
known frequency. So it should be:

52 52 53 52 52 52 52 53 53 52

Presume that it's mostly an artifact of measurement. It is,
in other words, some sort of jitter, but it seems to be highly
constrained jitter.

How do I design an IIR filter to clean that up? I just don't
know how to categorize this. What is this called?

I could pretty easily scattershot the thing, but I'd rather
have something more analytic to support the implementation.

I realize fully I may well be seeing aliasing, although the
supplied sample is hardly at the edge of the performance
envelope of the system - it's just a cheap input.

I am fully prepared to accept a class of several
particular solutions rather than one general case.

No, I don't even know what Fs should be for this case. Probably
"faster than it is."

-- 
Les Cargill
On Fri, 29 May 2015 21:58:14 -0500, Les Cargill wrote:

> Suppose I have a frequency input* which produces a repeating oscillating > error: > > *as in strobe from a stator on a motor or some such. > > 60 45 60 45 60 45 60 45 > > Presume I am measuring a very stable sig gen of known frequency. So it > should be: > > 52 52 53 52 52 52 52 53 53 52 > > Presume that it's mostly an artifact of measurement. It is, > in other words, some sort of jitter, but it seems to be highly > constrained jitter. > > How do I design an IIR filter to clean that up? I just don't know how to > categorize this. What is this called? > > I could pretty easily scattershot the thing, but I'd rather have > something more analytic to support the implementation. > > I realize fully I may well be seeing aliasing, although the supplied > sample is hardly at the edge of the performance envelope of the system - > it's just a cheap input. > > I am fully prepared to accept a class of several particular solutions > rather than one general case. > > No, I don't even know what Fs should be for this case. Probably "faster > than it is."
If that's really the only strong noise you have, then your best filter is z + 1 H(z) = ----- 2z It adds some delay, of course. If your strobe from a motor is real and not hypothetical, then look for some mechanical asymmetry that's causing it -- perhaps you're measuring frequency by timing the leading and trailing edges of a square wave, and its duty cycle isn't 50%. -- www.wescottdesign.com
Tim Wescott wrote:
> On Fri, 29 May 2015 21:58:14 -0500, Les Cargill wrote: > >> Suppose I have a frequency input* which produces a repeating oscillating >> error: >> >> *as in strobe from a stator on a motor or some such. >> >> 60 45 60 45 60 45 60 45 >> >> Presume I am measuring a very stable sig gen of known frequency. So it >> should be: >> >> 52 52 53 52 52 52 52 53 53 52 >> >> Presume that it's mostly an artifact of measurement. It is, >> in other words, some sort of jitter, but it seems to be highly >> constrained jitter. >> >> How do I design an IIR filter to clean that up? I just don't know how to >> categorize this. What is this called? >> >> I could pretty easily scattershot the thing, but I'd rather have >> something more analytic to support the implementation. >> >> I realize fully I may well be seeing aliasing, although the supplied >> sample is hardly at the edge of the performance envelope of the system - >> it's just a cheap input. >> >> I am fully prepared to accept a class of several particular solutions >> rather than one general case. >> >> No, I don't even know what Fs should be for this case. Probably "faster >> than it is." > > If that's really the only strong noise you have, then your best filter is > > z + 1 > H(z) = ----- > 2z >
That's kind of what I'd thought, but I wasn't sure why I'd thought that. I don't know that it the only strong noise, but it's kind of a general initial impression.
> It adds some delay, of course. >
A little. But that's a 1st order IIR, so it's not much delay.It uses this thing they call "damping" now which adds more delay. I think it's just a boxcar filter.
> If your strobe from a motor is real and not hypothetical, then look for > some mechanical asymmetry that's causing it -- perhaps you're measuring > frequency by timing the leading and trailing edges of a square wave, and > its duty cycle isn't 50%. >
It's the electronics adding the jitter/noise. It does the same with a signal generator. Thank you , Tim. -- Les Cargill
On Sat, 30 May 2015 14:16:28 -0500, Les Cargill wrote:

> Tim Wescott wrote: >> On Fri, 29 May 2015 21:58:14 -0500, Les Cargill wrote: >> >>> Suppose I have a frequency input* which produces a repeating >>> oscillating error: >>> >>> *as in strobe from a stator on a motor or some such. >>> >>> 60 45 60 45 60 45 60 45 >>> >>> Presume I am measuring a very stable sig gen of known frequency. So it >>> should be: >>> >>> 52 52 53 52 52 52 52 53 53 52 >>> >>> Presume that it's mostly an artifact of measurement. It is, >>> in other words, some sort of jitter, but it seems to be highly >>> constrained jitter. >>> >>> How do I design an IIR filter to clean that up? I just don't know how >>> to categorize this. What is this called? >>> >>> I could pretty easily scattershot the thing, but I'd rather have >>> something more analytic to support the implementation. >>> >>> I realize fully I may well be seeing aliasing, although the supplied >>> sample is hardly at the edge of the performance envelope of the system >>> - >>> it's just a cheap input. >>> >>> I am fully prepared to accept a class of several particular solutions >>> rather than one general case. >>> >>> No, I don't even know what Fs should be for this case. Probably >>> "faster than it is." >> >> If that's really the only strong noise you have, then your best filter >> is >> >> z + 1 >> H(z) = ----- >> 2z >> >> > > That's kind of what I'd thought, but I wasn't sure why I'd thought that. > > I don't know that it the only strong noise, but it's kind of a general > initial impression. > >> It adds some delay, of course. >> >> > A little. But that's a 1st order IIR, so it's not much delay.It uses > this thing they call "damping" > now which adds more delay. I think it's just a boxcar filter. > >> If your strobe from a motor is real and not hypothetical, then look for >> some mechanical asymmetry that's causing it -- perhaps you're measuring >> frequency by timing the leading and trailing edges of a square wave, >> and its duty cycle isn't 50%. >> >> > It's the electronics adding the jitter/noise. It does the same with a > signal generator.
Eeew. I'd also consider reviewing the electronics. If this is a control loop then the general rule is that there's only so far you can go with the physical plant as-is; when you're close to that limit you cannot profitably increase performance by messing with the control rule. Note that what I gave you was a 2-tap boxcar with a pole at z = 0; there's no reason you couldn't make a filter with a zero at z = -1 (like a 2-tap boxcar) and a pole somewhere in the range 0 <= z < 1. I have done that, profitably, in systems that sampled at twice the rotation rate of a shaft and thus had a strong tone at Fs/2. -- www.wescottdesign.com
Tim Wescott wrote:
> On Sat, 30 May 2015 14:16:28 -0500, Les Cargill wrote: > >> Tim Wescott wrote: >>> On Fri, 29 May 2015 21:58:14 -0500, Les Cargill wrote: >>> >>>> Suppose I have a frequency input* which produces a repeating >>>> oscillating error: >>>> >>>> *as in strobe from a stator on a motor or some such. >>>> >>>> 60 45 60 45 60 45 60 45 >>>> >>>> Presume I am measuring a very stable sig gen of known frequency. So it >>>> should be: >>>> >>>> 52 52 53 52 52 52 52 53 53 52 >>>> >>>> Presume that it's mostly an artifact of measurement. It is, >>>> in other words, some sort of jitter, but it seems to be highly >>>> constrained jitter. >>>> >>>> How do I design an IIR filter to clean that up? I just don't know how >>>> to categorize this. What is this called? >>>> >>>> I could pretty easily scattershot the thing, but I'd rather have >>>> something more analytic to support the implementation. >>>> >>>> I realize fully I may well be seeing aliasing, although the supplied >>>> sample is hardly at the edge of the performance envelope of the system >>>> - >>>> it's just a cheap input. >>>> >>>> I am fully prepared to accept a class of several particular solutions >>>> rather than one general case. >>>> >>>> No, I don't even know what Fs should be for this case. Probably >>>> "faster than it is." >>> >>> If that's really the only strong noise you have, then your best filter >>> is >>> >>> z + 1 >>> H(z) = ----- >>> 2z >>> >>> >> >> That's kind of what I'd thought, but I wasn't sure why I'd thought that. >> >> I don't know that it the only strong noise, but it's kind of a general >> initial impression. >> >>> It adds some delay, of course. >>> >>> >> A little. But that's a 1st order IIR, so it's not much delay.It uses >> this thing they call "damping" >> now which adds more delay. I think it's just a boxcar filter. >> >>> If your strobe from a motor is real and not hypothetical, then look for >>> some mechanical asymmetry that's causing it -- perhaps you're measuring >>> frequency by timing the leading and trailing edges of a square wave, >>> and its duty cycle isn't 50%. >>> >>> >> It's the electronics adding the jitter/noise. It does the same with a >> signal generator. > > Eeew. I'd also consider reviewing the electronics.
Heh.
> If this is a control > loop then the general rule is that there's only so far you can go with > the physical plant as-is; when you're close to that limit you cannot > profitably increase performance by messing with the control rule. >
Right.
> Note that what I gave you was a 2-tap boxcar with a pole at z = 0;
Yeah, it compares quite closely with a classic moving average.
> there's no reason you couldn't make a filter with a zero at z = -1 (like > a 2-tap boxcar) and a pole somewhere in the range 0 <= z < 1. I have > done that, profitably, in systems that sampled at twice the rotation rate > of a shaft and thus had a strong tone at Fs/2. >
Interesting. -- Les Cargill
Les Cargill <lcargill99@comcast.com> writes:
> [...] > Tim Wescott wrote: >> Note that what I gave you was a 2-tap boxcar with a pole at z = 0; > > Yeah, it compares quite closely with a classic moving average.
Boxcar, moving average - same damn thing. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
On Sat, 30 May 2015 21:15:39 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>Les Cargill <lcargill99@comcast.com> writes: >> [...] >> Tim Wescott wrote: >>> Note that what I gave you was a 2-tap boxcar with a pole at z = 0; >> >> Yeah, it compares quite closely with a classic moving average. > >Boxcar, moving average - same damn thing.
Ah, semantic fight! I argue that a boxcar is an equally-weighted Moving Average, and anything else is a weighted Moving Average. So a FIR is always a Moving Average. That's the MA in ARMA, anyway. ;) So a boxcar is perhaps a degenerate case of a Moving Average. Just my dos centavos. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
On 5/30/2015 9:51 PM, Eric Jacobsen wrote:
> On Sat, 30 May 2015 21:15:39 -0400, Randy Yates > <yates@digitalsignallabs.com> wrote: > >> Les Cargill <lcargill99@comcast.com> writes: >>> [...] >>> Tim Wescott wrote: >>>> Note that what I gave you was a 2-tap boxcar with a pole at z = 0; >>> >>> Yeah, it compares quite closely with a classic moving average. >> >> Boxcar, moving average - same damn thing. > > Ah, semantic fight! > > I argue that a boxcar is an equally-weighted Moving Average, and > anything else is a weighted Moving Average. So a FIR is always a > Moving Average. > > That's the MA in ARMA, anyway. ;) > > So a boxcar is perhaps a degenerate case of a Moving Average.
Don't you think a moving average is pretty clear without an explicit indication that it is not weighted? I'm not sure what you are trying to distinguish. BTW, why would you use the abbreviation ARMA, even in this group, without explanation? I bet I'm not the only one who had to look it up.
> Just my dos centavos.
Thanks, now I can have that operation I've been needing... -- Rick
Randy Yates wrote:
> Les Cargill <lcargill99@comcast.com> writes: >> [...] >> Tim Wescott wrote: >>> Note that what I gave you was a 2-tap boxcar with a pole at z = 0; >> >> Yeah, it compares quite closely with a classic moving average. > > Boxcar, moving average - same damn thing. >
Very similar - but not exactly the same. -- Les Cargill
Les Cargill <lcargill99@comcast.com> writes:

> Randy Yates wrote: >> Les Cargill <lcargill99@comcast.com> writes: >>> [...] >>> Tim Wescott wrote: >>>> Note that what I gave you was a 2-tap boxcar with a pole at z = 0; >>> >>> Yeah, it compares quite closely with a classic moving average. >> >> Boxcar, moving average - same damn thing. >> > > > Very similar - but not exactly the same.
Les, What difference do you think exists? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com