05-29-2009 04:17 PM
05-29-2009 04:37 PM
I cannot load the arithmetic" express VI, It seems there are some signalexpress components (CG .......vi) missing.
Where did you get that one? What does it do?
05-29-2009 05:02 PM
I found the arithmetic expresss vi. by going to Functions>>Signal Express>>Processing>>Analog Signals>>Arithmetic.
LabVIEW help had this to say about the function:
Performs arithmetic operations on two signals. The available operations change depending on the type of the input signals you select.
To select the correct type of operation, select the first signal to process from the Input signal 1 pull-down menu. The Input signal 2 pull-down menu displays only the list of compatible signals, and the step displays the available operations.
Parameter | Description |
---|---|
Input Signals | Displays the two input signals. |
Resulting Signal | Displays the signal that results from the arithmetic operation. |
Input | Contains the following options:
|
Configuration | Contains the following option:
|
Filter Setup | Available when you select Filter based from
Interpolation type. Contains the following option:
|
The operation I'm using is "add", I am NOT ignoring time stamps, I'm using linear interpolation, optimized for a single record, and the two inputs are time waveforms
05-29-2009 05:59 PM - edited 05-29-2009 06:04 PM
OK, signalexpress != LabVIEW and I don't have it. 😉
Still I undestand what you are trying to do, and you are doing this orders of magnitude more complicated than needed. You create tons of waveforms, one for each spike, and then later add them all together. This is a lot of work, memory inefficient and it is slow.
Here's the trivially simple solution using plain convolution.
You simply create an array containing the spikes, then convolute it with the Gaussian kernel. Compare the speed to your solution and you'll be amazed. (Since I create a real histogram for the time points, you could even reduce the time resolution drmatically and still get about the right answer).
Let me know if you have any questions.
06-02-2009 01:40 PM
The convolution method is about 10x faster than the addition method. However, the addition method is arguably more accurate given that the kernels are already aligned at the peak times. I say arguably because the convolution method could be made more accurate (at the cost of speed) by decreasing the delta t. Anyway, I've chosen to use the convolution method becasue of it's already widely accepted use. Thank you for showing me how to set that up.
I think I finally came up with a method of generating the kernel function that we can both agree upon. It calculates the kernel without any loops or special scaling at the end. The area under the curve always comes out to 1 (.9999) no matter what the width or resolution is set to. Could you please take a look at the attached VI and let me know what you think.
06-08-2009 10:41 AM
06-08-2009 02:24 PM - edited 06-08-2009 02:25 PM
Yes, it looks good.
You probably should keep the FP closed during run, else the waveform graph update would add to the cost of running it. You don't need the waveform graph except for debugging.
If this subVI is used often with similar or identical inputs during a run, you might want to add a feedback node to cache the result. Now simply check if the inputs are the same from the previous run and use the cached ouput if they are. (see image, the false case simply connects the output of the SR to the output tunnel of the case structure).
Since your data is symmetric, you need in principle to only calculate one half of the curve, then invert and merge. It's probably not worth for this simple equation, though. It would also complicate the code, because it is slightly more involved for odd numbered outputs.
11-18-2010 08:59 AM
Hi, Altenbach. I happened across this thread, searching for information on Gaussian kernels myself. And the thing you are talking about, "width at half height", would be just the thing for me. If it's handy, would you mind showing me a version that takes that for a parameter?
I'm actually needing to compute a 2-D Gaussian convolution kernel -- but if I understand right, that's just the outer product of a 1D kernel with itself. True?
Thanks,
Ken