Decimation/interpolation filters issue when sample rate ratio is variable

Hi fellows,

I'm still on my way with the same project, 
but now, it seems that I'm stuck and need a hint,
any pointing into the right direction...
seems like a brain deadlock which needs an escape...

Background:
A signal is sampled at 48kS/s.
It carries information which is related to a position vector. 
Since speed is varying, position and time are not proportional,
though they are related.

I create a position related stream by picking the current sample out 
of the isochronous stream at every pulse of a position clock.
(a sort of downsampling with a variable factor of 1...250 or even 
more)

This new stream is now filtered (application specific).

Then the stream is put back into the isochronous mode for 
evaluation/display purposes (with same factor as before:
still variable, but well-known at that certain moment).

Basically, what I do is this:

downsampling (var) -> applic.filter -> upsampling (var)

What I want is that:
decimation (var) -> applic.filter -> interpolation (var)

Difference is in the decimation/interpolation filters.

Special challenge is the variable rate of the slower clock.

Since the lower rate depends on an externally applied signal,
I cannot predict it, and I cannot assume that it's constant.

Now, what could I do to avoid aliasing/imaging effects as far as 
possible?

I cannot imagine a good decimation filter which works under these 
circumstances (with unpredictable filter length), except this one:

1/N*sum(z^(1-N)) with sum over 1..N

which is a simple averager, chosen, because all coefficients are
equal and therefore it can be evaluated without pre-knowledge of the 
filter length.

Again for the interpolation filter: 
 the only sort of interpolation filter I can imagine, is this:
 hold the latest sample and repeat it until a newer one exists.
Zero-stuffing seems inappropriate because I cannot delay the output 
until the next real input sample to the interpolator arrives - 
seems as if things would get worse with zero-stuffing.

I feel unhappy with these solutions, since they are not 
state-of-the-art. 

I'm quite sure that there are better ways to go.
Any proposals appreciated.

Bernhard 

Hi bernhard
	I think the issue is what does the noise (call it noise for want of a
better word) of your sampling process look like. If there were no noise
then you could just take the current sample at each tick of the position
clock. Is there any reason to believe that a sample at a given position
is going to be different when the process is slowed down just because
you collected a bunch of extra samples in between. If it is different
(or you believe it is) you need to know what frequencies are altered (or
added) when the process slows down. This probably means knowing
something about the frequency response of the measuring device WRT
speed. The only way to know that is by experimentation with known fixed
speeds. 
	If I remember correctly from your last post you are trying to detect
defects which appear as impulses. So it would seem a fairly simple
process of examining what the same impulse (defect) looks like at
different constant speeds. That should pretty much tell you what sort of
filter is needed to make them all look alike.

-jim 	


Bernhard Holzmayer wrote:
> 
> Hi fellows,
> 
> I'm still on my way with the same project,
> but now, it seems that I'm stuck and need a hint,
> any pointing into the right direction...
> seems like a brain deadlock which needs an escape...
> 
> Background:
> A signal is sampled at 48kS/s.
> It carries information which is related to a position vector.
> Since speed is varying, position and time are not proportional,
> though they are related.
> 
> I create a position related stream by picking the current sample out
> of the isochronous stream at every pulse of a position clock.
> (a sort of downsampling with a variable factor of 1...250 or even
> more)
> 
> This new stream is now filtered (application specific).
> 
> Then the stream is put back into the isochronous mode for
> evaluation/display purposes (with same factor as before:
> still variable, but well-known at that certain moment).
> 
> Basically, what I do is this:
> 
> downsampling (var) -> applic.filter -> upsampling (var)
> 
> What I want is that:
> decimation (var) -> applic.filter -> interpolation (var)
> 
> Difference is in the decimation/interpolation filters.
> 
> Special challenge is the variable rate of the slower clock.
> 
> Since the lower rate depends on an externally applied signal,
> I cannot predict it, and I cannot assume that it's constant.
> 
> Now, what could I do to avoid aliasing/imaging effects as far as
> possible?
> 
> I cannot imagine a good decimation filter which works under these
> circumstances (with unpredictable filter length), except this one:
> 
> 1/N*sum(z^(1-N)) with sum over 1..N
> 
> which is a simple averager, chosen, because all coefficients are
> equal and therefore it can be evaluated without pre-knowledge of the
> filter length.
> 
> Again for the interpolation filter:
>  the only sort of interpolation filter I can imagine, is this:
>  hold the latest sample and repeat it until a newer one exists.
> Zero-stuffing seems inappropriate because I cannot delay the output
> until the next real input sample to the interpolator arrives -
> seems as if things would get worse with zero-stuffing.
> 
> I feel unhappy with these solutions, since they are not
> state-of-the-art.
> 
> I'm quite sure that there are better ways to go.
> Any proposals appreciated.
> 
> Bernhard


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

