LabVIEW
TDR Edge Detection and analysis
Thank you for attaching your code, and also thank you for attaching some data.
Let's analyze the problem "backwards", starting with the last VI in your code, Basic Level Trigger Detection. Look at the Help for this VI -- notice that the Input is specified as a Waveform, not a 2D array of Dbl (with the first column being "Sample Time" and the second being "Sample Data").
A Waveform is a LabVIEW data construct for sampled data, the idea being that the data are acquired at equally-spaced samples (as precise as the hardware can make it). The Waveform is like a LabVIEW Cluster with three components: t0, the Timestamp when the data were acquired (you often don't need this); dt, the Sampling Interval; and Y, an Array of all of the Samples (3633, in your case). The Waveform is understood by Graphs and Charts, so plotting a Waveform (where only the Y values are "obvious") will produce an XY plot where X is time.
But never mind. Follow the Array wire you sent to the Trigger Detector -- it goes back to the first column of the 2D data Array. Do you see the problem? Suppose I plot this "by itself" -- here's what I see:
This is a Waveform Chart, so the X axis is (in this case) Sample #. But what is being plotted? Why, it's the first column, which is supposed to be the Sample Time, which is (one would think) supposed to be a straight line (as all of the sampling intervals, the increments in time, are supposed to be the same). What is really being plotted (on the Y axis) is the cumulative Time-to-Sample-N. It's a bit of a brain-twister, but I think if you look at, say, the plot around Sample 1000 (which looks to be around 0.000005), the slope of the line there (5e-6/1000) is the reciprocal of the sampling frequency at that sample, which makes the sampling frequency around 200 MHz, while near the end of the sampling, the slope of the line is much steeper (I won't try to estimate it), which means its reciprocal is much smaller. You can look at the differences between successive X values in the spreadsheet, which bears this out: at the beginning, they are around 10^-9 (or 1GHz) and at the end, they are more like 10^-7, or 10MHz. Very uneven sampling times!
So a multitude of problems. First, you are trying to find Peaks in the wrong signal, the "time", not the "data", signal. Second, the Peak-Finding algorithm expects the (data) sample be taken at equal time intervals, which is not the case for your data, so you'll have to "synthesize" data as through it were taken at a fixed data rate. And finally, there's the question of can we trust the data at all from Proteus 8, given the vast changes in sampling time from the first to the 3000th point?
I'd start with getting clean data. I don't know how you are collecting it, but you are forgetting the First Rule of Engineering -- "Look At Your Data, and See If It Makes Sense".
Bob Schor
