How to synchronize analog signal, digital signal and time?

[Jennifer O]

Hi Beavercreek,

Duty cycle measurement uses implicit timing and therefore it is difficult to associate a time with the measurement. Implicit timing simply means that the measurement begins when an edge is seen, not at a defined interval. I like to use the following analogy:

There are two people in a room.  One is turning on and off the light.  The other is using a stopwatch to time how long the light is on or off.  If I ask the stopwatch person, at set intervals, to tell me the time of the signal he may be in the middle of a measurement and will have no useful information to report.  On the other hand, I can ask the stopwatch person to yell out the elapsed time whenever he sees the light turn on or off.  This is implicit timing.

One solution I would like to suggest (which may be simpler for you than trying to sum up semi-period measurements to get a corresponding time) is to read your PWM signal on one of your analog input channels.  You can then see your PWM signal in relation to your data on a graph if you choose.  There is a function, Pulse Measurements.vi in LabVIEW, which will measure the high and low time of your signal as well as duty cycle.

If the signal must be measured with the counter you could clock your analog tasks off of the PWM signal.  However, this would require the PWM signal to be running prior to your analog measurement.  To do this you would wire the PWM signal to an available PFI line and specify the line as your clock source in the DAQmx Timing VI that you use for your analog task.  This would work well if your PWM signal had a constant frequency (i.e. 2500Hz) but varying duty cycle.

Hope this helps,

Jennifer O.
Applications Engineer
National Instruments

[beavercreek]

Hello Jennifer, Thank you for the response!

>One solution I would like to suggest (which may be simpler for you than trying to sum up semi-period measurements to get a corresponding time) is to read your PWM signal on one of your analog input channels.  You can then see your PWM signal in relation to your data on a graph if you choose.  There is a function, Pulse Measurements.vi in LabVIEW, which will measure the high and low time of your signal as well as duty cycle.

I've done some quick calculations on this (I like to know what I'm giving up) and here's what I came up with.  Since my PWM is 30-4000Hz and since I also need to acquire two analog inputs simultaneously (signal input to UUT and PWM output), the maximum sample rate I could get with my 6031E card is 50000S/s.  Which means that I have 13 samples available during each period of a 4000 Hz PWM.  13 Samples equates to 7.7 % duty cycle measurement resolution.  Do you agree?  Using the counter input (20MHz clock) I would have 5000 samples available during each period of a 4000Hz PWM and therefore 0.02 % duty cycle measurement resolution.  Almost 400 times more resolution.  That just seems too valuable to give up  (at least one thing i'm ignoring in these calculations is quality of the 20Mhz oscillator)

>If the signal must be measured with the counter you could clock your analog tasks off of the PWM signal.  However, this would require the PWM signal to be running prior to your analog measurement.  To do this you would wire the PWM signal to an available PFI line and specify the line as your clock source in the DAQmx Timing VI that you use for your analog task.  This would work well if your PWM signal had a constant frequency (i.e. 2500Hz) but varying duty cycle.

Great!  The PWM is running prior to acquisition!  I think this is the method I will be persuing.  Since I need to sample my analog at at least 2500 Hz, this method will work well down to that PWM frequency.  For PWM frequencies from 30 up to 2500 I'm in a no-mans-land with no decent method.  It's really too bad the pulse width measurement vi cant be taught to report stale values until a new measurement becomes available (for example when my PWM is at 30Hz), after all, if a new pulse hasn't been received, the duty cycle can't have changed!(except for in the mind of the controller)  Now that I've said it, I could probably achieve stale data reporting myself with the call external code features of labview, but I'm afraid my learning curve would not meet the timing expectations of my management.

[Jennifer O]

Hi,

You are correct that you will get a much better resolution using the counter measurement.  Depending on what you need to do with your data, your varying analog input measurement rate with option 2 may make calculations difficult. 

If "interpolating" the signal is sufficient for your application a software algorithm may hold the answer for you. By interpolating, I mean repeating the last value until a new value comes in or back filling for samples that would have occurred during the period measurement. You could use the previous measurement until a new one arrives.  Assuming a constant data rate of 2500s/s, you will have a dt of 0.4ms. You could place a DAQmx Read for your analog channel, and one for your counter in the same loop.  Starting the two tasks off the same trigger will ensure an initial alignment, and reading all available samples for both tasks will help to keep the data aligned.

There are many ways you could fill in the data.  Here is one suggestion:

Try using a for loop to interpolate or backfill for each of the counter measurements read.  If you read a pulse of 2.0ms, you know that this lasted for 2/0.4=5 analog samples so you can append to your counter array 5 values of 2ms. After appending the values, move on to the next value in the counter measurement. You could either fill based upon the current measurement, or based upon a cumulative measurement time(i.e. add the counter measurements together to get a total acquisition time). Once you have completed interpolating for each value, compare the length of your analog array to the counter array.  If the counter array comes up short, you would fill the array with the last value and keep track of the time being filled in for the next count so that you interpolate less samples in the next iteration.  Alternatively, you can display only the values up until the last counter measurement and then pass the leftover analog data through a shift register to the next acquisition to prepend and begin again.

This should be fairly simple to implement, the only thing to watch for is accumulating rounding error.  This option would provide consistent analog timing, accurate pulse width measurement (greater resolution)  and correlate the  two signals.  The only caveat is that the change in pulsewidth would always align with an analog datapoint, which may not be the actual point where the signal is transitioning.  To see the analog representation at the same time you could read the signal as an analog channel.

Hopefully this gives you an additional option to consider,

Jennifer O.