Trigger & Gate to split waveform into cycles

[marc1uk]

Hi all,

I'm trying to split a many-period waveform up into cycles using the Trigger & Gate Express vi, but have hit a couple of snags.

For context my ultimate goal is to perform a cycle rms on a PWM drive output. There are a couple of reasons I don't think I can use the Cycle RMS from the Amp & Levels Express vi: firstly the fact that it currently reads ~50V when it should be reading ~80V. I suspect this is because the express vi may not be correctly identifying a complete cycle; the vi uses reference levels to identify a cycle, but my signal is a PWM drive output that isn't really suitable for reference level analysis.Secondly, the express vi only returns one number per iteration, but my data is acquired ~30 periods at a time, meaning for every 30 cycles, 29 don't get analysed.

So I've decided I need to manually split up my waveform. For now I've created a simple little program using the Trigger & Gate express vi that does the job, but again there are a couple of problems. Firstly, it's only returning every other period. Presumably this is because my stop trigger threshold of one waveform will coincide with the start trigger threshold of the next cycle. Is it possible to set up such a trigger system that returns all the data?

Secondly, in order to use the trigger successfully I'm filtering out switching frequency and using the filtered version as the waveform to trigger on. Unfortunately the filtering is introducing a phase shift that means the two now have different trigger points. I've tried using the Align & Resample, but it doesn't appear to do anything.

Can anyone make any suggestions?

[Tori.M]

Hi Marc1uk.

Rather than using Express VIs for your coding, have you considered looking at other VIs available for signal analysis.

There is a VI designed specifically for calculating Cycle RMS called "Cycle Average and RMS.vi" which you can find by right-clicking on your block diagram and using the search from the functions palette. This VI can be used for periodic signals, although I appreciate your concerns that by changing the duty cycle of your PWM signal it may not fulfil your requirements.

To overcome your triggering issue, one of the simplest ways may be to change the parameters for your stop trigger. If you set this to the falling edge of the signal and something like 0.2 then hopefully the triggering will be stopped just before the next trigger gets started.

Unfortunately you're always likely to see some phase delay occurred through software filtering in any language. How much phase delay are you experiencing? One option that may reduce this slightly is to change your Filter Express VI to a lower level "Butterworth Filter.vi" which you can find through the Functions >> Signal Processing >> Filters, palette. For this, you can create constants to configure the VI to the same properties as your express VI i.e. a constant of "3" into the Order input, a constant of "Lowpass" into the Filter Type input and the output of the x*5 expression into the Low Cutoff F input.

Hope this information helps you further on your way! If you have any questions don't hesitate to ask.

Kind regards,

Tori

[marc1uk]

Hi Tori, apologies for the lateness of reply. I had looked into the different vi's available but they appear to work on the same principle of reference levels and give exactly the same result, neither of which tie up with readings from a power analyser (although you do get programmatic control over the reference levels).

I had thought about having the start and stop trigger levels as slightly off, however this means having a gap in my data - albeit a small one if the levels were close enough. The trouble the gap I'd need depends both on the amplitude of the wave, which would vary so the trigger levels would have to be programmatically determined, which doesn't seem possible. Even if it were, I have to have a sufficient gap that there are datapoints between the two thresholds otherwise triggering still doesn't work.

The phase shift is ~20 degrees i'd guess, although I realised it's not so much of a concern as I'll still be getting a full period. The below screencap illustrates both the phase shift and the accumulating loss of data - you can see the shift between the two waveforms decreasing where the clipped data is shortening the waveform.

[majoris]

I know for certain if you use FIR filters, there are tricks when you're working in post processing to get rid of the phase delay. Namely, can you take a signal. Filter it. Reverse it. Filter it again with the same filter. And then reverse it. The general idea here is that what you're actually doing is using a non-causal filter (which you can actually design if you so choose), but this technique works just as well, I believe (this is mentioned in Digital Fitlers by Hamming). This is a really good paper on it for FIR filters: http://larpdocs.fnal.gov/LARP/DocDB/0003/000359/001/zerophase20Mar2006.pdf. I'm not sure how well this extrapolates to IIR filters, but it probably works.

[marc1uk]

@ Majoris:I remember reading something along those lines to remove phase delay introduced by filtering before, but it did seem considerably more complicated than I'd expected it needed to be. To be honest I'm not really sure why a simple align wouldn't work, but I'll look at the paper you've referenced and give it a try.

Unfortunately after that fun little excursion it doesn't seem an incorrect identification of the cycle makes a lot of difference!

I set up a real measurement input to try'n get a feel for the trigger levels and how much data would be lost. Although not every waveform is being measured, it's getting a good sample of appropriate cycle lengths. The RMS comparison, however, is actually almost identicle to the existing vi's. I wouldn't say this is because the built-in vi's are in fact correctly identifying a complete cycle,  - an FFT shows the switching frequency is actually the largest component and any frequency analysis tools pick it out rather than the fundamental - but it looks like this isn't the source of the RMS discrepancy with our Power Analyser.

H'mm...

[Ben]

In this thread CC and I discussed how to deal with the data loss you get and the front and back of Zero Phase Shift Filter by reflecting the data about the last point blah blah blah.

Ben

[marc1uk]

Thanks Ben, that's quite a story for sorting out what seems like a very mathematical issue! It's jumping through a few hoops but seems to the trick, i'll definitely be putting it to use.