Forums

decimation and resolution

Started by alb October 31, 2014
Hi everyone,

I have an encoder which is delivering 22bit data for a 360 rotation. The 
rotation is accomplished in ~800ms but the serial link from the encoder 
is running such that we will sample values at 25KHz (that is a 
requirement).

It roughly means we are grossly undersampling the amount of information 
the enconder is capable to provide.

Would this 'decimation' have an impact on the angle resolution? 
Considering the angle information is used in a control loop for a motor 
controller, would this 'decimation' have an impact on the loop itself?

Thanks a lot for any pointer,

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 31 Oct 2014 15:41:18 +0000, alb wrote:

> Hi everyone, > > I have an encoder which is delivering 22bit data for a 360 rotation. The > rotation is accomplished in ~800ms but the serial link from the encoder > is running such that we will sample values at 25KHz (that is a > requirement). > > It roughly means we are grossly undersampling the amount of information > the enconder is capable to provide. > > Would this 'decimation' have an impact on the angle resolution? > Considering the angle information is used in a control loop for a motor > controller, would this 'decimation' have an impact on the loop itself? > > Thanks a lot for any pointer,
Well, you're certainly looking at this issue from an unusual perspective! I wouldn't call what you're seeing "decimation" -- you're really just sampling the shaft position at 25kHz. The questions that you have to ask, then, are: (1) is the 25kHz sampling rate limiting your loop bandwidth, and (2) is the noise at the encoder output a significant source of position error. If the answer to both of those questions is "no", then you can move on to things that really matter. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
>> Would this 'decimation' have an impact on the angle resolution? >> Considering the angle information is used in a control loop for a motor >> controller, would this 'decimation' have an impact on the loop itself? > > Well, you're certainly looking at this issue from an unusual perspective!
thanks for being so polite. I admit my embarassing ignorance when it comes to signal processing... but is on my wishlist for the coming years (together with constrol theory, system modeling, system engineering, documentation systems, verification methodologies, high level synthesis, continuous integration, poker theory and the list goes on...) Why it cannot be considered 'decimation'? I'm just reducing the sampling rate of a signal, isn't that right?
> I wouldn't call what you're seeing "decimation" -- you're really just > sampling the shaft position at 25kHz.
Ok, so there's no 'Nyquist frequency' violation if we are undersampling information, no aliasing effect that needs to be taken into account, is that correct?
> The questions that you have to ask, > then, are: (1) is the 25kHz sampling rate limiting your loop bandwidth, > and (2) is the noise at the encoder output a significant source of > position error.
1. I'm not so sure I can answer this question, I know my loop is working at 3 KHz. I suppose an input running at 25 KHz is not limiting the operation of the loop. For that matter the loop itself is only looking at ~1/8 samples. 2. Noise is not known, we provide the implementation of the control, but parameters tuning is done by the customer. Yet I'd like to know if I need to take precautions against noise. Actuallyi, talking about noise the customer wants to get rid of 'spourious' readings but while we are sampling, the motor is moving so thresholds over a mean is not really the best way to get rid of those values. One possibility is to take the maximum velocity of the motor and compare it to the current velocity, if the point is way beyond then something has gone wrong and we can throw the value away. At the moment I cannot think something more efficient.
> If the answer to both of those questions is "no", then you can move on to > things that really matter.
That intrigues me, I know soon I'll find out myself but any anticipation about 'what really matters' can get me trained ;-). Al
On Fri, 31 Oct 2014 23:04:44 +0000, alb wrote:

