Does anyone know if data collected with a Velocity Transducer then integrated to Acceleration in a waveform is reliable? we collect data during our regular routes using a velocity sensor. However we would like to know how reliable the data is using RBM ware and converting it to waveform in Acceleration.

Original Post
Actually to get from velocity to acceleration would require not "integration" but "differentiation", in effect looking at the slope of the signal.
So any sharp changes, spiky behaviour etc causing steep local slopes would drive the computed acceleration signal all over the map.
You'd need a very valid signal, and a very precise analysis to prevent getting some garbage out.
Of course a pure sinusoid would be trivially easy.
disclaimer:I know zip about what commercial instruments / analyzers / software can do.
I don't think RBMware can change a waveform, but the spectrum can be changed for Accel, vel, or disp.. Ron is correct in that one would have to differentiate a velocity signal to get acceleration, and this can only be done with spectrum and not waveform with CSI software.


Once while supporting the Nuke power, I designed a system to differentiate a prox. probe to get velocity. Actually, the purpose was to get kinetic energy to calibrate/qualify a loose parts monitoring system.

It can be done. Usually, it is in the frequency domain, which simply means that the spectrum is scaled, i.e. multiplied by frequency and a calibration factor to get the units correct (g's, m/sec^2, in/sec^2, etc.).
One way to look at this....

Integrating acceleration to velocity is like passing the signal through a low pass filter, with 6 dB/octave roll-off. The higher the frequency, the less of the signal gets through.

To go the other direction accurately, that is differentiating velocity to acceleration, requires "putting back" that part of the signal that was filtered out. But there's no way to put back the high frequency information that isn't there.

The differentiated signal will lack high frequency components. Signals from impacting and from high frequency sources such as rolling element bearing deterioration and gear mesh will not be present, so the time domain signal will be distorted from the true signal.

In short, integration from acceleration to velocity to displacement is ok. Differentiation from displacement to velocity or velocity to acceleration is not so good.

Peaks from a spectrum can be accurately converted between acceleration/velocity/displacement in any direction. VibCon, a free vibration conversion calculator by yours truly, is available on CTC's web site at
Another application where signal derivatives are used is in a PID controller, the D part.

In fluid film bearings there is a natural derivative action (no signal manipulation required); this produces damping. In magnetic bearings this is done with the control system. There are a number of such bearings with PID controllers. Usually the position is sensed with something like a proximity probe, not usually Bently. Axial magnetic bearings almost always use PID control.

High frequency can involve the problem of unmodled dynamics. If one does not take care of this it is easy to have a high frequency mode go unstable.

There are legitimate uses for differentiation. It is true that many PID controllers relate to low frequency dynamics, and thus would have no issue with high frequency (add low pass here).
I have taken the output data and then manipulated it after the fact and displayed frequency, acel, vel & mils in a chart when the plot prints out. This doesn't touch or affect the integrity of the data although it's a part of the software.

If you go front-end and re-process using 'nothing out of left field' you still may have some issues.

Wheather a strength of field or eddy for position is used it is a known for relative position. I'm not as well versed as Bill here - this takes care of low frequency but I'm unsure how you would derive higher frequency components and have their magnitudes correspond to something realistic from the controllers data? Anyway, it's interesting where I understand it or not. Maybe something to look into.
If life were trouble free, well it wouldn't be life or so much fun.

There are some potential/real issues with the high frequency. 1) You don't want to put out a control signal based on noise. Then you would be introducing noise in the system. 2) If the high frequency modes are not accurate, they can go unstable or be greatly excited by noise.

Integration and the low frequency can cause issues too. Did you ever have your car speed control wind up or bog down going up or down hills? This could be an integrater at work increasing the error signal (speed variance to desired).
Ksmith, why not just save an acceleration waveform as your 'default' waveform? In general, I find the acceleration waveform to be much more useful than the velocity waveform when doing 'route work.' I display the velocity spectrum as I collect data (and save it that way) which shows any lower frequency mechanical problems. If I sense there is so high-frequency noise present, I'll look at the acceleration waveform just collected. If I see too much 'energy' there (that's how I think of acceleration) in the waveform, then I'll collect additional spectrum/waveform pairs, usually in velocity and acceleration with enough resolution to resolve what I'm seeing.
I believe in CSI's signal processing, if the raw TWF data is collected in acceleration units, it could be then converted into velocity units by reconstructing the TWF from the velocity spectrum since amplitude and phase data is available to FFT for each frequency within Fmax.
Rusty and David,

In this case, the data is coming from a velocity transducer. No acceleration data to work with.

Any velocity level can be converted to acceleration (in the spectra) but converting TWF data is risky at best, because high frequency components have been filtered out.

Spintelligent Labs
Originally posted by Jon Chandler:
... converting TWF data is risky at best, because high frequency components have been filtered out.

If TWF data is taken in velocity units with certain Fmax, all frequencies up to Fmax regardless of units will be present in the TWF assuming they are in the linear response range of the velocity sensor.

So, if a velocity spectrum is calculated based on that data, then converted into acceleration spectrum, and then an acceleration TWF is reconstructed from the spectrum (considering phase of each frequency) why would the acceleration TWF be inaccurate in terms of having high frequencies filtered out?

To me it will still contain all frequencies up to Fmax.

At RBMWare, Analysis Parameters, You can select Special Time Waveform at Waveform Parameters page DB26. There you can select the Data Units. So the instrument can apply hardware integaration or differention, with respect to sensor type and the data units which you select. This will be the best quality data.

As mentioned, also you can change the Waveform data units at the WAVEFORMS.

Auto correlation and Togle waveforms will help you more for Waveform analysis. For this the RPM has to be corrected.
There is no argument that velocity is better suited to identifying low frequency magnitudes, but I would bet the sensor you are using is an accelerometer that is internally integrated to velocity. Also, the number one concern you're usually trying to identify in slow speed rolls is anti-friction bearings. In that case, acceleration, spike energy, peak vue, take your pick, and they are by far the chosen measurement over velocity.

Add Reply

Likes (0)