jim wrote:

> Hi bernhard
>         I think the issue is what does the noise (call it noise
>         for want of a
> better word) of your sampling process look like. If there were no
> noise then you could just take the current sample at each tick of
> the position clock. Is there any reason to believe that a sample
> at a given position is going to be different when the process is
> slowed down just because you collected a bunch of extra samples in
> between. If it is different (or you believe it is) you need to
> know what frequencies are altered (or added) when the process
> slows down. This probably means knowing something about the
> frequency response of the measuring device WRT speed. The only way
> to know that is by experimentation with known fixed speeds.
>         If I remember correctly from your last post you are trying
>         to detect
> defects which appear as impulses. So it would seem a fairly simple
> process of examining what the same impulse (defect) looks like at
> different constant speeds. That should pretty much tell you what
> sort of filter is needed to make them all look alike.
> 
> -jim
> 

Thanks for the response, Jim.
You remember fairly well, what I'm doing.
Yes, the defects appear as impulses.
And, I'm pretty sure from the physics that they scale with the 
speed. That's the reason why I'm going to do it this way.
(The once time variant application filter at position rate becomes 
quite simple and invariant after transformation from time to 
position).

Since most of the signal content will scale with speed too, it would 
be enough to just pick one sample out of the set (if no other 
signal content would exist).
On the other hand, I must assume that there's considerable noise 
which does not scale down. Without a decimation filter, aliasing 
would result.

I cannot predict the noise because my solution shall be able to deal 
with different environments, in different applications - to 
restrict a solution to "noise-free" environments would be too hard.

Bernhard 

"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:1176462.lnuKDRrfKf@holzmayer.ifr.rt...
> jim wrote:
>
> > Hi bernhard
> >         I think the issue is what does the noise (call it noise
> >         for want of a
> > better word) of your sampling process look like. If there were no
> > noise then you could just take the current sample at each tick of
> > the position clock. Is there any reason to believe that a sample
> > at a given position is going to be different when the process is
> > slowed down just because you collected a bunch of extra samples in
> > between. If it is different (or you believe it is) you need to
> > know what frequencies are altered (or added) when the process
> > slows down. This probably means knowing something about the
> > frequency response of the measuring device WRT speed. The only way
> > to know that is by experimentation with known fixed speeds.
> >         If I remember correctly from your last post you are trying
> >         to detect
> > defects which appear as impulses. So it would seem a fairly simple
> > process of examining what the same impulse (defect) looks like at
> > different constant speeds. That should pretty much tell you what
> > sort of filter is needed to make them all look alike.
> >
> > -jim
> >
>
> Thanks for the response, Jim.
> You remember fairly well, what I'm doing.
> Yes, the defects appear as impulses.
> And, I'm pretty sure from the physics that they scale with the
> speed. That's the reason why I'm going to do it this way.
> (The once time variant application filter at position rate becomes
> quite simple and invariant after transformation from time to
> position).
>
> Since most of the signal content will scale with speed too, it would
> be enough to just pick one sample out of the set (if no other
> signal content would exist).
> On the other hand, I must assume that there's considerable noise
> which does not scale down. Without a decimation filter, aliasing
> would result.
>
> I cannot predict the noise because my solution shall be able to deal
> with different environments, in different applications - to
> restrict a solution to "noise-free" environments would be too hard.