> Hi Tim, > > Tim Wescott <seemywebsite@myfooter.really> wrote: > [] >>> Would this 'decimation' have an impact on the angle resolution? >>> Considering the angle information is used in a control loop for a >>> motor controller, would this 'decimation' have an impact on the loop >>> itself? >> >> Well, you're certainly looking at this issue from an unusual >> perspective! > > thanks for being so polite. I admit my embarassing ignorance when it > comes to signal processing... but is on my wishlist for the coming years > (together with constrol theory, system modeling, system engineering, > documentation systems, verification methodologies, high level synthesis, > continuous integration, poker theory and the list goes on...) > > Why it cannot be considered 'decimation'? I'm just reducing the sampling > rate of a signal, isn't that right?
It's not that it cannot be considered decimation, so much as it's quite a stretch to do so. Particularly because you can't possibly have an encoder with 240000 lines -- you've almost certainly got an encoder with 16384 or fewer (probably 4096) that's taking analog readings of the light and interpolating the extra bits. So it's not as if there's really a discrete event going from one 1/4 line to another the way there is with a "normal" differential encoder.
>> I wouldn't call what you're seeing "decimation" -- you're really just >> sampling the shaft position at 25kHz. > > Ok, so there's no 'Nyquist frequency' violation if we are undersampling > information, no aliasing effect that needs to be taken into account, is > that correct?
Uh... Things are different in control loops. Generally, if it's just the control loop that's the issue, your loop speed is so far below the sampling rate that Nyquist and all that really isn't an issue. HOWEVER: If you have some noise that's bothersome, and if that noise can be shifted down to DC by the sampling, then it's an issue. Isn't that nice?
>> The questions that you have to ask, >> then, are: (1) is the 25kHz sampling rate limiting your loop bandwidth, >> and (2) is the noise at the encoder output a significant source of >> position error. > > 1. I'm not so sure I can answer this question, I know my loop is working > at 3 KHz. I suppose an input running at 25 KHz is not limiting the > operation of the loop. For that matter the loop itself is only looking > at ~1/8 samples.
If you mean your loop is only sampled at 3kHz, then the 25kHz isn't an issue. At this point you ARE decimating, and it may be worthwhile to consider some very judicious filtering. About the only kind that I'd contemplate is a filter that decimates by N and averages (or sums) by N -- you end up with a comb filter with nulls at all harmonics of the sampling rate (so it totally undermines any noise aliasing), at the best possible phase shift to attenuation ratio for anything that may alias down.
> 2. Noise is not known, we provide the implementation of the control, but > parameters tuning is done by the customer. Yet I'd like to know if I > need to take precautions against noise.
You'll find out. Personally I think that's an unwise place to split the task, but if your customer is supplying the money, and your group was smart enough to arrange the contract so that they pay for effort and not results, then you should be fine.
> Actuallyi, talking about noise the customer wants to get rid of > 'spourious' readings but while we are sampling, the motor is moving so > thresholds over a mean is not really the best way to get rid of those > values. > > One possibility is to take the maximum velocity of the motor and compare > it to the current velocity, if the point is way beyond then something > has gone wrong and we can throw the value away. At the moment I cannot > think something more efficient.
Hard to say what's the best answer -- it depends on what's making the problem. Often the best answer is to fix the root problem, rather than trying to put bandaids over it.
>> If the answer to both of those questions is "no", then you can move on >> to things that really matter. > > That intrigues me, I know soon I'll find out myself but any anticipation > about 'what really matters' can get me trained ;-). > > Al
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Hi Tim,
Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
>> Why it cannot be considered 'decimation'? I'm just reducing the sampling >> rate of a signal, isn't that right? > > It's not that it cannot be considered decimation, so much as it's quite a > stretch to do so. Particularly because you can't possibly have an encoder > with 240000 lines -- you've almost certainly got an encoder with 16384 or > fewer (probably 4096) that's taking analog readings of the light and > interpolating the extra bits.
I see, well I actually have no clue what's the implementation and how do they get to that precision. I've found though encoders working with interpolation as you mentioned (up to 18000 lines). []
>> Ok, so there's no 'Nyquist frequency' violation if we are undersampling >> information, no aliasing effect that needs to be taken into account, is >> that correct? > > Uh... > > Things are different in control loops. Generally, if it's just the > control loop that's the issue, your loop speed is so far below the > sampling rate that Nyquist and all that really isn't an issue. > > HOWEVER: If you have some noise that's bothersome, and if that noise can > be shifted down to DC by the sampling, then it's an issue. Isn't that > nice?
That's very nice! So if I understood you correctly what I'm doing with undersampling is getting the noise density above my sampling frequency and aliasing it. That's what I thought in the first place.
>> 1. I'm not so sure I can answer this question, I know my loop is working >> at 3 KHz. I suppose an input running at 25 KHz is not limiting the >> operation of the loop. For that matter the loop itself is only looking >> at ~1/8 samples. > > If you mean your loop is only sampled at 3kHz, then the 25kHz isn't an > issue. > > At this point you ARE decimating, and it may be worthwhile to consider > some very judicious filtering. About the only kind that I'd contemplate > is a filter that decimates by N and averages (or sums) by N -- you end up > with a comb filter with nulls at all harmonics of the sampling rate (so it > totally undermines any noise aliasing), at the best possible phase shift > to attenuation ratio for anything that may alias down.
I'm sorry but I think I lost you here. I understood that noise can be aliased down around DC where my signal is (~1.2Hz) but I haven't understood how the comb filter may undermine aliasing.
>> 2. Noise is not known, we provide the implementation of the control, but >> parameters tuning is done by the customer. Yet I'd like to know if I >> need to take precautions against noise. > > You'll find out. Personally I think that's an unwise place to split the > task, but if your customer is supplying the money, and your group was > smart enough to arrange the contract so that they pay for effort and not > results, then you should be fine.
I've always found bizarre that the motor controller has been separated from the motor and encoder themselves (which might be also done by two different groups). One thing is responsibility for a working system (we are not responsible) and customer satisfaction. At the end of the day, when things are not working tension will arise and an unsatisfied customer is never a good thing to have.
>> Actuallyi, talking about noise the customer wants to get rid of >> 'spourious' readings but while we are sampling, the motor is moving so >> thresholds over a mean is not really the best way to get rid of those >> values. >> >> One possibility is to take the maximum velocity of the motor and compare >> it to the current velocity, if the point is way beyond then something >> has gone wrong and we can throw the value away. At the moment I cannot >> think something more efficient. > > Hard to say what's the best answer -- it depends on what's making the > problem. Often the best answer is to fix the root problem, rather than > trying to put bandaids over it.
Sometimes the problem isn't fixable. A spourious value can be there because of a heavy ion commuting the state of a register and here you go with your crazy value. Failure analysis usually leads to countermeasures to be implemented because you cannot get rid of the root cause. Al
On 10/31/14 7:04 PM, alb wrote:
> > Ok, so there's no 'Nyquist frequency' violation if we are undersampling > information, no aliasing effect that needs to be taken into account, is > that correct? >
uhm, i think you mean "oversampling". "undersampling" means that your sample rate is not high enough and that Nyquist is below the signal bandwidth. "oversampling" means that your sample rate is higher than absolutely necessary and there is a gap of empty band (or stuff you don't care about) between the top bandedge and Nyquist. the definition of Nyquist frequency i am using is Fs/2 . some people (even O&S, which is a damn shame), might define Nyquist as the bandwidth of the continuous-time signal being sampled. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
On Sat, 01 Nov 2014 15:50:38 +0000, alb wrote:

> Hi Tim, > Tim Wescott <seemywebsite@myfooter.really> wrote: > [] >>> Why it cannot be considered 'decimation'? I'm just reducing the >>> sampling rate of a signal, isn't that right? >> >> It's not that it cannot be considered decimation, so much as it's quite >> a stretch to do so. Particularly because you can't possibly have an >> encoder with 240000 lines -- you've almost certainly got an encoder >> with 16384 or fewer (probably 4096) that's taking analog readings of >> the light and interpolating the extra bits. > > I see, well I actually have no clue what's the implementation and how do > they get to that precision. I've found though encoders working with > interpolation as you mentioned (up to 18000 lines). > > [] >>> Ok, so there's no 'Nyquist frequency' violation if we are >>> undersampling information, no aliasing effect that needs to be taken >>> into account, is that correct? >> >> Uh... >> >> Things are different in control loops. Generally, if it's just the >> control loop that's the issue, your loop speed is so far below the >> sampling rate that Nyquist and all that really isn't an issue. >> >> HOWEVER: If you have some noise that's bothersome, and if that noise >> can be shifted down to DC by the sampling, then it's an issue. Isn't >> that nice? > > That's very nice! So if I understood you correctly what I'm doing with > undersampling is getting the noise density above my sampling frequency > and aliasing it. That's what I thought in the first place.
I was being sarcastic and thought you'd pick it up. As a concrete example, if you're sampling at 8kHz and you've got significant noise at 8002Hz, then after sampling that noise will appear at 2Hz. 2Hz is probably well within your control loop's bandwidth, so your controller will dutifully make sure that the 2Hz signal is eliminated from the position feedback -- by making the assembly flap around at 2Hz. This is NOT a problem of the control loop itself: it is an issue with the control loop, the sampling, AND the noise.
>>> 1. I'm not so sure I can answer this question, I know my loop is >>> working at 3 KHz. I suppose an input running at 25 KHz is not limiting >>> the operation of the loop. For that matter the loop itself is only >>> looking at ~1/8 samples. >> >> If you mean your loop is only sampled at 3kHz, then the 25kHz isn't an >> issue. >> >> At this point you ARE decimating, and it may be worthwhile to consider >> some very judicious filtering. About the only kind that I'd >> contemplate is a filter that decimates by N and averages (or sums) by N >> -- you end up with a comb filter with nulls at all harmonics of the >> sampling rate (so it totally undermines any noise aliasing), at the >> best possible phase shift to attenuation ratio for anything that may >> alias down. > > I'm sorry but I think I lost you here. I understood that noise can be > aliased down around DC where my signal is (~1.2Hz) but I haven't > understood how the comb filter may undermine aliasing.
If you take my 8kHz sampling example above, an average-and-decimate filter will have a frequency response of sinc(pi*f/8000Hz). Its response will be 1 at DC, nearly 1 at 2Hz, zero at 8kHz, and about 0.00025 at 8002Hz. Without the average-and-decimate filter the signal at 8002Hz would come through at full strength. If you figure out the phase delay in the filter vs. the amount of attenuation you for signals that will alias to within your loop passband, you'll find that the average-and-decimate filter tends to be more favorable than just about any other kind of anti-aliasing filters.
>>> 2. Noise is not known, we provide the implementation of the control, >>> but parameters tuning is done by the customer. Yet I'd like to know if >>> I need to take precautions against noise. >> >> You'll find out. Personally I think that's an unwise place to split >> the task, but if your customer is supplying the money, and your group >> was smart enough to arrange the contract so that they pay for effort >> and not results, then you should be fine. > > I've always found bizarre that the motor controller has been separated > from the motor and encoder themselves (which might be also done by two > different groups). One thing is responsibility for a working system (we > are not responsible) and customer satisfaction. At the end of the day, > when things are not working tension will arise and an unsatisfied > customer is never a good thing to have.
It can be awkward when a customer is asking for something that will not lead to joy.
>>> Actuallyi, talking about noise the customer wants to get rid of >>> 'spourious' readings but while we are sampling, the motor is moving so >>> thresholds over a mean is not really the best way to get rid of those >>> values. >>> >>> One possibility is to take the maximum velocity of the motor and >>> compare it to the current velocity, if the point is way beyond then >>> something has gone wrong and we can throw the value away. At the >>> moment I cannot think something more efficient. >> >> Hard to say what's the best answer -- it depends on what's making the >> problem. Often the best answer is to fix the root problem, rather than >> trying to put bandaids over it. > > Sometimes the problem isn't fixable. A spourious value can be there > because of a heavy ion commuting the state of a register and here you go > with your crazy value. Failure analysis usually leads to countermeasures > to be implemented because you cannot get rid of the root cause. >
True. If root cause analysis is being done, and the root cause really is unfixable, then of course you need to do something else. -- www.wescottdesign.com
On Saturday, November 1, 2014 4:09:48 PM UTC-4, Tim Wescott wrote:
> On Sat, 01 Nov 2014 15:50:38 +0000, alb wrote: > > > Hi Tim, > > Tim Wescott <seemywebsite@myfooter.really> wrote: > > [] > >>> Why it cannot be considered 'decimation'? I'm just reducing the > >>> sampling rate of a signal, isn't that right? > >> > >> It's not that it cannot be considered decimation, so much as it's quite > >> a stretch to do so. Particularly because you can't possibly have an > >> encoder with 240000 lines -- you've almost certainly got an encoder > >> with 16384 or fewer (probably 4096) that's taking analog readings of > >> the light and interpolating the extra bits. > > > > I see, well I actually have no clue what's the implementation and how do > > they get to that precision. I've found though encoders working with > > interpolation as you mentioned (up to 18000 lines). > > > > [] > >>> Ok, so there's no 'Nyquist frequency' violation if we are > >>> undersampling information, no aliasing effect that needs to be taken > >>> into account, is that correct? > >> > >> Uh... > >> > >> Things are different in control loops. Generally, if it's just the > >> control loop that's the issue, your loop speed is so far below the > >> sampling rate that Nyquist and all that really isn't an issue. > >> > >> HOWEVER: If you have some noise that's bothersome, and if that noise > >> can be shifted down to DC by the sampling, then it's an issue. Isn't > >> that nice? > > > > That's very nice! So if I understood you correctly what I'm doing with > > undersampling is getting the noise density above my sampling frequency > > and aliasing it. That's what I thought in the first place. > > I was being sarcastic and thought you'd pick it up. As a concrete > example, if you're sampling at 8kHz and you've got significant noise at > 8002Hz, then after sampling that noise will appear at 2Hz. 2Hz is > probably well within your control loop's bandwidth, so your controller > will dutifully make sure that the 2Hz signal is eliminated from the > position feedback -- by making the assembly flap around at 2Hz. > > This is NOT a problem of the control loop itself: it is an issue with the > control loop, the sampling, AND the noise. > > >>> 1. I'm not so sure I can answer this question, I know my loop is > >>> working at 3 KHz. I suppose an input running at 25 KHz is not limiting > >>> the operation of the loop. For that matter the loop itself is only > >>> looking at ~1/8 samples. > >> > >> If you mean your loop is only sampled at 3kHz, then the 25kHz isn't an > >> issue. > >> > >> At this point you ARE decimating, and it may be worthwhile to consider > >> some very judicious filtering. About the only kind that I'd > >> contemplate is a filter that decimates by N and averages (or sums) by N > >> -- you end up with a comb filter with nulls at all harmonics of the > >> sampling rate (so it totally undermines any noise aliasing), at the > >> best possible phase shift to attenuation ratio for anything that may > >> alias down. > > > > I'm sorry but I think I lost you here. I understood that noise can be > > aliased down around DC where my signal is (~1.2Hz) but I haven't > > understood how the comb filter may undermine aliasing. > > If you take my 8kHz sampling example above, an average-and-decimate > filter will have a frequency response of sinc(pi*f/8000Hz). Its response > will be 1 at DC, nearly 1 at 2Hz, zero at 8kHz, and about 0.00025 at > 8002Hz. Without the average-and-decimate filter the signal at 8002Hz > would come through at full strength. > > If you figure out the phase delay in the filter vs. the amount of > attenuation you for signals that will alias to within your loop passband, > you'll find that the average-and-decimate filter tends to be more > favorable than just about any other kind of anti-aliasing filters. > > >>> 2. Noise is not known, we provide the implementation of the control, > >>> but parameters tuning is done by the customer. Yet I'd like to know if > >>> I need to take precautions against noise. > >> > >> You'll find out. Personally I think that's an unwise place to split > >> the task, but if your customer is supplying the money, and your group > >> was smart enough to arrange the contract so that they pay for effort > >> and not results, then you should be fine. > > > > I've always found bizarre that the motor controller has been separated > > from the motor and encoder themselves (which might be also done by two > > different groups). One thing is responsibility for a working system (we > > are not responsible) and customer satisfaction. At the end of the day, > > when things are not working tension will arise and an unsatisfied > > customer is never a good thing to have. > > It can be awkward when a customer is asking for something that will not > lead to joy. > > >>> Actuallyi, talking about noise the customer wants to get rid of > >>> 'spourious' readings but while we are sampling, the motor is moving so > >>> thresholds over a mean is not really the best way to get rid of those > >>> values. > >>> > >>> One possibility is to take the maximum velocity of the motor and > >>> compare it to the current velocity, if the point is way beyond then > >>> something has gone wrong and we can throw the value away. At the > >>> moment I cannot think something more efficient. > >> > >> Hard to say what's the best answer -- it depends on what's making the > >> problem. Often the best answer is to fix the root problem, rather than > >> trying to put bandaids over it. > > > > Sometimes the problem isn't fixable. A spourious value can be there > > because of a heavy ion commuting the state of a register and here you go > > with your crazy value. Failure analysis usually leads to countermeasures > > to be implemented because you cannot get rid of the root cause. > > > > True. If root cause analysis is being done, and the root cause really is > unfixable, then of course you need to do something else. > > -- > www.wescottdesign.com
One factor regarding filtering/"decimation"/etc, is that if there's any delay (e.g. from decimating), then that will make the "measured" position not match the real motor position. Another way you could look at it is to just pretend you're sampling at your control-loop rate and ignore the extra samples you're being sent. If they're from a digital read head, there won't really be any noise anyway. Also, are you doing position-mode or velocity-mode control, and is the motor turning around hundreds/thousands of times or just 1 revolution? And what type of motor? If it's e.g. a 3-phase brushless "dc" motor, then practically speaking you just need to sample fast enough that at full speed it hasn't gone more than a few dozen degrees (this is what would really be the "alias" limit of your sampling frequency. HTH -Mike
nice to see you here, Mike.

still got that house in Cambridge?  i was down there last night.

L8r,

r b-j

On 11/1/14 8:29 PM, Michael Shonle wrote:
> On Saturday, November 1, 2014 4:09:48 PM UTC-4, Tim Wescott wrote: >> On Sat, 01 Nov 2014 15:50:38 +0000, alb wrote: >> >>> Hi Tim, >>> Tim Wescott<seemywebsite@myfooter.really> wrote: >>> [] >>>>> Why it cannot be considered 'decimation'? I'm just reducing the >>>>> sampling rate of a signal, isn't that right? >>>> >>>> It's not that it cannot be considered decimation, so much as it's quite >>>> a stretch to do so. Particularly because you can't possibly have an >>>> encoder with 240000 lines -- you've almost certainly got an encoder >>>> with 16384 or fewer (probably 4096) that's taking analog readings of >>>> the light and interpolating the extra bits. >>> >>> I see, well I actually have no clue what's the implementation and how do >>> they get to that precision. I've found though encoders working with >>> interpolation as you mentioned (up to 18000 lines). >>> >>> [] >>>>> Ok, so there's no 'Nyquist frequency' violation if we are >>>>> undersampling information, no aliasing effect that needs to be taken >>>>> into account, is that correct? >>>> >>>> Uh... >>>> >>>> Things are different in control loops. Generally, if it's just the >>>> control loop that's the issue, your loop speed is so far below the >>>> sampling rate that Nyquist and all that really isn't an issue. >>>> >>>> HOWEVER: If you have some noise that's bothersome, and if that noise >>>> can be shifted down to DC by the sampling, then it's an issue. Isn't >>>> that nice? >>> >>> That's very nice! So if I understood you correctly what I'm doing with >>> undersampling is getting the noise density above my sampling frequency >>> and aliasing it. That's what I thought in the first place. >> >> I was being sarcastic and thought you'd pick it up. As a concrete >> example, if you're sampling at 8kHz and you've got significant noise at >> 8002Hz, then after sampling that noise will appear at 2Hz. 2Hz is >> probably well within your control loop's bandwidth, so your controller >> will dutifully make sure that the 2Hz signal is eliminated from the >> position feedback -- by making the assembly flap around at 2Hz. >> >> This is NOT a problem of the control loop itself: it is an issue with the >> control loop, the sampling, AND the noise. >> >>>>> 1. I'm not so sure I can answer this question, I know my loop is >>>>> working at 3 KHz. I suppose an input running at 25 KHz is not limiting >>>>> the operation of the loop. For that matter the loop itself is only >>>>> looking at ~1/8 samples. >>>> >>>> If you mean your loop is only sampled at 3kHz, then the 25kHz isn't an >>>> issue. >>>> >>>> At this point you ARE decimating, and it may be worthwhile to consider >>>> some very judicious filtering. About the only kind that I'd >>>> contemplate is a filter that decimates by N and averages (or sums) by N >>>> -- you end up with a comb filter with nulls at all harmonics of the >>>> sampling rate (so it totally undermines any noise aliasing), at the >>>> best possible phase shift to attenuation ratio for anything that may >>>> alias down. >>> >>> I'm sorry but I think I lost you here. I understood that noise can be >>> aliased down around DC where my signal is (~1.2Hz) but I haven't >>> understood how the comb filter may undermine aliasing. >> >> If you take my 8kHz sampling example above, an average-and-decimate >> filter will have a frequency response of sinc(pi*f/8000Hz). Its response >> will be 1 at DC, nearly 1 at 2Hz, zero at 8kHz, and about 0.00025 at >> 8002Hz. Without the average-and-decimate filter the signal at 8002Hz >> would come through at full strength. >> >> If you figure out the phase delay in the filter vs. the amount of >> attenuation you for signals that will alias to within your loop passband, >> you'll find that the average-and-decimate filter tends to be more >> favorable than just about any other kind of anti-aliasing filters. >> >>>>> 2. Noise is not known, we provide the implementation of the control, >>>>> but parameters tuning is done by the customer. Yet I'd like to know if >>>>> I need to take precautions against noise. >>>> >>>> You'll find out. Personally I think that's an unwise place to split >>>> the task, but if your customer is supplying the money, and your group >>>> was smart enough to arrange the contract so that they pay for effort >>>> and not results, then you should be fine. >>> >>> I've always found bizarre that the motor controller has been separated >>> from the motor and encoder themselves (which might be also done by two >>> different groups). One thing is responsibility for a working system (we >>> are not responsible) and customer satisfaction. At the end of the day, >>> when things are not working tension will arise and an unsatisfied >>> customer is never a good thing to have. >> >> It can be awkward when a customer is asking for something that will not >> lead to joy. >> >>>>> Actuallyi, talking about noise the customer wants to get rid of >>>>> 'spourious' readings but while we are sampling, the motor is moving so >>>>> thresholds over a mean is not really the best way to get rid of those >>>>> values. >>>>> >>>>> One possibility is to take the maximum velocity of the motor and >>>>> compare it to the current velocity, if the point is way beyond then >>>>> something has gone wrong and we can throw the value away. At the >>>>> moment I cannot think something more efficient. >>>> >>>> Hard to say what's the best answer -- it depends on what's making the >>>> problem. Often the best answer is to fix the root problem, rather than >>>> trying to put bandaids over it. >>> >>> Sometimes the problem isn't fixable. A spourious value can be there >>> because of a heavy ion commuting the state of a register and here you go >>> with your crazy value. Failure analysis usually leads to countermeasures >>> to be implemented because you cannot get rid of the root cause. >>> >> >> True. If root cause analysis is being done, and the root cause really is >> unfixable, then of course you need to do something else. >> >> -- >> www.wescottdesign.com > > One factor regarding filtering/"decimation"/etc, is that if there's any delay
(e.g. from decimating), then that will make the "measured" position not match the real motor position. Another way you could look at it is to just pretend you're sampling at your control-loop rate and ignore the extra samples you're being sent. If they're from a digital read head, there won't really be any noise anyway. Also, are you doing position-mode or velocity-mode control, and is the motor turning around hundreds/thousands of times or just 1 revolution? And what type of motor? If it's e.g. a 3-phase brushless "dc" motor, then practically speaking you just need to sample fast enough that at full speed it hasn't gone more than a few dozen degrees (this is what would really be the "alias" limit of your sampling frequency.
> > HTH > -Mike
-- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Hi Tim,

Tim Wescott <tim@seemywebsite.com> wrote:
[]
>> That's very nice! So if I understood you correctly what I'm doing with >> undersampling is getting the noise density above my sampling frequency >> and aliasing it. That's what I thought in the first place. > > I was being sarcastic and thought you'd pick it up.
I did pick up your sarcasm indeed, but I failed to emphasize it enough in my reply. The /best/ thing about this whole story is that now I have my microvibration environment on top of my set of bldc motors and undersampling may simply be a receipt for failure!
> As a concrete > example, if you're sampling at 8kHz and you've got significant noise at > 8002Hz, then after sampling that noise will appear at 2Hz. 2Hz is > probably well within your control loop's bandwidth, so your controller > will dutifully make sure that the 2Hz signal is eliminated from the > position feedback -- by making the assembly flap around at 2Hz. > > This is NOT a problem of the control loop itself: it is an issue with the > control loop, the sampling, AND the noise.
Meaning, in order for the control loop to work properly, signal *must* be treated to avoid issues. []
>>> At this point you ARE decimating, and it may be worthwhile to consider >>> some very judicious filtering. About the only kind that I'd >>> contemplate is a filter that decimates by N and averages (or sums) by N >>> -- you end up with a comb filter with nulls at all harmonics of the >>> sampling rate (so it totally undermines any noise aliasing), at the >>> best possible phase shift to attenuation ratio for anything that may >>> alias down. >> >> I'm sorry but I think I lost you here. I understood that noise can be >> aliased down around DC where my signal is (~1.2Hz) but I haven't >> understood how the comb filter may undermine aliasing. > > If you take my 8kHz sampling example above, an average-and-decimate > filter will have a frequency response of sinc(pi*f/8000Hz). Its response > will be 1 at DC, nearly 1 at 2Hz, zero at 8kHz, and about 0.00025 at > 8002Hz. Without the average-and-decimate filter the signal at 8002Hz > would come through at full strength.
Ok, so is the attenuation of the 8002 Hz component that helps us reduce the 2Hz aliased signal. Of course this means spectral information for the environment shall be available in order to correctly define sampling rate *and* filter definition.
> If you figure out the phase delay in the filter vs. the amount of > attenuation you for signals that will alias to within your loop passband, > you'll find that the average-and-decimate filter tends to be more > favorable than just about any other kind of anti-aliasing filters.
Why not a low-pass filter? Is it a matter of 'complexity'? What I can do is to show what's the effect of some type of noise on our system and warn our customer about the lack of a specification for the filtering stage. They ought to know the microvibration environment at instrument and platform level so they can specify what we should implement. For the time being I only see a potential flaw in their specification (the lack of a filter). []
>> I've always found bizarre that the motor controller has been separated >> from the motor and encoder themselves (which might be also done by two >> different groups). One thing is responsibility for a working system (we >> are not responsible) and customer satisfaction. At the end of the day, >> when things are not working tension will arise and an unsatisfied >> customer is never a good thing to have. > > It can be awkward when a customer is asking for something that will not > lead to joy.
True, but there are geopolitical needs and constraints to do so, yet we could have been more proactive and propose to split the system differently. No matter how contracts and Statement of Compliances are done, it's unwise to play dumb and 'just do what they asked for'. But I'd be happy if at least I can demonstrate the issue and launch a warning. []
>> Sometimes the problem isn't fixable. A spourious value can be there >> because of a heavy ion commuting the state of a register and here you go >> with your crazy value. Failure analysis usually leads to countermeasures >> to be implemented because you cannot get rid of the root cause. >> > > True. If root cause analysis is being done, and the root cause really is > unfixable, then of course you need to do something else.
A low-pass filter will definitely dump the spikes, I'm not sure about an average. Al