04-27-2009 03:35 AM
As shown in the attached shot, there are more than one minimized value in the collected data.
But only the 3rd one is the really one I needed. The difference of the 3 red cycles is:
The curve at the 3rd red cycle is not Smooth in math, that is its 1st order Derivative at the 3rd cyccle is not a Continuous function.
Is there any way to detect it?
Thanks.
04-28-2009 01:15 AM
Hi Turbot,
Your pic shows a waveform that starts at about zero and ends at about zero. The attached VI examines the input array from each end to find the first slope-transition-points. Once the data initially stops rising we start looking for a minimum - up to where the final decline begins.
... maybe ;^)
Hey, it's what I'd do - hope it helps!
Cheers!
04-28-2009 10:04 AM
That VI will not always work. If the signal has a little bit of noise you can get wildly different values for the "min index". Try it with a sync function and a small amount (standard deviation = 0.005) of Gaussian noise. The "min index" can be 10, 53, 63, or 110. Which is the right value?
A couple of alternatives:
04-29-2009 12:40 AM
Hi Smercurio,
It's probably safe to assume there's some noise - of course a smoothing filter can be applied before analysis. Since noise will affect accuracy of the measurement, it should be filtered if possible.
It's not obvious to me how your two alternatives offer any simpler approach, or one that will "always work" - given unfiltered data with "noise".
Cheers!
04-29-2009 09:12 AM
See attached VI. As you can see, the Waveform Peak Detection always gives the same values for the locations of the valleys. Your VI does not (though it is restricted to just one).The only thing that changes in each iteration is the noise. Yes, you can always filter a signal, but you will not be able to eliminate all noise, and any algorithm must take this into account.
I also included the derivate graphs so that one can see how they behave.
05-03-2009 04:26 AM - edited 05-03-2009 04:36 AM
Hi Smercurio,
Your VI doesn't work once waveform is modified to look like turbot's example (but my VI does.)
My VI was explicitly designed to work on turbot's example - rising at the beginning, falling at the end.
After you fix your code to work with a waveform like that originally posted, you may want to play with noise settings until my VI stops working. To speed things up, just figure I'll start smoothing. I'm interested just how much you're willing to pervert the original example in order to say "see? your VI doesn't work."
I'm ready to play this game if you are, and I think the burden is on you to supply an algorithm that always works - even when I get to add the noise!
Cheers.
Top: Your waveform, bottom modified per original post.
05-03-2009 11:00 AM
tbd wrote:
I'm interested just how much you're willing to pervert the original example in order to say "see? your VI doesn't work."
I'm ready to play this game if you are, and I think the burden is on you to supply an algorithm that always works - even when I get to add the noise!
I was not playing a game, nor was I "perverting" anything. I was pointing out that the algorithm did not work under certain cases and presented two alternate solutions that the user may want to investigate. You responded by asking why those two alternate suggestions were simpler or were ones that "always worked". I never laid any claims to the solutions being ones that "always" worked. I presented an example where the solutions always gave the same result on a waveform while yours did not. That's it. You seemed to have extrapolated it to saying I was (a) claiming the solutions I presented were simpler; (b) claiming they always worked, (c) claiming yours was apparently not useful or unworkable. As for (a) I would say they are simpler since they use built-in VIs as opposed to having to code up your own VI. As for (b), I never made such a claim and will not be roped into defending a non-existent claim. As for (c) I never said such a thing.
I think the burden is on you to supply an algorithm that always works - even when I get to add the noise!
I have no such burden, nor do I have to prove anything. It's also disingenous to challenge someone to provide an algorithm that will always work when you know this cannot be done.
05-03-2009 01:49 PM - edited 05-03-2009 01:56 PM
smercurio_fc wrote:That VI will not always work. If the signal has a little bit of noise you can get wildly different values for the "min index".
smercurio_fc wrote:It's also disingenous to challenge someone to provide an algorithm that will always work when you know this cannot be done.
Yes, it is.
I think if I were volunteering criticism of your code, I'd feel obligated to help fix it or suggest a better solution - but that's a burden I place on myself.
05-03-2009 03:19 PM - edited 05-03-2009 03:23 PM
Hi Turbot,
Is it possible that instead of a "minimized value" - which might be interpreted as: "relative minimum" - what's important is the point where "1st order Derivative at the 3rd cyccle is not a Continuous function"?
In other words, might the point-of-interest NOT be the "relative min"? (If that's the case, then I agree with smercurio's proposal to use the 2nd derivative.)
Cheers!