Bernhard,

I don't understand your situation very well from the description.  But, I
wonder if you might be able to use an old trick that's used in spectrum
analysis of machinery noise?

Would it be possible to clock the data at a rate that varies with what you
refer to as "speed".  For example, could you clock the data from a binary
tachometer - or a phase-locked frequency multiple thereof?  In doing this,
you convert from a time base to a radian base.

Machinery noise can be sampled this way and subsequently spectrum analyzed.
Any vibrations that are rotation related show up clearly even in the face of
lots of shaft rotation speed variations.  Of course, the x-axis out of a
spectrum anayzer isn't "frequency" any more, it's in terms of something like
"events per rotation".
So, filtering this data with a digital filter would result in the same kind
of thing - you'd be filtering out in the "events per rotation" space.

Note that this type of data collection has no impact on the filtering
process - so you could use a FIR or IIR filter on the data directly.
Software doesn't have a time base - just an index.  It's just that we
normally think of the index being related to a time base.  But, in this
case, it could just as easily be related to a rotation interval.

Now, if you can't sample the data at time intervals derived from speed then
you might interpolate the data and resample if you have measures of speed or
shaft position taken in parallel.  The end result can be improved SNR.

Fred

Bernhard Holzmayer <holzmayer.bernhard@deadspam.com> wrote in message news:<1176462.lnuKDRrfKf@holzmayer.ifr.rt>...
> jim wrote:
> 
> > Hi bernhard
> >         I think the issue is what does the noise (call it noise
> >         for want of a
> > better word) of your sampling process look like. If there were no
> > noise then you could just take the current sample at each tick of
> > the position clock. Is there any reason to believe that a sample
> > at a given position is going to be different when the process is
> > slowed down just because you collected a bunch of extra samples in
> > between. If it is different (or you believe it is) you need to
> > know what frequencies are altered (or added) when the process
> > slows down. This probably means knowing something about the
> > frequency response of the measuring device WRT speed. The only way
> > to know that is by experimentation with known fixed speeds.
> >         If I remember correctly from your last post you are trying
> >         to detect
> > defects which appear as impulses. So it would seem a fairly simple
> > process of examining what the same impulse (defect) looks like at
> > different constant speeds. That should pretty much tell you what
> > sort of filter is needed to make them all look alike.
> > 
> > -jim
> > 
> 
> Thanks for the response, Jim.
> You remember fairly well, what I'm doing.
> Yes, the defects appear as impulses.
> And, I'm pretty sure from the physics that they scale with the 
> speed. That's the reason why I'm going to do it this way.
> (The once time variant application filter at position rate becomes 
> quite simple and invariant after transformation from time to 
> position).
> 
> Since most of the signal content will scale with speed too, it would 
> be enough to just pick one sample out of the set (if no other 
> signal content would exist).
> On the other hand, I must assume that there's considerable noise 
> which does not scale down. Without a decimation filter, aliasing 
> would result.
> 
> I cannot predict the noise because my solution shall be able to deal 
> with different environments, in different applications - to 
> restrict a solution to "noise-free" environments would be too hard.
> 
> Bernhard

A variable rate decimator can be implemented with a numerically
controlled oscillator (NCO) and a polynomial interpolator, as 
described in Part 1 of "Interpolation in Digital Modems" by Floyd
Gardner in IEEE Trans Comm. The idea is to lock your NCO onto
the rate control signal. The NCO is basically a counter that rolls
over once per cycle of the control signal. Every time the counter
rolls over, you need to compute an output from the signal to be
decimated. The value of the counter after the rollover is used to
compute coefficients of an interpolating polynomial that operates
on a group of samples in a window around the rollover point. This
method is fairly standard in modems, where the bit clock is 
asynchronous to the A/D that sampled the analog signal. 

John

Fred Marshall wrote:

