Measuring pulse width 3.3khz signal

[Jake_U+1F346]

So I'm trying to measure the inductance of a component by pairing it with a capacitor and exciting it for 100ns with 5v. This gives me a 3.3khz decaying sine wave that lasts roughly half a millisecond before it gets too weak to reliably measure. That part works fine.

What I can't seem to get to work is getting that signal into my NI 6320 counters to work with the high frequency w/ two counters example. Per the example vi, I followed the search for "Connecting Counter Signals" instructions, clicked the myDAQ Signal Connections for Counters help link, and added the DAQmx Channel block as suggested to try to connect the signal to the counters via pin 1 (/Dev1/PFI14) as shown in the attached vi.

I've tried a handful of different things but I must be missing something dead simple for why this isn't working. The example and help sheets make it sound as easy as tell the counter which pin to listen on and it'll work. I've connected a signal generator to pin 1 emitting a 3.3khz 5v P-P square wave for now to eliminate any uncertainties with the actual parts, but still no luck.

There's a fair number of posts from several years ago about similar issues but the accepted answers are either not the problem I'm having or are "check this link" and the link is broken.

[Kevin_Price]

Counters on NI's DAQ devices are intended only for digital logic signals, not decaying sine waves.   Even if the sine wave amplitude is sufficient for a while, the rise time and fall time will be too long to meet logic specs.

Maybe you should capture this as an analog signal where you can acquire at up to 250 kHz?  That's more than enough to capture a sine wave, the bigger problem will be that a 3.3 kHz "decaying sine wave" that lasts for half a millisec only gives you 1.5 sine wave cycles to work with.  That may put a limit on the robustness of the post-processing you do.

-Kevin P

[Jake_U+1F346]

Grabbing the signal via 250khz analog sampling is what I did at first, and it worked ok, but the resolution is too poor to get a useful measurement. The change in frequency per step is roughly 40hz, combine that with the arbitrary phase shift between the input signal and the internal counter and the reading has a lot of jitter and quickly becomes useless. For reference the target I'm aiming for is +/- 100hz.

I'm not worried about analyzing the sine itself, I just need to accurately measure the pulse width of half the wave. I'll handle turning the sine into a square wave in hardware so that won't be a factor for the NI hardware.

If I can count the number of 100MHz cycles in one half of the 3.3kHz cycle I'll be golden. For reference measuring one full cycle of the 3.3kHz wave via the analog read gave me 75 counts, counting the 100MHz cycles in one half of the 3.3kHz wave will give me roughly 15 thousand counts, much more precise.

I can always hit the inductor multiple times to get multiple half waves and do an average of those to improve robustness too. With such a short cycle time the hardware could easily do a hundred tests in one second, assuming the computer itself can handle that rate.

[Kevin_Price · Accepted solution]

Ok, that sounds more like it.

I don't know electronics well enough to give specific guidance on converting your decaying sine into digital logic.  I imagine something based on zero-crossings, along with an input-side capacitor to eliminate any DC offset.  Fortunately it sounds like you've got that part covered, so let's start from where you have good clean digital logic that transitions at each zero-crossing of the original sine.

While it may seem natural to configure a counter task for pulse width measurement, I think I'd want to measure both the rising-to-falling width *and* the falling-to-rising width.   In theory you'd expect them to agree, but it'll be good to know if in practice they don't.

Therefore I'd configure the task to do Pulse measurements, a relatively newer feature that your device should support.  I'd also work in buffered acquisition mode by configuring DAQmx Timing.  I suggest "Implicit" Timing.  I'd probably also go with Continuous Sampling since you won't know ahead of time exactly how many measurements you'll get.

Then I'd set up a way to generate the stimulus pulse at <= 500 Hz.  That puts a full 2+ msec from one to the next and your response time is only ~0.5 msec, leaving plenty of margin.

Each stimulus will probably generate 1-3 pairs of high and low times.  They'll always come in pairs in pulse measurement mode.  2 or 3 defined intervals give you 2 values, 4 or 5 give you 4 values.   (A semiperiod measurement mode exists where you'd always get values from N intervals, but it may be tricky to track which are highs and which are lows over multiple stimuli.  I'd stick with pulse measurement mode to start with.)

These measurements get buffered up by the driver and you can read them at a more leisurely pace.  You can even make a big buffer (say 10000 samples worth, which ought to hold 10-20 seconds worth of response with a 500 Hz stimulus), start things up, and decide later how much of the data to bother reading.  You can ask for a specific # of samples or you could wait for a specific amount of time and then retrieve whatever amount is available.

To get started, check out the shipping examples for Counter Input.  Find one that does continuous pulse measurements that come out as a duty cycle / frequency pair.  Change it to use the "Implicit" version of DAQmx Timing and delete the user controls for sample rate and external clock source.  You'll probably want to modify the stated max frequency and "samples per loop" too.

   At first it'll be easiest to run this example and use math to convert: High time = duty cycle / frequency = duty cycle * period.  Low time = (1 - duty cycle) / frequency = (1 - duty cycle) * period.  Later, you can work at modifying the task config to directly take high time / low time measurements.

-Kevin P

[Jake_U+1F346]

I looked for one of those examples like you suggested, Counter - Read Pulse Width and Frequency (Continuous).vi worked perfect for this. It seems knowing where to look is half the battle.

Now I just need to trim the extra example features out like you suggest and I should be on my way. Thanks!