06-10-2016 08:42 AM
Greetings everyone, I am working on a project that requires detecting a particular event that, from the looks of it so far, can be seen in the gathered data of a sensor. As you can see in the screenshot below, the blue data marks a regular interval of cycles, and the red shows a series where the event was forcibly induced to occur every iteration.
We are however reluctant to just go for a "top ceiling" approach, because the sensor throws a spike every now and then that could be interpreted as the event, plus the top values vary depending on user input and mechanical variables, and a max value won't work for all cases. I have heard about LabView graphical analysis toolkits that could help with this, could anyone please point me to an example, video or whatever that helped me analyze the graphs and find the event?
06-10-2016 09:13 AM
Ok, you do not like maximum, what is your criteria then? It will determine toolkit requirements.
How much and what can vary? What do you want to determine automatically, what can be set as parameter?
You can estimate noise and/or signal levels before the maximum - simple array subset + maths statistics pallette.
More advanced - determine period (if it changes), specify and update sample (good period) and run correlation analysis.
One more question, how fast should it work? Is it real-time, or offline analysis? What is the period of a signal?
06-10-2016 09:37 AM
When I look at your graph, lacking knowledge of what you are measuring, what is "stimulus" and what is "response", it is not at all clear to me what I would "detect" as an Event! Looking at the Red and Blue traces, the most obvious difference between them is the level of high-frequency "signal" (or "noise") in the Red trace (relative to the Blue), nore or less throughout the trace.
I agree that the main issue is going to be developing a set of "rules" that allows you to say "This is an Event", and, equally important, "This is not an Event". Once you have the rules, implementing the algorithm should be fairly straight-forward, but you need to decide on the rules.
Bob Schor
06-10-2016 09:40 AM
X axis is time and is constant, 2kSamples at 2kHz. Y axis is force in Newtons and it can vary from roughly 400 in the lower stress mechanical systems, to roughly 1.5kN as normal in the heavier ones, and probably peaks around the 3k department. I want to determine when the system exhibits a peak like the one seen in the red graph, that is different from its usual behavior. for example if the cycles are typically 800N max I don't mind much if there's a 900 spike, but a 1.3k is a big deal and I want to know about it.
It works off already collected data, via a call to the buffer of the DAQmx, so the algorythm goes something like: sequence runs > critical portion occurs > data is gathered from the buffer > data is analyzed from the buffer > event occurred yes or no. The period of the signal varies due to user input and mechanical variants, but I use the timing functions to know how long it took for the critical portion to finish to know how much buffer I need to call back.
06-10-2016 10:03 AM - edited 06-10-2016 10:25 AM
I would calculate average value of maxima of a "calibration" run, and specify limit in percent, not in absolute values. If you have multiple periods in buffer and only one is suspicious, you do not need separate calibration run - you check all periods anyway.
One more difference I see is that in case of signal, maximum occurs before falling edge and for normal - after rising edge. It will help not only determine event, but also to find a glitch
06-10-2016 10:26 AM
Sadly, I don't think I can recall more periods from memory in terms of processing power, since the hardware I'm running this on is already starting to feel the stress. Was thinking about a "running average" indeed, would it be best to implement it as a "fire and forget" where you get data once? (these are day-long tests) Or to keep the average value in a shift register and constantly average it with values that fall within the limits, and discard spikes from the averaging and counting them as events?
06-10-2016 10:40 AM
I prefer running average. Obviously with an option to restart from manual limit in case of changes.