> 
> "Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in
> message news:1176462.lnuKDRrfKf@holzmayer.ifr.rt...
>> jim wrote:
>>
>> > Hi bernhard
>> >         I think the issue is what does the noise (call it noise
>> >         for want of a
>> > better word) of your sampling process look like. If there were
>> > no noise then you could just take the current sample at each
>> > tick of the position clock. Is there any reason to believe that
>> > a sample at a given position is going to be different when the
>> > process is slowed down just because you collected a bunch of
>> > extra samples in between. If it is different (or you believe it
>> > is) you need to know what frequencies are altered (or added)
>> > when the process slows down. This probably means knowing
>> > something about the frequency response of the measuring device
>> > WRT speed. The only way to know that is by experimentation with
>> > known fixed speeds.
>> >         If I remember correctly from your last post you are
>> >         trying to detect
>> > defects which appear as impulses. So it would seem a fairly
>> > simple process of examining what the same impulse (defect)
>> > looks like at different constant speeds. That should pretty
>> > much tell you what sort of filter is needed to make them all
>> > look alike.
>> >
>> > -jim
>> >
>>
>> Thanks for the response, Jim.
>> You remember fairly well, what I'm doing.
>> Yes, the defects appear as impulses.
>> And, I'm pretty sure from the physics that they scale with the
>> speed. That's the reason why I'm going to do it this way.
>> (The once time variant application filter at position rate
>> becomes quite simple and invariant after transformation from time
>> to position).
>>
>> Since most of the signal content will scale with speed too, it
>> would be enough to just pick one sample out of the set (if no
>> other signal content would exist).
>> On the other hand, I must assume that there's considerable noise
>> which does not scale down. Without a decimation filter, aliasing
>> would result.
>>
>> I cannot predict the noise because my solution shall be able to
>> deal with different environments, in different applications - to
>> restrict a solution to "noise-free" environments would be too
>> hard.
> 
> Bernhard,
> 
> I don't understand your situation very well from the description. 
> But, I wonder if you might be able to use an old trick that's used
> in spectrum analysis of machinery noise?
> 
> Would it be possible to clock the data at a rate that varies with
> what you
> refer to as "speed".  For example, could you clock the data from a
> binary
> tachometer - or a phase-locked frequency multiple thereof?  In
> doing this, you convert from a time base to a radian base.
That's exactly my situation: There is a tachometer, it's even 
better: it gives me a constant number of pulses per mm.
Since the effects which I investigate, are caused by surface effects 
which are related to positions, that's exactly the clock which I 
need - and that's exactly what you describe.
> 
> Machinery noise can be sampled this way and subsequently spectrum
> analyzed. Any vibrations that are rotation related show up clearly
> even in the face of
> lots of shaft rotation speed variations.  Of course, the x-axis
> out of a spectrum anayzer isn't "frequency" any more, it's in
> terms of something like "events per rotation".
Correct.
> So, filtering this data with a digital filter would result in the
> same kind of thing - you'd be filtering out in the "events per
> rotation" space.
Yes. 
> 
> Note that this type of data collection has no impact on the
> filtering process - so you could use a FIR or IIR filter on the
> data directly.
I see, and that's why I'm going to do it this way.
All once difficult (speed-variant) filtering transforms to a 
straight-forward IIR filter.
> Software doesn't have a time base - just an index.  It's just that
> we
> normally think of the index being related to a time base.  
> But, in this case, it could just as easily be related to a 
> rotation interval.
It's not so easy to transform the thinking!
> ...
> Fred

All right, you got it - and I see that you're not unexperienced with 
this stuff.
I build a mock-up scenario and tested it. All works pretty much as 
expected. So, it's obviously a fine approach.

To show you, what concern bothers me, let's assume a signal with 
frequency content from DC to 20kHz.
At a high positional clock rate (high speed), it will be sampled at 
some 40kS/s or more, then the mentioned IIR cuts away everything 
outside a band of 10...15kHz.
Now let's assume that positional clock rate (speed) is lower, which 
might result in a momentary sampling rate of 20kS/s. The IIR filter 
will scale accordingly, and filter the signal at 5...7,5kHz.
But Nyquist requires that the signal is bandlimited to 0...10kHz.
If sampling rate were at 1kS/s, legal band would range from 
0...500Hz. 
That's what the decimation filter usually deals with.
And that's what I don't have and don't know how I should realize it.
Since there are certainly frequency components (noise) which do not 
scale with speed, I cannot neglect this. 

