LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Peak find trouble (doesn't scale?)

Run into a problem today...

I search for the main peak ... usually a relative search width of 5% to 25% works fine. (and a threshold of 20% max , not used here for demonstration)

Attached is an example data where I increased the samplerate (about 130k sample) and the peak detection failed (without error).

If width is set to 30000 (23%)  I expect to find the main peak (not very fast, the fitting of the square function has a payload 😉 )

but this only seems to work with decimated data. I don't expect to find exactly the same point, but why it fails?

peak find trouble 01.png

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 1 of 14
(3,772 Views)

Interesting case.  Its not clear why it fails with the full dataset.  Though with that many data points I wonder if the NI Peak Detect quadratic fit is simply finding too little change in the large dataset.

 

Here's another method of peak detection I've been meaning to share that is quite quick even for large data sets.  I tried it with your data and it works well (attached).  Its handy when NI Peak Detector fails to find the peak/valley you are really interested in.  Its usually a lot faster than the NI PeakDetector.vi in most cases and I'm sure there's also ways to speed the code up further.  Its an implementation of the method outlined here - http://billauer.co.il/peakdet.html  

 

At some point I'll post examples.


Craig

 

Message 2 of 14
(3,687 Views)

Craig, thank you for your solution, and the link.

while looking at the code I realized I have done something similar here in the forum... 2015 ...  Eli did it 2012 🙂

 

Would have marked it as solution, however the problem still remain: WHY the NI peak detection fails?

It's slow for higher width values and a lot of datapoints, so not the best to use in such cases, BUT the math and the algorythm explained (in the help, that's all I have, the code is hidden in a node) should work.

 

And another lik to information to peak detection: http://www.ni.com/product-documentation/3770/en/

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 3 of 14
(3,653 Views)

@Henrik_Volkers wrote:

 

Would have marked it as solution, however the problem still remain: WHY the NI peak detection fails?


here's something strange: multiply the y-Array by a scalar-factor of 100 (nothing else changed)

MOD.PNG

 

case 1 case 2
y: scale = 1 {0; ... ; 0,0005} y: scale = 100 {0; ...; 0,5}
y_1.PNG y_100.PNG

 

the peak detector is based on discrete calculus, so we are looking at finite differences

It looks like there is an accuracy limit that is exceeded in case 1... I agree, there should be an error or warning

 

 

 

Message 4 of 14
(3,631 Views)

@Henrik_Volkers wrote:

Run into a problem today...

I search for the main peak ... usually a relative search width of 5% to 25% works fine. (and a threshold of 20% max , not used here for demonstration)

Attached is an example data where I increased the samplerate (about 130k sample) and the peak detection failed (without error).

If width is set to 30000 (23%)  I expect to find the main peak (not very fast, the fitting of the square function has a payload 😉 )

but this only seems to work with decimated data. I don't expect to find exactly the same point, but why it fails?

 

 


y:scale = 100 also works for decimating factor = 20 width = 30.000

2019-09-19_170422_ys100_df20_w30k.PNG

 

for this example,

y: scale can be reduced to 7

somewhere between 0,0280999 and 0,0327832, the peak detector stops working

iterations.PNG

 

 

Message 5 of 14
(3,622 Views)

@Henrik_Volkers wrote:

If width is set to 30000 (23%)  I expect to find the main peak (not very fast, the fitting of the square function has a payload 😉 )


Unfortunately, we cannot see the code inside the dll, but if it does i^2 in I32, a size of 129936 will overflow and wrap around if squared, resulting in negative terms (I32: 129936² = -296505088 (wrong!) instead of DBL: 129936² = 16883364096 (correct!), so if they do the squaring on the I32 index before further calculations, you'll get garbage. I guess the width should not contain an excessive number of points if this limitation exists.

 

Just guessing, but might be worth investigating. I could be wrong, of course. Might be a more general conditioning problem, though.

Message 6 of 14
(3,615 Views)

Thank you for your investigations and ideas..  so we have to wait until someone from NI looks into the code.

Smells a little buggy now ... (maybe ad some checks )  Oh, the strange world of digital numerics ... 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 7 of 14
(3,534 Views)

@cstorey wrote:

http://billauer.co.il/peakdet.html  

 

@Henrik_Volkers wrote:

Craig, thank you for your solution, and the link.

while looking at the code I realized I have done something similar here in the forum... 2015 ...  Eli did it 2012 🙂


 

both approaches appear to be sophisticated variations of the

"peak_detector_ptbypt.vi" for getting minima-maxima pairs in a waveform.

 

ptbypt.PNG

we can look inside the ptbypt .vis

however, for the example under consideration,

the ptbypt performs worse... e.g. it appears to have an offset in regards to the extrema found, which is getting worse the bigger the search width gets

 

 

 

 

 

 

Message 8 of 14
(3,513 Views)

Would have marked it as solution, however the problem still remain: WHY the NI peak detection fails?

Yes, it would be nice to know why it fails.  At least an error message or warning would be good. Not sure there's an easy way to get to that unless NI takes notice and decides to open up old code and examine.  That might be a big project for small returns.  You might have to find a few more case where it failed before it was worth it for them.  At the very least it would be nice of them to provide guidance, and comment about how the Y scaling affects the algorithm and how that might be useful if people run into problems.  

 

So you might try normalizing your X and Y data, say to Y=100 and X=1000.  Record the scaling factors, (decimate) run the Peak Detector, then rescale the points for plotting on the original data.

 

No worries about solution, I was just trying to show a fix to your problem with some code I've meant to share for awhile.  It seems every few weeks there's a peak finding question where the "NI Peak Detector.vi" is a bit of overkill and a bit slow.   I wish I'd found your solution in the forums when I started looking for alternatives...might have saved me some trouble.

 

Craig

Message 9 of 14
(3,490 Views)

Filed a bug report.

Could be a hint to dig into old DLL code. 😄

In the past arrays with >130k points easely caused a memory overflow 😉

so maybe this ( and some more old) code wasn't tested for such cases.

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


Message 10 of 14
(3,431 Views)