(800) 778-8755


(back to FAQs)

How is the data handled?

The Rotating Machinery application has 2 modes of operation: "Averaged Spectra" and "Map Spectral". The first mode behaves the same as a standard analyzer application. Data is acquired and averaged into a set of processed data functions such as auto power spectra, power spectral densities, or frequency response functions. The result of a "run" for the Averaged Spectra mode is a single data set of the averaged functions. The second mode (Map) is more elaborate in function. The result of a run for this case is a SET of processed data functions. The processed data functions may be optionally averaged as well but in general they represent a single average count result. The sets of processed functions are stored in a serially accessed data base using data record markers called "gates". These gates allow the user to access and correlate the data.


(back to FAQs)

What is a gate?

A gate is typically a value related to time, rpm, frequency, etc. It may also be an extracted channel based value such as channel rms. For example, one gate value implicitly available is called "time" which is the test time in seconds when the data set was acquired. Another implicit gate is record number which is the sequentially numbered index of the acquired data set. In addition to these gates, the user may establish extra gates (up to 5) which are be based on data channel measurements such as Rms or rpm. Once the gate has been enabled, then the user must select the type and source of the gate processing. The user must first select which gates ( via the 'Select Gate Types' dialog ) are to be active. Next, one must also setup the gate parameters ( via the 'Setup Gates' dialog ) which will indicate how the gate value is to be determined or extracted. Optionally, the gate value(s) may be used to control the actual data acquisition process ( via the ' Acquisition Gating' dialog ). The "mapped" or waterfall mode of operation for the RMA application acquires and stores multiple data sets in a serial accessed file. Each data set contains the channel time histories and all gate values calculated. A status panel exists to allow the user to monitor the individual values of the gates during online or test acquisition operations.


(back to FAQs)

How are gates utilized?

Acquisition of the time domain data can be optionally controlled by using a set of additional processed information values called "Gates". The gate values are used to control all aspects of the test data acquisition. The user can use gate values to control the Test Start, Test Stop and data acquisition step (increment). Post test analysis is further accomplished by allowing the user to reference gate values against data acquisition sets for purposes of waterfall type displays or order track extraction plots.


(back to FAQs)

How does Tacho processing work?

Tacho processing, as performed by the Rotating machinery application, uses the traditional method for determining the frequency of an input signal. This processing method relies on monitoring the number of fixed time increments observed between a start and stop of a single cycle of the tacho waveform. This assumes that the tacho waveform is of a single sinusoid nature and that a start/stop event pair can be determined similar to the way triggering is performed on impact waveforms. Once the trigger events (start/stop) have been defined, the number of fixed time increments are counted between the start/stop events of a single tacho cycle. Knowing the frequency (i.e. delta T) of the fixed time increments we can convert the "counts" to a frequency by the simple equation:

Tacho_period = Counts/Tacho_Clock

Tacho_freq = 1.0 /Tacho_period

Ref_freq = Tacho_freq / Pulses_per_Rev

There are usually 2 ways that the tacho can be measured.

1) The simplest is to use a data channel as a tacho channel ("pulse" option). In this case, the Tacho_Clock is actually the sample rate of the data channels. This sample rate usually limits the tacho frequency range since the tacho range is now set by the input data frequency range requirement. In addition, due to the "frame" nature of the input sampling process (i.e. we have to acquire a certain number of data points (1024,2048,4096,...etc.) we are limited to how we acquire the tacho signal. This restriction usually means we get several tacho cycles in every data frame. The result is often an "averaged" value which is acceptable unless the tacho signal is changing frequency during the data frame event.

2) Another way tacho can be measured is to use a tacho hardware daughter card ("H/W" option) that contains its own Tacho_Clock which runs at a much higher speed; typically 100Mhz. This tacho hardware also contains special double buffered counters (i.e. to read "Counts") which maintain a continuous counter reading (from tacho cycle to tacho cycle) to avoid skipping any triggered cycles of the tacho signal. There is also an option to allow these counters to "average" several tacho periods for cases when the input tacho frequency is very high (see accuracy discussion). The advantage here is that we decouple the Tacho_Clock from the input data rate. In addition, we double-buffer the counters to avoid missing or combining tacho input cycles. This means we can have an extremely high update rate to the tacho frequency as it is based only on the input tacho frequency. This is important when dealing with any tacho source that has a varying input frequency (a.k.a. "skew").

