LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Peak Detector shows peaks under threshold

Solved!
Go to solution

Hey everybody,

 

I'm currently working on a VI to analyze measurement data.

 

For this I calculated the first derivative of my signal and used peak detection to find the peaks and valleys.

My signal is periodic and therefore after a peak should always follow a valley and so on. The peaks are irregular and sometimes what I would like to be registered as one peak is registered as two or more peaks, depending on the current measurement data (picture, red circle). 

 

My idea was to use a case structure, such that after registering a peak it switches cases until registering a valley and keep changing between peak and valley detection.

 

In general this seems to work, but I have a problem with the peak detection. I wired a threshold of 50 to the peak function, but it seems to register peaks way smaller than that after a valley (picture, green circle)? 

 

How could I fix this or is there another approach I could use?

 

I'm using real measurement data so I can't really link my VI, but generally I'm using separate peak/valley detection as shown below.

 

Thanks!

Download All
0 Kudos
Message 1 of 4
(279 Views)
Solution
Accepted by topic author lente99

It seems a 'peak' is defined as valley to top, not 0 to top...

 

I guess you could make 0 the minimum of the data (using min & max function).

 

Alternatively (maybe a bit cleaner; manipulating data when analyzing data is walking on thin ice AFAIC), you can post process (filter) the returned peaks. This is simply a for loop, and if the Y value at the max location is <50, don't add the result to the output. A auto index in and conditional auto index out makes this really simple. See this (embedded 👍) image:

wiebeCARYA_0-1720439235806.png

 

0 Kudos
Message 2 of 4
(266 Views)

Thanks for your reply, I will make sure to also use embedded pictures in the future 🙂 

 

Yes, I guess peak is valley to top.

 

You simply check against the amplitude that the function gives right?

 

I tried doing it like this and apparently the small peak which I circled green in the picture has an amplitude of 56 according to the function but for every other peak the amplitude looks correct.

 

It's not really a problem because I just go an extra step and read the amplitude at the corresponding index from the signal and then compare it, just seems a bit weird.

 

Solution should work like this though, thank you!

 

 

 

 

Message 3 of 4
(239 Views)

@lente99 wrote:

You simply check against the amplitude that the function gives right?


I'm not sure actually. But getting the amplitude from the original data (if the peak happens to be valley to top) isn't that much harder (indeed, an index array).

 


@lente99 wrote:

I tried doing it like this and apparently the small peak which I circled green in the picture has an amplitude of 56 according to the function but for every other peak the amplitude looks correct.


We'd need to look at your data.

 

If you'd like us to, you can put the data in any control\indicator, and make those values default. If you then save it and upload it, we should have the same data.

 

Or export the data to clipboard or file and save it... That's a bit more work on our part.

 

The function's documentation has a few things to say about all this:

Locations contains the index locations of all peaks or valleys detected in the current block of data. Because the peak detection algorithm uses a quadratic fit to find the peaks, it actually interpolates between the data points. Therefore, the indexes are not integers. In other words, the peaks found are not necessarily actual points in the input data but may be at fractions of an index and at amplitudes not found in the input array.

 

And:

Amplitudes contains the amplitudes of peaks or valleys found in the current block of data.
 

 

Note  The Locations and Amplitudes might deviate from actual peaks or valleys for noisy signals with large dynamic ranges.
0 Kudos
Message 4 of 4
(225 Views)