False Peaks with Threshold Peak DetectorI

[Pablop]

I use the Threshold Peak Detector (TPD) to find transitions in waveforms. It works great. I vary the "width" based on sample rate so that I can avoid false detections. This works well but there are occassions where I can still get a failure. Small levels of noise causing the signal to jig across the trigger level. Increasing the width can remove these as well, but....

Is there a reason why the width should apply only to the setting of the peak detection, and not also the unsetting?

That is, if I set the width for 10, the rising signal must stay high for 10 samples. At sample 10, its a valid peak. If sample eleven drops below the theeshold, for only one sample, then the TPD is now looking for the next  peak.

I'm kind of a Dummy when it comes to signal analysis, but it seems to me that using the width on both sides would have its benefit. (At least in my apps )

[johnsold]

Paul,

Please post your VI with some typical data which exhibits this problem. I am having some trouble understanding exactly what you are seeing.

Lynn

[Pablop]

See attached image False Peak.

The TPD detected a peak at sample 866110, because the signal rose above 1.75 V and stayed above for at least 10 samples.

At sample 866120, the signal just barely dropped below 1.75 V, resetting the searach for the next peak. The next peak was found at 866121, just one sample later. Also attached is an image looking at the same are with opened up chart ranges.

If the TPD could use the same width value before resetting to look for another peak, it would, in essence, be acknowledging that the sort of signal jigging we want to avoid seeing can in fact exist on both sides of the detection.

[Pablop]

Sorry, I goofed the second image and didn't go out far enough to see the actual transition regions, but you get the idea.

[Kevin_Price]

As I look at your data, what I see (I *think*) is an overall trend which has some high-frequency dithering due to quantization effects.  Apparently, you have a threshold somewhere between adjacent quanta and would like to see when your data passes through it.  However, the dithering causes some problems for the Threshold Peak Detector.

Given your .sig, I kinda suspect we're looking at encoder speed information that is calculated with a simple finite difference of position data divided by the sample period.  If so, you may avoid some of these data processing issues if you acquire frequency directly instead of calculating it from an acquired position.

Meanwhile, an interesting filter you might try is a Median filter.  It's really good at maintaining sharp transitions and not inducing a time delay between input and output.  Other types of filtering or curve-fitting could also help, and there are many, many to choose among.

Can you describe the app a bit more?  The best overall solution may require reframing the problem a bit...

-Kevin P.

[Pablop]

Hey Kevin,

I am aquiring a square wave using a scope card. The data previously posted is the "raw data"; voltage as a function of sample number. I aquire a fixed number of samples then analyse this data to pass or fail the UUT. I need symmetry, symmetry jitter, frequency, count and in conjunction with another simultaneously aquired signal; phase and phase jitter. Most of these can't be provided acurately by built in NI VI, if at all. I use the the raw data array, then create an interleaved array of rising and falling edges as a function of sample number. This array might look like:

0         100
2         210
3         300

So this square wave has a rising  transition at sample 100, a falling transition at sample 210 and the next rising edge at sample 300. And so on for up to 16,000 or so edges.

I like the idea of filters that don't inhibit test time. Software filters work great, but are very slow when sifting through over 1 million data points. Hardware filters are nice, but not easy to design for each application.

Is the median filter a software filter?

[Kevin_Price]

Ok, gotcha -- the quantization has to do with A/D resolution.  I'm accustomed to 16-bit +/- 10V max data acq cards which quantize to a much finer resolution than the 10's of mV seen in your screenshot.   Still, you mention square waves, and I can't help but wonder if at least *some* of your measurements could be better handled with counters or hardware-timed digital input, once you TTL-ize the raw signal(s).

Anyway, you're going to need to clean up that signal somehow.  The bottom line is that the dithering isn't real, it's just an artifact of the limited resolution of your acquisition.  Thus you have no moral obligation to retain that high-freq dithering information.  The "right" kind of filtering is highly dependent on the specific needs of a given app, so there isn't a perfect choice.  All have trade-offs of one kind or another.

The Median filter is a software filter.  My remark about time delay means this: if you pass your array into a Median filter and then plot the input and output together, the output will tend to show sharp transitions at the same index/time as the input.  It tends not to induce a "phase delay" effect.   Most other standard filter types *will* both induce a phase delay *and* round off the sharp edges of transitions.  However, the Median filter is probably relatively slow in terms of execution time.

Since you expect square-like waves as input, be aware that many standard filters can produce a ringing phenomenon in their time-domain step response.  This may steer you toward the Bessel style filters where such ringing is easier to avoid.  Like most (all?) of the FIR and IIR family of filters, Bessels will induce a phase delay.   However, if you subject all your inputs to the same Bessel filtering parameters, the *same* delay will be induced to each.  Thus the phase *difference* between a pair of signals is preserved.

-Kevin P.

[johnsold]

Paul,

Kevin's idea is a good one. The median filter is a software filter.

Why try to handle a million points when you are only looking for a transition which takes a few thousand points (estimated from the graph you posted earlier)? Find the first place where the threshold is crossed, take 1000 points before and after that point, apply the filter or linear regression to the 2000 points, and find the threshold for that segment. Repeat for the next threshold crossing until done.

Using your Actual Form.jpg as an example and taking the threshold to be 1, puts the first crossing at about 865764. The data from 865600 to 866000 appear to fit a straight line quite well. Just grabbing two points from the graph (865600, 0.65 and 866000, 1.5) and solving the equations of a straight line gives x (y=1) = 865764.71.

Lynn

[Pablop]

We build rotary optical encoders, and I'm testing there output during final test. If all I needed was the edge transitions, I would indeed be using counter cards or hardware timed digital input (whatever that is )

But, I also need to verify the On andf Off voltage levels of the square wave output, and, on some products, I need to test what we call the "Raw Cell Output". This is essentially the low level analog waveform, mostly sinusoidal, and generallaly around 100mV peak to peak.

For that and other reasons (inherited station design, general lack of EE knowledge!), my current system config looks like this:

PXI Chassis with MXI-4 to PC workstation
Scope card
Switch Card
DMM

I use the switch card to send two channels at a time to the scope card. There are up to 12 TTL channels to be tested and another 4 for the low level analog. I do apply filtering to the analog signal, because there was no way to get a reasonable signal without. I can also apply the filtering to the other shannels. The attached sub-VI is used to aquire the sigals and is based on the NI example. I use it prodigiously!

I like the idea of filtering just in the transition regions and will have to give that some thought. Sounds like it would add computation time to select a region for further computations, but maybe not as much as filtering the entire wave form.

Thanks for the input, any other suggestions would be greatly appreciated.

[Pablop]

Kevin,

I'm using an 8-bit digitizer (PXI-5112). If I stepped up to a 14-bit digitizer, do you think this quatizing error would go away for the case I pictured previously?

Thanks,

Paul