If you remember that old trick, with machinery noise. How did they 
overcome the influence of noise which didn't scale with rotational 
speed? Just ignore the problem?

Bernhard 

Bernhard Holzmayer wrote:

> Fred Marshall wrote:
   ...

>>Bernhard,
>>
>>I don't understand your situation very well from the description. 
>>But, I wonder if you might be able to use an old trick that's used
>>in spectrum analysis of machinery noise?
>>
>>Would it be possible to clock the data at a rate that varies with
>>what you
>>refer to as "speed".  For example, could you clock the data from a
>>binary
>>tachometer - or a phase-locked frequency multiple thereof?  In
>>doing this, you convert from a time base to a radian base.
> 
> That's exactly my situation: There is a tachometer, it's even 
> better: it gives me a constant number of pulses per mm.
> Since the effects which I investigate, are caused by surface effects 
> which are related to positions, that's exactly the clock which I 
> need - and that's exactly what you describe.
> 
>>Machinery noise can be sampled this way and subsequently spectrum
>>analyzed. Any vibrations that are rotation related show up clearly
>>even in the face of
>>lots of shaft rotation speed variations.  Of course, the x-axis
>>out of a spectrum anayzer isn't "frequency" any more, it's in
>>terms of something like "events per rotation".
> 
> Correct.
> 
>>So, filtering this data with a digital filter would result in the
>>same kind of thing - you'd be filtering out in the "events per
>>rotation" space.
> 
> Yes. 
> 
>>Note that this type of data collection has no impact on the
>>filtering process - so you could use a FIR or IIR filter on the
>>data directly.
> 
> I see, and that's why I'm going to do it this way.
> All once difficult (speed-variant) filtering transforms to a 
> straight-forward IIR filter.
> 
>>Software doesn't have a time base - just an index.  It's just that
>>we
>>normally think of the index being related to a time base.  
>>But, in this case, it could just as easily be related to a 
>>rotation interval.
> 
> It's not so easy to transform the thinking!
> 
>>...
>>Fred
> 
> 
> All right, you got it - and I see that you're not unexperienced with 
> this stuff.
> I build a mock-up scenario and tested it. All works pretty much as 
> expected. So, it's obviously a fine approach.
> 
> To show you, what concern bothers me, let's assume a signal with 
> frequency content from DC to 20kHz.

The content is independent of speed?

> At a high positional clock rate (high speed), it will be sampled at 
> some 40kS/s or more, then the mentioned IIR cuts away everything 
> outside a band of 10...15kHz.


> Now let's assume that positional clock rate (speed) is lower, which 
> might result in a momentary sampling rate of 20kS/s. The IIR filter 
> will scale accordingly, and filter the signal at 5...7,5kHz.
> But Nyquist requires that the signal is bandlimited to 0...10kHz.


The Nyquist limit on the data rate relative to the sample rate is just
like a highway's speed limit. You are not required to go that fast. Do I
not understand?

> If sampling rate were at 1kS/s, legal band would range from 
> 0...500Hz. 
> That's what the decimation filter usually deals with.

You don't need to remove what isn't there. I'm clearly missing something
important. Please try to explain.

> And that's what I don't have and don't know how I should realize it.
> Since there are certainly frequency components (noise) which do not 
> scale with speed, I cannot neglect this. 
> 
> If you remember that old trick, with machinery noise. How did they 
> overcome the influence of noise which didn't scale with rotational 
> speed? Just ignore the problem?

