> 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'?
Sort of. Unless your sampling rate is exceedingly generous you need far
more than a 1st-order low-pass, and the filter absolutely positively must
be minimum phase. You can implement all of this with a 5th- or 6th- or
whatever-order IIR filter, but you end up with something that takes more
time to implement, analyze, and verify than an average-and-dump.
The average-and-dump filter also has very favorable action on random ADC
noise (which your encoder experiences, if it's what I think it is).
> 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).
It may just be a non-problem. It's hard not to borrow trouble when you
don't have information. A warning about vibration or electrical noise
close to your sampling rate may be a good idea, though.
> []
[]
> []
>>> 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.
A moving average, or average-and-dump, _is_ a low-pass filter. So it'll
reduce the spike magnitude.
Be aware, however, that a low-pass filter is effective at filtering out
noise that has zero mean and a mostly-Gaussian distribution. Noise that
spikes every once in a while doesn't meet that criterion -- in that case,
some sort of a median detector, or other filter that identifies outliers
and tosses them, is a good idea.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by alb●November 3, 20142014-11-03
Hi Robert,
robert bristow-johnson <rbj@audioimagination.com> 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.
I did mean 'undersampling'. The useful signal is around 1.2Hz and we
have a table of values (a.k.a. profile) to be executed at 3KHz. Yet the
position is known with a 25KHz rate. So the encoder position is
'undersampled' w.r.t. the control loop and if there's noise it can be
injected right where the signal is.
Now another question I have is about the bandwidth of my control loop.
The simple fact that I'm supposed to drive it at 3 KHz, does it mean the
loop bandwidth is 3 KHz? I don't really see the connection.
> 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.
I follow the same definition as you and I'm aware of the confusion!
Is O&S Oppenheim and Schafer?
Al
Reply by alb●November 3, 20142014-11-03
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
Reply by robert bristow-johnson●November 1, 20142014-11-01
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."
Reply by Michael Shonle●November 1, 20142014-11-01
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
Reply by Tim Wescott●November 1, 20142014-11-01
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
Reply by robert bristow-johnson●November 1, 20142014-11-01
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."
Reply by alb●November 1, 20142014-11-01
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
Reply by Tim Wescott●October 31, 20142014-10-31
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
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