Measure the height of an square pulse

[CoastalMaineBird]

Given that the original post said " the occurrence of the pulse is random", I don't think you can do that.
I was assuming that every pulse had a different amplitude, as well.

[Ben]

Good eye!

I missed that one.

So the signal is not rectangular and the simple approach falls by the wayside.

Ben

[Ben]

How about going back to the triggered acquisition and using the,

Waveform>>>Waveform measurements>>>Amplitude and Level.VI
and
Waveform>>>Waveform measurements>>>Transition and Measurements.VI

They can do 10Msamples in less than a second. See attached.

Ben

[Photon_Dan]

Triggered is OK as long as the next pulse doesn't happen while you are trying to re-arm it.

- Dan

[Ben]

Agreed!

Ben

[S.Klumpp]

Thank you very much for all your help!
All your suggestions helped me to get a new viewpoint for this problem and hopefully will get me to the solution.

I will be back if not.

Thanks again!

Stephan Klumpp

[Ben]

Please keep us updated on what actually worked.

Ben

[S.Klumpp]

I will!
Thanks for your interest.

I tried so far your code example and it accelerated things pretty much. But unfortunately it works only with LabView 6.1, so we have to update!

Stephan

[S.Klumpp]

So I tested Ben's example program "Measure_High.VI" and as mentioned earlier it accelerated things pretty much. But unfortunately it just finds the highest amplitude in an array and returns it. But I like to find every one and return the height in an array.
It tried it brute force, looking for high states and deleting the low states with "Delete from Array" but it takes awful long!
Well, to give an example: I consider the worst case analysing an array of 5000000 elements by brute force. This represents a 5s measurement with a sampling rate of 1MHz.
With LabView this takes hours. I tried this also in Pascal and C under DOS and this took just between 0.5 and 1.5 seconds.
I attached the LabView file I created for the simulation. Maybe I'm just to unexperienc
ed to write efficient LabView-Code.
Is there another way to speed things up ?

[CoastalMaineBird]

Well, I measured your test at 23000 mSec for 100,000 counts. I rewrote it and measured it at 26 mSec for 100,000 counts.

So, I'd say there is room for improvement.

For one thing, you're not measuring what you think you're measuring - you include an indicator in the loop your timing - so your time includes the time to convert 100,000 integers to text strings, and write them to the display. That's not a legitimate way of measuring timing. Take out your indicator and your time improves a lot (to about 17 sec).

Second, use operations on arrays over an array of operations on elements whenever possible. In other words, use a single comparison on the array, and you get an array of boolean results.

Third, don't use DELETE ARRAY
in a loop if you can avoid it.

Fourth, you subtract i - x every time thru the loop, needed or not.

I have attached my rewritten version of your test.

Remember my motto, when thinking about how to speed up a program.

WORK YOU DON'T HAVE TO DO IS JUST LIKE WORK YOU'VE ALREADY DONE. It doesn't take any execution time.