Order Analysis when there is a significant DC offset in signal

[RagMan]

Thanks for reading this. I am using the NI LabVIEW Order Analysis Toolkit to do order analysis of strain gage signals of a part attached to an auto engine. My goal is acquire data from a strain gaged part attached to an engine during its rampup and identify the signifcant orders in the strain signal. I am not able to understand an issue I see with my results in the Order Power Spectrum.

I measure the strain gage signals during the engine run-up using the cDAQ 9235 module (1000 to 6000 rpm in 15 seconds). I also acquire the Tachometer using NI-9402 module (counter). I then converted the strain signals to even angle signals, and did the Order Power Spectrum.

Please the resulting Order Power Spectrum shown in Fig1. What I am finding is that the DC offset in the strain signal shows up as a high amplitude peaks (red or green) in the Order Power Spectrum (Please see Fig 1) around order of 0. Because of these huge peaks around order 0,  the order peaks of real interest around 2 or 3 order (blue or purple) are hard to discern in the graph.

The DC offset shows clearly in the graph of Strain vs RPM (RPM is a linear function of time), so essential this is same as Strain vs Time. The white line in Fig 2 is the DC offset. In this example, the DC offset is constant during the RPM rampup, but more often, the strain gaged part experiences both changing static strain and cyclic strain  as shown in Fig 3. Here the part is undergoing increasing tensile strain, with cyclic strain overlaid on top of that.

My questions are:

Am I missing some key step here in preprocessing?

-- do I need a high pass filter to remove DC offset?

-- do  I need to subtract the mean value of the signal from the time based signal before sending to Order Processing?

How does one handle signals that have a varying static strain in addition to a cyclic signal overlaid on top of the static signal? This appears to me a common scenario in strain measurements because the DUT is undergoing both varying static and dynamic stresses during an engine ramp.

Thanks for any comments or tips!

[Bob_Schor]

If you are interested in a time-varying signal and you have a signal with a big DC component (by definition not time-varying), it makes sense to zero-mean your data first.

Bob Schor

[CoastalMaineBird · Accepted solution]

You have several choices, depending on what you want to do.

If what you want is a pretty plot, and if the DC signal is not varying enough to influence your 1st order, then simply set the DC component to 0 after you do the analysis.

Presto - instant DC removal.  That's perfectly legit, as long as the DC isn't wandering around too much.  Mathematically, it's exactly the same as removing DC before analyzing it.  (do an inverse FFT of that result and you will get the original signal without DC, if you don't believe me).

OR

You can do as Bob suggested and remove the mean.  if your block length is short compared to the rate of change of the real DC component, that's fine.

OR

You can remove the trend by interpolation.  For example, for a 1024-pt block, find the average of 100 points around (either side of) the start of your block.  Find the average of 100 points around (either side of) the end of your block.  Figure an equation (Y = mX +B) to describe the trend line there, and use that equation to subtract a different DC value for each point.

OR

You can remove the trend by extrapolation and interpolation.  For example, for a 1024 pt block,. find the average of the first 100 points, and the last 100 points, and assign those values to X=50 and X = 973 (1023 - 50).  Figure an equation (Y = mX +B) to describe the trend line there, and use that equation to subtract a different DC value for each point.  You have to deal with the fact that the X = 0 starts BEFORE your trend line at X=50, but that's basic algebra.

The trendline removal technique is most accurate, and necessary if the DC changes siugnificantly during your block.

[CoastalMaineBird]

If you want the utmost in accuracy, then do this ( once upon a time, I did this for professional troubleshooters all the time):

Affix an optical encoder to the engine crankshaft. (512-line was common).

Use the INDEX output to trigger a scan (external trigger).

Use the LINE output (512/revolution) to clock the scan (external clock)

Set up tasks to record 512 points, and record the data.

Record as many channels as you like (as long as your scan time is less than the RPS / 512).

Do FFT on the data and store the results.

Average as many FFT results as you like.

Ignore the DC output if you like,

They're guaranteed to be synchronous,  No filters, no windowing, just good data.  

You're removing the DC output by ignoring the DC component of the FFT.  Even if it's drifting, you're removing it rev by rev.

Be careful of averaging too many results, though.  If your speed is changing, then you're averaging 750 RPM with 755 RPM, with 760 RPM, etc. That may not be what you want.

If you know where (on the shaft) the encoder INDEX is, then rotate the 512 pt data by N pts before analyzing it, to preserve phase information relative to TDC.

[RagMan]

Thank you Bob Shor and Steve Bird.

Very helpful suggestions. More importantly it helped confirm my assessment of the issue.

