Problem with LabVIEW function

[Limsg]

I have encountered some problem when using the peak detection function in LabVIEW.. 

Basically, I load a waveform to the VI to detect the peaks using the peak detection function. from the waveform, it is quite obvious that the first peak will occur at around 10570Hz..

When using subgroup size of 3, it detected 1st peak at 10567Hz (correct)

When using subgroup size of 4, it detected 1st peak at 10569Hz (correct)

When using subgroup size of 5, it detected 1st peak at 12737Hz (Wrong)

When using subgroup size of 6, it detected 1st peak at 10588Hz (correct)

When using subgroup size of 7, it detected 1st peak at 10588Hz (correct)

And using other various subgroup size, the freq agrees with the waveform.. Why is it that when using subgroup size of 5, it doesn't give the correct reading? Is there a theory or reason for it? or simply a bug with the LabVIEW function?

A VI is attached and the default values are loaded.

Appreciate any assistance/advise.

[johnsold]

Your signal is noisy.  That is why you see several peaks reported at many of the real peak locations and some "non-peaks" are also detected.  To see this turn off the Autoscale for the X axis and then set the X-axis limits to 10525 and 10650.  You can see three distinct peaks.  From the looks of the data your Width input (SubGroup Size) should be substantially larger.  With a values of 20-100 you only get 3- 4 peaks.  Read the detailed help for the peak detector.

Lynn

[Yamaeda]

A resonable theory is that with 5 as width you manage to hit the exact 10570 top as breaking point, thus not getting any peak on the reading before or after, but 2 slopes of the graph. As you might notice, using width of 4 you get the 12740 peak but as index 10.

From the help it says ~"Find a balance between as low width as possible without false peaks". It seems ~20 is that magic number in this instance. 🙂

/Y

[Limsg]

---

@johnsold wrote:

Your signal is noisy.  That is why you see several peaks reported at many of the real peak locations and some "non-peaks" are also detected.  To see this turn off the Autoscale for the X axis and then set the X-axis limits to 10525 and 10650.  You can see three distinct peaks.  From the looks of the data your Width input (SubGroup Size) should be substantially larger.  With a values of 20-100 you only get 3- 4 peaks.  Read the detailed help for the peak detector.

Lynn

---

If you read my question carefully, it's Not asking why are there "false" or numerous peaks.

The question is, Why is the first peak Not at region around 10570 Hz? All the other subgroup sizes correctly detect the first peak at around 10570Hz which agrees with the plot, along with all other undesirable peaks.

of coz there maybe workaround or methods to "improve" the situation..

But what I want to find out now is whether there is a bug in the function? Not asking for workaround..

At least, we need to find the root cause first, then apply appropriate measures "confidently".

I have encountered a bug before in LV7, the array sorting function just doesn't sort properly. And NI acknowledged a bug. And, as a programmer, naturally we want to know the root cause if not how can we tell whether when the result will be correct and when will the result maybe be wrong? The application will be totally unreliable if we cannot confidently determine the kind of outcome/output.

Sorry but your comment is not helpful in this case..

Please refer to the attached plot with emphasis on the region from 10kHz to 13kHz. There is no reason (or excuse) for the function to return a peak at 12737Hz when the peak is obviously between 10.5kHz and 11kHz. 

[Limsg]

---

@Yamaeda wrote:

A resonable theory is that with 5 as width you manage to hit the exact 10570 top as breaking point, thus not getting any peak on the reading before or after, but 2 slopes of the graph. As you might notice, using width of 4 you get the 12740 peak but as index 10.

From the help it says ~"Find a balance between as low width as possible without false peaks". It seems ~20 is that magic number in this instance. 🙂

/Y

---

Could you explain again what is meant by "hit the exact 10570 top as breaking point"?

Now, the issue is not "Find a balance between as low width as possible without false peaks" which applies more to detecting a false peak when it is not there. The issue now is the function is Not detecting a peak when it is there.. a BIG mountain totally missed.....

[Limsg]

---

@Limsg wrote:

Please refer to the attached plot with emphasis on the region from 10kHz to 13kHz. There is no reason (or excuse) for the function to return a FIRST peak at 12737Hz when the FIRST peak is obviously between 10.5kHz and 11kHz. 

---

A BIG mountain peak totally missed by the function when the subgroup is 5. Is this acceptable?

Detecting "unwanted" peak is acceptable ( small peaks are present ), But NOT DETECTING an obvious peak is not acceptable, IMO. Unless there is a mathematical/technical reason/explanation for it.

[johnsold]

I suspect that the particular setting of your peak width parameter which missed the big peak at 10.5 kHz was one in which no peak of that width occurred.  Look at each group of 5 consecutive data points near the peak.  Is there any set of those which meets the definition of a peak?  The Peak detector VI uses a Call Library Function Node, so we cannot see the algorithm.

I created an array of differences from the Magnitude of the Power Spectrum.  Near the 10.5 peak it looks like 6, 5, 5, 6, 2, 5, -0.5, -1, 1, 2, -1, -.9, 2, -6, -2, -7 ... x 10^-7. Four a width of 4 it detects peaks from [2, 5, -0.5, -1], [1, 2, -1, -.9], and another which I cannot clearly identify.  The only possible 5 width peak is [6, 2, 5, -0.5, -1].  Since the algorithm interpolates the peak position and the rising "edge" has a much greater slope than the falling "edge," it probably looks at the next point [+1] and decides that this is not a real peak.  The minimum width which appears to guarantee no false peaks is 9 or possibly 11, depending on how the algorithm works.

Lynn

[Limsg]

---

@johnsold wrote:

I suspect that the particular setting of your peak width parameter which missed the big peak at 10.5 kHz was one in which no peak of that width occurred.  Look at each group of 5 consecutive data points near the peak.  Is there any set of those which meets the definition of a peak?  The Peak detector VI uses a Call Library Function Node, so we cannot see the algorithm.

---

According to http://zone.ni.com/devzone/cda/tut/p/id/3770

" The function performs a quadratic curve fitting to find the peaks and valleys. The core of the peak-finding algorithm consists of fitting a parabola to successive groups of points, equal in number towidth. The function uses the coefficients from the fit to determine whether a peak or valley is present."

Considering the attached waveform, for the 5 point 10575 to 10595, surely, a best fit quadratic curve should produce a maxima at around 10585Hz right.. there is no reason for it to miss a "peak". In fact, there would be a few peaks around that region, before and after. All missed.

Btw, I find the following 2 statements contradicting

A) "For each set of points, the algorithm performs the least-squares quadratic fit, and then performs a series of tests on the coefficients to see whether they meet the criteria for a peak."

B) "Figure 8c shows the signal, smoothed by using the same method as the peak detection algorithm, and then passed to the peak detection function."

(A) suggests that the function does a quadratic fit for the data points, meaning the data points are not modified in any way.

(B) suggests that the data points are modified via a smoothing method

Which one is actually correct?

[Yamaeda]

I dont find A and B contradicting, A refers to the data calculated upon, B refers to the data drawn on the graph.

/Y

[Limsg]

---

@Yamaeda wrote:

I dont find A and B contradicting, A refers to the data calculated upon, B refers to the data drawn on the graph.

/Y

---

A simple question. are the original data modified in any way inside the peak detection function?