I don't know.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> Bernhard Holzmayer wrote:
> 
>> Fred Marshall wrote:
>    ...
> 
>>>Bernhard,
>>>
>>>I don't understand your situation very well from the description.
>>>But, I wonder if you might be able to use an old trick that's
>>>used in spectrum analysis of machinery noise?
>>>
>>>Would it be possible to clock the data at a rate that varies with
>>>what you
>>>refer to as "speed".  For example, could you clock the data from
>>>a binary
>>>tachometer - or a phase-locked frequency multiple thereof?  In
>>>doing this, you convert from a time base to a radian base.
>> 
>> That's exactly my situation: There is a tachometer, it's even
>> better: it gives me a constant number of pulses per mm.
>> Since the effects which I investigate, are caused by surface
>> effects which are related to positions, that's exactly the clock
>> which I need - and that's exactly what you describe.
>> 
>>>Machinery noise can be sampled this way and subsequently spectrum
>>>analyzed. Any vibrations that are rotation related show up
>>>clearly even in the face of
>>>lots of shaft rotation speed variations.  Of course, the x-axis
>>>out of a spectrum anayzer isn't "frequency" any more, it's in
>>>terms of something like "events per rotation".
>> 
>> Correct.
>> 
>>>So, filtering this data with a digital filter would result in the
>>>same kind of thing - you'd be filtering out in the "events per
>>>rotation" space.
>> 
>> Yes.
>> 
>>>Note that this type of data collection has no impact on the
>>>filtering process - so you could use a FIR or IIR filter on the
>>>data directly.
>> 
>> I see, and that's why I'm going to do it this way.
>> All once difficult (speed-variant) filtering transforms to a
>> straight-forward IIR filter.
>> 
>>>Software doesn't have a time base - just an index.  It's just
>>>that we
>>>normally think of the index being related to a time base.
>>>But, in this case, it could just as easily be related to a
>>>rotation interval.
>> 
>> It's not so easy to transform the thinking!
>> 
>>>...
>>>Fred
>> 
>> 
>> All right, you got it - and I see that you're not unexperienced
>> with this stuff.
>> I build a mock-up scenario and tested it. All works pretty much
>> as expected. So, it's obviously a fine approach.
>> 
>> To show you, what concern bothers me, let's assume a signal with
>> frequency content from DC to 20kHz.
> 
> The content is independent of speed?
The part which I'm interested in: no.
Noise and other dirt effects, maybe yes.

> 
>> At a high positional clock rate (high speed), it will be sampled
>> at some 40kS/s or more, then the mentioned IIR cuts away
>> everything outside a band of 10...15kHz.
> 
> 
>> Now let's assume that positional clock rate (speed) is lower,
>> which might result in a momentary sampling rate of 20kS/s. The
>> IIR filter will scale accordingly, and filter the signal at
>> 5...7,5kHz. But Nyquist requires that the signal is bandlimited
>> to 0...10kHz.
> 
> 
> The Nyquist limit on the data rate relative to the sample rate is
> just like a highway's speed limit. You are not required to go that
> fast. Do I not understand?
I agree. And I know. But the noise on my signal doesn't.
It's just present on my samples without taking notice of the speed 
limit!
And since the noise is present, let's say at 14kHz, this would mean,
that I'm not allowed to drive the line that slow. I may decrease 
speed only downto something above 28kS/s. 
(line speed is a process parameter, which I can measure, but not 
influence)

> 
>> If sampling rate were at 1kS/s, legal band would range from
>> 0...500Hz.
>> That's what the decimation filter usually deals with.
> 
> You don't need to remove what isn't there. I'm clearly missing
> something important. Please try to explain.

Imagine very slow sampling at a rate of 200 samples/s (which is not 
far from reality in my applications). 
Let's assume a signal band from 0...100Hz. 
The content will be a mixture between wanted signal components like 
the ones caused by material defects (these will scale with speed).
Other components are unwanted but unavoidable. There are two sorts 
of them:
- noise from the machinery (bearings, motors,...) which scale with 
speed
- environmental noise (50Hz or 60Hz from mains), speed independent 
vibrations,...

The problem are those sources which don't scale with speed.
The coupling from mains will certainly not scale with speed.
Now, assume that sampling rate decreases with speed to 40 samples/s.

50Hz/60Hz noise persists, but now rides way too fast on that 
highway...


