Counter - Read pulse duty cycle and frequency

[nebu5]

Hi!

I am trying to read a PWM signal from a microcontroller and I would like to read the duty cycle and the frequency value from it. I have seen that there is an example in labview (Counter - Read Pulse Duty Cycle and Frequency (Continious).vi). My question is, in the external clock source what I am supposed to connect? The clock from the microcontroller? How can I do that? I am using a cDAQ to acquire data and I have a digital input/output module connected to it.

I tried to remove the sampling clock in the vi but the problem is that I can't know the frequency, although the duty cycle is working pretty well. 

I would be happy to see the replies.

[Kevin_Price]

All you should need to do is change the little drop-down menu under DAQmx Timing to use "Implicit (Counter)".  I'm kinda surprised the example wasn't configured that way in the first place.  You'll no longer need to specify a sample clock Rate or Source.  Sample timing will now be handled "implicitly" based on the timing of the incoming signal transitions.

In Implicit timing mode, there's no guarantee (and often no great likelihood) that samples will be equally spaced in time.  The individual frequency values will imply the sample intervals (interval period = 1/freq), and if desired you can track cumulative time of all the measurements by tracking a cumulative sum of those intervals.

-Kevin P

[nebu5]

Thank you for your reply, I really appreciate it. I changed the timing to implicit (counter) and now it returns this error:

[Kevin_Price · Accepted solution]

That error text gives you some specific suggestions.  Which have you tried?  What happened?

Try opening a 2nd shipping example for continuous counter pulse generation.  Configure it to use a different counter and select a specific PFI pin for the output.  Set it to run at a reasonably high frequency, say >= 10 kHz.  Run the program and let it keep running.

Then specify that same PFI pin for your freq/duty cycle measurement program and run it.  Assuming this works (it should, unless you have a 0 timeout or something), then your microcontroller pulses are either too slow, not present at all, or not TTL-compatible.

-Kevin P