Steve, regarding your suggestion about using the encoder to both trigger and clock the DAQ, the previous system that I am replacing with cDAQ used to do exactly that. Since the acquired AI signals were already even angle based, there was no need to use the OAT VIs. Straight FFT worked well. But I could not figure out exactly how the previous programmer was discarding the DC result from the FFT.

Since I am using the cDAQ 9235 module (it is a delta sigma ADC), I am not sure it will let me use an external signal from the encoder to be the Scan Clock. Need to do a bit more research but vaguely remember trying it before without success.

Thanks again.

[CoastalMaineBird]

But I could not figure out exactly how the previous programmer was discarding the DC result from the FFT.

S/he has to be either replacing element 0 of the FFT output with 0, or starting the plot from element 1 (ignoring element 0).

Since I am using the cDAQ 9235 module (it is a delta sigma ADC), I am not sure it will let me use an external signal from the encoder to be the Scan Clock.

Well, I think the synchronous DAQ is the most accurate you can get, not to mention the easiest (software-wise).  You either have to bend the hardware requirements to fit the task oyu want to do, or bend the task to fit the hardware you have.

[CoastalMaineBird]

Other fun facts:

--- The Encoder solution has absolutely no connection to speed.  It is all connected to crank angle.

For what we were doing that was perfect. We were looking at cylinder pressure and valve position vs. crank angle.  But you have to measure speed some other way (use the encoder's INDEX output into a COUNTER channel, for example).

--- Measuring speed on a (combustion) engine is an illusion anyway.  You can come up with an average speed, but the crankshaft literally slows down (that gas does not want to be compressed) and speeds up (exploding gas REALLY wants to get out).  If you analyze the 512/rev signal vs. time, you can see the cylinders firing.  A flywheel mitigates this, but everything is an average.

--- You're better off (speed wise) if the number of points you choose is a power of 2. You can use a FAST fourier if so.

--- The basic assumption behind Fourier analysis is that the signal you are analysing is synchronous to the block (the chunk you are analyzing), and repetitive: the next sample after the tail (element N-1) would be the head (element 0).

--- Order analysis involving windows (Hanning, Hamming, etc.) is simply an attempt to correct for the fact that you're measuring it wrong.  If you take an arbitrary time-chunk of data, then your head may not match up to your tail. As far as Fourier is concerned, that is a sudden transition in the signal and will show up as energy spread through the 1st order, 2nd order, etc.  It's polluting the data.  Worse, it's not consistent: if the head and tail meet at 750 RPM, you have little pollution.  If the head and tail are 180 out at 760 RPM, you have a large pollution.  Hanning, etc. basically reduce that transition by bending the signal toward zero at the head and the tail.  You then multiply the results by a fudge factor, because the window distorts the data.

--- If you record an arbitrary time-chunk of data, you don't have any phase information.  You don't know if this particular order's artifact is related to the valve opening at 270 degrees, or the suction valve closing, or what.  It's just not there.  You can get a phase result, but it's a phase relative to the start of your block, and if that's arbitrary, then phase is useless.

--- All those issues are avoided if you take the data synchronously.  Don't window it. Don't filter it, unless you have a known interfering signal way above the highest order you want.

I mentioned above that you can record as many channels as you like as long as the total scan time is < RPS / 512.

Obviously, that should be < 1 / RPS / 512 : the TIME it takes to turn the encoder one 512th of a rev.  You shouldn't get too close to that limit, because the speed varies during a revolution.

[RagMan]

One thing I forgot to mention was that it is not possible to put an external encoder on the engine (due to some limitations with the engine room setup i think). However there is a 58 tooth gear attached to the crank shaft (teeth are spaced  degrees apart with 2 teeth missing to indicate zero position). The previous system which used M-series hardware used synchronous sampling, but the 512 pulse/rev clock signal was artificially generated by an external frequency multiplier device (Motrona FM260 Frequency Multiplier,  http://www.motrona.eu/PDF/Fm260_e.pdf). This FM device was triggered off the zero pulse of the engine crank position sensor.

Regarding your earlier suggestions about removing the DC offset by interpolation/extrapolation, I found a VI that may do the work. 

It is called WA Online Detrend. When I run the example VI, it seems to do what I am looking for.

Example VI for WA Online Detrend.vi:

[CoastalMaineBird]

used synchronous sampling, but the 512 pulse/rev clock signal was artificially generated by an external frequency multiplier device

Well, that's not synchronous sampling, then.  I had to invent such a device myself, some 25 years ago. 

Assuming that it's like mine, it generates a TIME BASED interval at 512 x the index rate.

That's fine for a steady speed motor, but there's no such thing as a steady speed engine.  The cylinders accelerate it when they fire and decelerate it when they compress.

And if your engine speed is ramping up, the last point of the 512 that it generates is in danger of being overrun by the index pulse.

In any case, it sounds like the DETREND thing might be just what you need.