Order Analysis when there is a significant DC offset in signal

Question

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!
 

Answer 1

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.