Tacho measurement accuracy, in either of the two measurement methods, basically relies on how accurately we measure the "Counts" value. For a fixed frequency input, the counts are expected to vary depending on the frequency/accuracy of the trigger points and how close the Tacho_Clock frequency is to the input tacho frequency. Our internal specification for counting accuracy is 1 count in a 1000. This means that the "Count" value should be at least 1000 in order to ensure a reasonable accurate result.


For example, the H/W tacho has a clock of:

100 x 10^6 hz (100 Mhz)

For Count equal to 1000 we have a tacho frequency of:

1.0 / (1000 / 100 x 10^6) = 100,000 hz

While the tacho H/W can measure still higher input frequencies, the accuracy will begin to degrade.


For the case of using the data sample clock, take a typical example of 2000 BW (10240 hz sample rate). In this case:

1.0 / (1000 / 10240) = 10 hz

Obviously, we must relax the accuracy specification for the fixed sample case in order to get a reasonable range. However, assuming that we only measure 5 points per cycle (the best due to the filter cutoff), we find that the absolute max tacho freq will be:

1.0 / ( 5 / 10240 ) = 2000 hz

This measurement of the tacho is sure to have a lot of "bounce"/variability due to the poor counts available to determine the true tacho frequency. This measurement is somewhat improved by using averaging (due to there probably being several tacho cycles in the input buffer). Note that at the max freq there will be over 200 cycles in a 1024 point waveform. The bottom line is that the "pulses" option (i.e. using a data channel) is only usable in a few cases when the tacho frequencies are on the order of the data frequencies. This can be okay when using very low pulses per tacho revolution. Since the tacho frequency being measured must include the pulses/rev effect, the maximum frequency input must still be below the filter cutoff. For our example above, if we had a pulses/rev of 100 (not unusual for flywheel or geared data), then the usable MAX tacho (reference frequency value) would be:2000 / 100 = 20 hz

This is the maximum fundamental frequency. Your only choice in these applications is to try increasing the measurement BW which then increases the sample rate. Unfortunately this also decreases the frequency resolution of the data analysis ( delta_F = SampleRate / FrameSize ). In any event, such a (pulses) tacho source is not a recommended reference source for performing any tracking sampling measurements due to its lower accuracy and inability to track a slewed data set. OFFLINE processing of "pulses" option data may be the only way to perform tracked data sampling since the tacho waveform is completely digitized and tacho frequency estimators can be employed to better estimate the reference frequency values.


(back to FAQs)

What are the digitizing options (i.e. sampling types) available in RMA?

There are 2 types of digitizing methods utilized by the RMA package: fixed and tracking.  The choice of which method to utilize depends on the input characteristics and available hardware options.

Fixed sampling refers to the classical method of digitizing analog data streams by using a low pass filter at a specific bandwidth followed by a fixed sample rate converter. The user typically specifies the desired bandwidth and the software selects the proper low pass filter and sample rate to match. This method forces all of the data to be sampled at the basic digitizing rate irrespective of the operating conditions (e.g. machine rpm). The results of this processing is a digitized time history using a constant delta T (time) increment. This procedure is most often utilized for cases where the test object's primary motion/operation is stationary or slowly varying (relative to the amount of time per data frame). When the rpm change (rpm slew) becomes more significant during the acquired data frame, then the spectral results (including order tracks, etc.) become more "smeared". Increasing the number of spectral lines, to decrease the spectral resolution (i.e. a "finer" or smaller delta frequency) often only increases the problem as the increased resolution also increases the data frame time. The data frame time can be calculated via several methods:

Data_Frame_Time => 1.0 / Delta_Freq => Num_Lines / Bandwidth => Frame_size / Sample_Rate

Synchronous or tracking sampling requires that the sample rate (and hence the low pass filter cutoffs) be continuously adjusted with respect to input rpm changes. As the input rpm changes, so does the sample rate and low pass filter cutoff change to maintain a synchronous relationship between the data samples and fundamental rpm values. In this case, the sampling time increment is continuously modified from data point to data point. Instead of using a delta time increment, the data domain is often referred to the angle or order domain. In this domain, true order related events are completely synchronous to the reference rpm and do not display the typical smearing observed by fixed sample rate processing. The ability to accurately observe order related events often requires that the sample rate be constantly adjustable to maintain the proper digitizing perspective. For tracking sampling, since the delta time increment is constantly changing, the data frame time is also constantly changing. The user typically specifies the desired maximum order and the software selects the proper tracking ratios to be utilized during the sample rate/filter tracking process. Tracking sampling is also useful for fixed speed cases where accuracy of order extraction is important since there is no "smearing" of the order data due to slight fundamental speed variations or drift. Of particular importance is the fact that both the sample rate and associated low pass filter cutoffs are continuously modified thus maintaining alias-free data at all times. Tracking sampling can only be utilized when the SD tacho hardware is available. The quality of the tracking sampling is tied to the quality of the input tacho signal and the maximum order required.