> 
>> And that's what I don't have and don't know how I should realize
>> it. Since there are certainly frequency components (noise) which
>> do not scale with speed, I cannot neglect this.
>> 
>> If you remember that old trick, with machinery noise. How did
>> they overcome the influence of noise which didn't scale with
>> rotational speed? Just ignore the problem?
> 
> I don't know.
Sorry, if you didn't get the context: 
Fred mentioned this trick. This paragraph related to that.
Nevertheless, thanks for trying...
> 
> Jerry

Bernhard

Bernhard Holzmayer wrote:

> Jerry Avins wrote:


   ...

>>The content is independent of speed?
> 
> The part which I'm interested in: no.
> Noise and other dirt effects, maybe yes.

That part not dependent on speed may be coming out of the transducer,
but it probably doesn't represent anything about the process you're
measuring. Is it possibly noise you might somehow reject?

   ...

>>The Nyquist limit on the data rate relative to the sample rate is
>>just like a highway's speed limit. You are not required to go that
>>fast. Do I not understand?
> 
> I agree. And I know. But the noise on my signal doesn't.
> It's just present on my samples without taking notice of the speed 
> limit!

That's all the more reason to believe (from this safe distance!) that
your transducer not only measures eddy currents in the web, but also
picks up noise induced from another source. Does shielding it or
changing its orientation alter the noise? Could the noise be bucked by a
differential design?

> And since the noise is present, let's say at 14kHz, this would mean,
> that I'm not allowed to drive the line that slow. I may decrease 
> speed only downto something above 28kS/s. 
> (line speed is a process parameter, which I can measure, but not 
> influence)

If you can identify the noise source, maybe you can increase its
frequency to the point that a single low-pass filter that doesn't
disturb what you need to measure can block most of it.

>>>If sampling rate were at 1kS/s, legal band would range from
>>>0...500Hz.
>>>That's what the decimation filter usually deals with.
>>
>>You don't need to remove what isn't there. I'm clearly missing
>>something important. Please try to explain.
> 
> 
> Imagine very slow sampling at a rate of 200 samples/s (which is not 
> far from reality in my applications). 
> Let's assume a signal band from 0...100Hz. 
> The content will be a mixture between wanted signal components like 
> the ones caused by material defects (these will scale with speed).
> Other components are unwanted but unavoidable. There are two sorts 
> of them:
> - noise from the machinery (bearings, motors,...) which scale with 
> speed

If you truly sense eddy currents, how are these picked up?

> - environmental noise (50Hz or 60Hz from mains), speed independent 
> vibrations,...

Ah: Hum! Do you use an instrumentation amplifier referenced to the
converter's AGND? IIRC, you have a carrier-based system. A transformer
might replace the I-amp. I can understand hum added to the carrier, but
not modulating it. A band-pass filter at the carrier frequency might
clean up the signal.

> The problem are those sources which don't scale with speed.
> The coupling from mains will certainly not scale with speed.
> Now, assume that sampling rate decreases with speed to 40 samples/s.
> 
> 50Hz/60Hz noise persists, but now rides way too fast on that 
> highway...

   ...

