Measuring duty cycle with the DAQ6510

I would like to know the best approach(es) for measuring the duty cycle of a PWM signal with the DAQ6510. I realize that the 6510 is not the ideal instrument for this task, but nonetheless I would like to better understand the programming/trigger capabilities of the 6510 and how they might be used to solve this type of problem.

The signal in question is a 1 kHz PWM (0 -> 3.3 V), and I don’t need high accuracy, +/- 1% would be sufficient. Ideally this would be a TSP script that I can call up from the front panel of the instrument.

Ultimately, if this is possible then my “final application” would be to use duty-cycle as a Trigger to start a scan of some rear-panel (multiplexed) input channels. For example, wait for the duty-cycle on channel 101 to be >= 80% and then initiate a scan of channels 102-105.

Does anyone have any ideas how to go about solving this task?

 

Here's what I would do in TSP:

1. Since it's a 1kHz signal, you will need to use the digitizer to digitize the PWM signal voltage. Refer to page 4-31 of the Reference Manual to learn about digitizing if you're not familiar.
2. Configure the digitizer to measure some number of points, maybe 1M. This is the sample you will use to determine duty cycle. The digitizer measures at 1M pts. / second. The internal memory can hold a maximum 7M points.
3. Create a limit with dmm.digitize.limit1.high.value of say, 1V. We will use this to flag when the PWM signal is high or low. You could alternatively use dmm.digitize.limit1.low.value, but no need to use both.
4. Use buffer.make() to create a new buffer to hold your reading.
5. Use dmm.digitize.read(bufferVar) to make a measurement into your buffer.
6. Iterate through your buffer in a loop, tracking bufferVar.statuses to count how many readings were high/low based on limit1.
7. Use the count of high/low readings and the length of your measurement to determine duty cycle.

Some variation ideas:

• You don't have to use the limit method, you could take the readings and iterate through the buffer readings with greater than or less than operation to determine high/low.
• You might want to verify your method works through the front panel before routing through a switch card. It will work the same, but it can be easier to debug a method like this without worrying about channel settings.
• You could use the trigger model to set up your measurements. The trigger model provides the best response time if timing/speed will be an issue for your application. Though, the method I described will iterate through a buffer, there might be a less processor-heavy way of doing this that hasn't occurred to me yet.
• You could adjust the digitizer aperture with dmm.digitize.aperture if 1MS/s is too many samples for you. Thinking about it, you might want to, since 1MS/s might catch a bit of the PWM edge transitions on a 1kHz signal.

Thank you Bradley for your very insightful suggestions. It had never occurred to me to take a series of measurements and then post-process to look for a trigger condition. Working with the DAQ6510, with its powerful on-instrument processing, takes some getting used to and causes us to rethink our old ways of doing things.

I tried a solution similar to what you suggested, basically a digitized acquisition of X measurements and then analyzed them looking for positive pulses which then gave me the pulse widths I needed. I didn't use the limits/statuses as you suggested, mostly because I was not familiar with those at all, instead I just examined the reading values directly. I found the post-processing of 1M points did take some time (~7 seconds) which was longer than I'd expected but not a problem in this application because I'm just scanning temperatures.

As a exercise I went a bit further and experimented with using the trigger model as you hinted at, but this didn't really help with the processing time as I still needed to iterate through the readings array to find the edges. (I used "LoopUntilEvent" with a rising edge condition.) Since I knew beforehand the width of the pulse(s) I could reduce the sample count to much less than 1M and this sped things up considerably, to around 25ms which makes this solution feasible for future use on scanning other signal types beyond slowly changing temperatures.

Thank you very much for your suggestions, and if you do think of any ways to employ the trigger model I'd love to hear about them!