Developing an Algorithm for Tick Detection

An investigation was made of a sample of automotive components where some were exhibiting a high frequency “tick” or rattle during each operating cycle. This feature could be heard above the normal operating noise. The problem this posed was to measure and analyze components in an objective fashion and classify components as “good” or “bad”.

A microphone was mounted on the test jig to verify that the sound could be recorded sufficiently well to discriminate the two conditions. That is, could the “tick” on bad components be heard on the recorded signal. After capture, the two signals were replayed through headphones and it was established that the “tick” was still prominent in the recorded signal. The time histories from the microphone are shown in Figure 1 below (click any of the figures for a larger view). Both look very similar and it is clear that there are no particular features that would aid in classifying the problem.

Figure 1: Microphone signals of component with and without tick

Click the play button or link below to listen to the sample signals1. The first is a component that doesn’t have a “tick” and the second one does.

Listen to microphone signal of component without tick

Listen to microphone signal of component with tick

What was required was a method of detecting the “tick” algorithmically. By this time, both signals had been loaded into a DATS worksheet. It was plain from the listening to the component and the recording that the tick was of a relatively high frequency. So, the first obvious step was to calculate the frequency spectrum for each signal and overlay them to see how they differed. As we needed to compare the relative amplitudes of the two signals we first normalized with respect to the standard deviation (SD) of the signals to remove any variability due to measurement conditions.

Figure 2: Overlay of frequency spectra from both samples

Once this was done and the spectra had been computed (see Figure 2)  it is obvious that there is more energy in the signal with the “tick”, but it is spread out over quite a wide frequency range making it unsuitable to detect in a narrow band. An easier way of detecting the condition may be to look at the overall RMS in a frequency band between 5 and 15kHz. To do this a band pass filter is applied to each time history signal. It is quite useful to listen to the two signals again, now that the filter has been applied, to ensure that the feature we are trying to detect is still present.

Listen to filtered microphone signal of component without tick

Listen to filtered microphone signal of component with tick

Figure 3: Spectra of band pass filtered signals (dB scale)

Looking at the spectra of the signals now (Figure 3) it is still difficult to see any major differences on a log scale but if we change to a linear scale (Figure 4) then the difference in amplitude of the frequency components in this frequency band can be seen quite clearly.

Figure 4: Spectra of band pass filtered signals (linear scale)

The difference in the signals is spread over a relatively wide band, but the total energy is obviously greater in the signal with the “tick”. So using the RMS value of the filtered signal may be sufficient. If we calculate the RMS for the “good” and “bad” signals we get values of 0.0082 and 0.0230. This is nearly a factor of 3 and would appear to be a good enough discriminator if we can show that it holds true over a number of samples.

Another way of looking at the energy in these signals is to calculate the trend of the RMS from the original time history.

Looking at this raises some interesting issues. It shows us that our supposedly clean reference signal does occasionally exhibit the same phenomena. It is too infrequent to influence the overall RMS as this is heavily weighted by the good cycles. However if it was necessary to detect any occurrence of the tick then checking the threshold of the RMS Trend would provide finer discrimination than just the RMS value in the band.

Performing the Analysis

The analysis for this test was performed using Prosig’s DATS package. The software lends itself to both the intensive interactive work required to investigate and understand the data and is then ideal to refine a final application that can be used to test components in a production environment. The initial worksheet created in DATS to help classify the data can be seen in Figure 5 (click to see a larger view). This is a typical “engineers” worksheet and is analyzing the data in many different ways in order to understand the problem.

Figure 5: The initial analysis worksheet

Once the results of this analysis were examined it became clear how the data should be analyzed as detailed above. The worksheet could then be stripped down to the analysis chain required to classify our components.

Figure 6: A “leaner” worksheet

The worksheet in Figure 6 takes the “good” and “bad” signals, analyzes them and presents the results of the RMS calculation in a message box. This was then refined further.

Figure 7: Worksheet to classify an individual component

Obviously, when one wishes to test a single component it is only necessary to analyze one signal at a time. Figure 7 shows the worksheet to take one signal from a captured data file and analyze it to produce a single RMS value that can be used to decide if a component is “good” or “bad”.

Figure 8: Final worksheet

In the final iteration of the worksheet, shown in Figure 8, the initial disk file input has been exchanged for a data acquisition component so that the microphone capture becomes part of the classification process. In addition, after several components had been tested it was possible to set an acceptance limit for the measured RMS value. This was then encapsulated in the analysis as a decision box in the worksheet that gave a pass or fail message.

The flexibility of the DATS worksheets opens up many possibilities for future development of the application. For instance, the whole process could be run in a loop allowing for a continuous testing process. The DATS data acquisition software has a range of sophisticated triggers and, therefore, the data capture stage could be automatically triggered. If this were coupled with the report generation capabilities and the export options to formats like Microsoft Excel then the testing process could be made fully hands-off.

1 The audio clips above have been converted to compressed MP3 files for convenience when adding to this blog post. For the analysis described above they were reviewed at full, uncompressed quality.

The following two tabs change content below.

Chris Mason

General Manager at Prosig
Chris' passion for software, technology and innovation began in his teens with a diet of Sinclair ZX80's, Commodore Pets and early Apple products. Chris graduated from Portsmouth Polytechnic in 1983 and went on to have a career in software product development, software team management, web development, marketing and, now, general management. His other passions include bicycles, IoT, coffee, running, walking, cooking and supercharged Jags.

3 thoughts on “Developing an Algorithm for Tick Detection

  1. vinay

    I rarely see people categorizing the problem and comparing each step for easy understanding of the viewer. I appreciate the effort and hope that others (Analysis Software makers) emulate this. Cheers. Hare Krishna.

  2. marco clark

    I see you comparing the data in log and finally linearly but I don’t see some of the steps you have in the flowchart such as filtering. As a newby I would like to know how you get the RMS value. Maybe you can collect some from all your samples and put it in an FAQ but for now just how did you get the RMS (I’m assuming it’s trivial but I’d still like to know)

  3. Chris Mason Post author

    Hi Marco, thanks for your question. The RMS value used in the example is calculated by the STAT operation. This calculates a whole bunch of statistical values for the signal and stores them all in Named Elements with the original data.

    The following are an example of the statistical information that can be calculated…

    #$REAL_AVERAGE_FREQ    Average Frequency
    #$REAL_CRESTFACTOR     Crest Factor
    #$REAL_KURT            Kurtosis
    #$REAL_M5              5th Central Moment
    #$REAL_M6              6th Central Moment
    #$REAL_MAX             Maximum
    #$REAL_MAX_LOCN        Location of Maximum
    #$REAL_MEAN            Mean
    #$REAL_MEDIAN          Median
    #$REAL_MIN             Minimum
    #$REAL_MIN_LOCN        Location of Minimum
    #$REAL_QUARTILELOW     Lower Quartile
    #$REAL_QUARTILEUPP     Upper Quartile
    #$REAL_RMS             RMS
    #$REAL_SKEW            Skew
    #$REAL_STD_DEV         Standard Deviation

    The #$REAL_ part of the Named Element name reflects the fact that I was looking at a real signal. If I had been using complex data then further values would be calculated for imaginary or phase parts.

    So, in our example, the STAT function is performed and then the decision box checks the value of the Named Element #$REAL_RMS and proceeds accordingly.

Leave a Reply

  1. We welcome any feedback, questions or comments
Optimization WordPress Plugins & Solutions by W3 EDGE