It seems to me, leaning back in my armchair with my feet up on the
ottoman, that your signal is contaminated with possibly removable dreck.
If it were my problem, I would do everything possible to get a clean
analog signal before sampling it. Sometimes, little or nothing is
possible, but I would try to be sure before exploring other approaches.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> Bernhard Holzmayer wrote:
> 
>> Jerry Avins wrote:
> 
> 
>    ...
> 
>>>The content is independent of speed?
>> 
>> The part which I'm interested in: no.
>> Noise and other dirt effects, maybe yes.
> 
> That part not dependent on speed may be coming out of the
> transducer, but it probably doesn't represent anything about the
> process you're measuring. Is it possibly noise you might somehow
> reject?
> 
Yes.
> 
>>>The Nyquist limit on the data rate relative to the sample rate is
>>>just like a highway's speed limit. You are not required to go
>>>that fast. Do I not understand?
>> 
>> I agree. And I know. But the noise on my signal doesn't.
>> It's just present on my samples without taking notice of the
>> speed limit!
> 
> That's all the more reason to believe (from this safe distance!)
> that your transducer not only measures eddy currents in the web,
> but also picks up noise induced from another source. Does
> shielding it or changing its orientation alter the noise? Could
> the noise be bucked by a differential design?
We do all that already. 
Measurement is sometimes not far from noise floor, S/N ratio being 
around 10dB. 
Since there was no reason up to now to differentiate between noise 
which comes from transducer and other sources, I really don't know.
And guessing is not so much a reliable method... 
> 
>> And since the noise is present, let's say at 14kHz, this would
>> mean, that I'm not allowed to drive the line that slow. I may
>> decrease speed only downto something above 28kS/s.
>> (line speed is a process parameter, which I can measure, but not
>> influence)
> 
> If you can identify the noise source, maybe you can increase its
> frequency to the point that a single low-pass filter that doesn't
> disturb what you need to measure can block most of it.
I agree. That came to my mind already. I'll probably end up with a 
mixture: one filter before the decimation process, another after.
The first must deal with the speed independent components, the other 
with the effects which scale.
 
> 
>>>>If sampling rate were at 1kS/s, legal band would range from
>>>>0...500Hz.
>>>>That's what the decimation filter usually deals with.
>>>
>>>You don't need to remove what isn't there. I'm clearly missing
>>>something important. Please try to explain.
>> 
>> 
>> Imagine very slow sampling at a rate of 200 samples/s (which is
>> not far from reality in my applications).
>> Let's assume a signal band from 0...100Hz.
>> The content will be a mixture between wanted signal components
>> like the ones caused by material defects (these will scale with
>> speed). Other components are unwanted but unavoidable. There are
>> two sorts of them:
>> - noise from the machinery (bearings, motors,...) which scale
>> with speed
> 
> If you truly sense eddy currents, how are these picked up?
There's a system of coils with essentially one transmitter and 
another single or differential receiver coil, such arranged, that 
the currents from transmitter to receiver must pass the material 
under test.
Unwanted "noise"  is either from material effects which are of no 
interest, or of the processing machinery (vibrations or distance 
variations coming from straighteners, rolls, punches etc. on this 
or a neighbour line)
> 
>> - environmental noise (50Hz or 60Hz from mains), speed
>> independent vibrations,...
> 
> Ah: Hum! Do you use an instrumentation amplifier referenced to the
> converter's AGND? IIRC, you have a carrier-based system. A
> transformer might replace the I-amp. I can understand hum added to
> the carrier, but not modulating it. A band-pass filter at the
> carrier frequency might clean up the signal.
It was a guess, hopefully I need not worry about this.
> 
>> The problem are those sources which don't scale with speed.
>> The coupling from mains will certainly not scale with speed.
>> Now, assume that sampling rate decreases with speed to 40
>> samples/s.
>> 
>> 50Hz/60Hz noise persists, but now rides way too fast on that
>> highway...
> 
>    ...
> 
> It seems to me, leaning back in my armchair with my feet up on the
> ottoman, that your signal is contaminated with possibly removable
> dreck.  If it were my problem, I would do everything possible to
> get a clean analog signal before sampling it. Sometimes, little or
> nothing is possible, but I would try to be sure before exploring
> other approaches.
> 
> Jerry

In the past, we were doing all that in analog realm.
Most of it with filters.
These filters, which I try to replace by digital filters, and 
especially by filters which scale with speed.

Trying to get your perspective (leaning back in my chair, feet on 
the desk...), I come to this premature conclusion:

I need the static (outer bandpass) filters to remove all the 
non-scaling dreck effects.
I can remove all the scaling effects with the speed-variant filter 
(inner bandpass).
There stays a danger, that unwanted components pass the outer 
bandpass. Of these, we must accept the facts
- that they are present outside the inner filter.
- that aliasing effects make these components fold into the region 
of interest.

The last point leaves me unhappy/challenged.

Bernhard