(See next FAQ about tracking sampling performance)


(back to FAQs)

How can the tracking sampling performance be optimized / What parameters affect the tracking accuracy?

Tracking sampling performance is directly related to the quality and type of reference signal (tachometer) utilized. The sample rate/filter bandwidth settings are constantly being updated based on the tachometer measurement. Since the tacho measurements are based on a single "cycle" of the input tacho waveform, than the instantaneous tacho value can only be updated based on each tacho waveform period. The tacho hardware also utilizes a double buffered counter system (see Tacho Processing FAQ) so each tacho period can be accessed for sample rate updates. For acquisition cases of very high "slew" rates, where the rate of change of the tacho signal is high relative to the fundamental order, then multiple pulses per revolution signals provide the best results. Multiple pulses provide additional sample rate updates during each fundamental revolution thereby giving a better estimate to the true angular position requirement. Since the RMA software automatically compensates for pulses per revolution on a floating point basis, the pulses per rev parameter need not be an integer. For example, this feature is often important when deciding to track intermediate shafts in manual transmissions where the gear tooth counts are non integral.

 (back to FAQs)   

How is an order track calculated?

The order track and frequency track extraction functions provide the same basic capabilities. In the case of order tracks, the tracked "frequency" is actually a frequency value that is proportional to the fundamental tracked gate (i.e. engine RPM, etc.). In the case of the frequency tracking, the tracked value is fixed independent of any of the fundamental gate parameters.

For purposes of description, the order tracked option is described in the following explanations.

The order plot function extracts the specified order value from the data records. The order value is that value which can be found (for example) in the spectral data by extracting the frequency information corresponding to the equation:

Freq = Order# x Fundamental

Where the "Fundamental" is the reference gate used to specify the basic fundamental order property (such as the system RPM, etc.). Note that there are implied conversions between frequency (1/sec) and rpm (1/min) which are automatically performed. The Order# is a floating point entry provided by the user.

There are several ways to extract the order data from the associated record's spectrum. The options are: Line, Peak and Filter FFT. All of these options operate using the Fourier domain (FFT) data. Due to the nature of using a finite FFT, certain restrictions may be placed on order resolution and consequential results.

Line: The line extraction method calculates the nearest spectral line corresponding to the order frequency for the data record. The value is extracted as an rms based result. Errors and other data biases can be attributed to smearing and effects of order frequency truncation due to the finite resolution of the FFT process. The use of this option should generally be accompanied by use of a spectral window (unless the data is synchronously sampled) to try to minimize the leakage effects.

Peak: The peak extraction method is similar to the line method with the exception that a range of spectral lines are examined and the maximum value within the range is extracted. This method is slightly less tolerant to leakage effects but a spectral window is still recommended. The range utilized for the maximal scan is established by the dialog "Filter" selection type. The filter employed is a proportional bandwidth filter. The filter settings use the "Width(%)" dialog entry to establish the scanning width by taking the entered % and determining the half width of the bandpass frequency by the equation:

Half_Width (Hz) = Order_Freq * Width(%)/200

The Half_Width value is converted to a spectral line count. This line count is used to scan above and below the approximate Order frequency position.

Filter FFT: This extraction method utilizes an integration process. All spectral data within a range of spectral lines is (power) summed. The derivation for the range of spectral lines utilized is exactly as described for the Peak extraction method. The Filter FFT method is slightly less tolerant to leakage effects and is useful when a spectral window is not utilized on the data.

In both the Peak and Filter FFT methods, the results are based on a proportionally defined tracking filter. This means that the filter bandwidth varies proportionally to the tracked center frequency of the filter. In both cases, the width/accuracy of the filter is predicated on the basic FFT resolution established under the acquisition parameters dialog.

(back to FAQs)