Measure rise time with USB-6363

[Jesse278]

Hello,

I am using USB-6363 and am trying to measure the rise time of a signal (10% to 90%) that is approximately 450 ns. The maximum sample rate of the USB-6363 is 2 MHz, so the resolution is not enough to capture this rise time. One idea I had to get around this is to use the counter, that has a 100 MHz clock, and measure the 2 edge separation between two digital pulses. The first pulse would be triggered by the analog input at 10% amplitude and the second pulse would be triggered by the analog input at 90% amplitude, so the 2 edge separation will be the rise time. Is this feasible and how would that work? Is there a better way to do this?

Thank you in advance,

Jesse

[croohcifer]

The digital lines on NI DAQ MIO devices do not have programmable thresholds.  They're all TTL I/O, so you'd need some external circuitry to enable this.  A simple option might be to use external buffer circuits with programmable thresholds that would output TTL pulses when the input signal crossed the 10% and 90% thresholds.  You could then wire those TTL buffer output signals into the DAQ board.  There would be additional errors in this circuit that you'd need to characterize and compensate for in addition to the inherent 10 ns quantization error of the counter.

The easiest (though more expensive) solution would be to purchase a scope capable of taking these measurements directly in the analog domain.  It's simply too fast an edge for any typical DAQ card to acquire with the fidelity you'll want.  All NI scopes can take a rise time measurement natively through the NI-SCOPE API.

[Jesse278]

Could I use an analog trigger signal as the TTL input to the counter? So I would setup 2 analog triggers at the 10% and 90% thresholds for a signal wired to the analog input, and then use the 2 trigger signals to start and stop the counter and/or measure the time between the two trigger events?

[croohcifer]

If there were two analog reference trigger comparators, you probably could, but there's only one.  To the best of my knowledge, NI doesn't make an MIO DAQ card with two comparators.  Even if they did have two channels, I don't know what the bandwidth is on that channel.  NI doesn't publish it.  That said, it could very conceivably be less than the (0.35)/(450 ns) = ~780 kHz you need to not attenuate your edge.  Given that the 6353 is a relatively low speed (~2 MS/s) DAQ board, I wouldn't be surprised if there were a low-order low pass filter on the channels slapped on there around the 1 MHz or lower cutoff to lower noise on the channel in general.  (To be clear, that's speculation, but it's a moot point anyway since there's only analog reference trigger comparator.)

[Jesse278]

Thanks for all your help! I've got one more idea before I start looking into adding some additional circuitry to perform this measurement.

I was looking at the analog window trigger mode, which will maybe work for my purposes. If I set the bottom and top to my 10% and 90% thresholds and trigger when entering the window, the analog comparison event will be a digital signal that is high while my signal is in that window. I could then use the counter to measure that pulse width to get my rise time. 

I tested it out with a different signal where I expected the window to be ~500 us and the counter seemed to measure it accurately, but when I tried to measure my 450 ns rise time, the counter reported 27 us instead. Perhaps it isn't accurate enough to measure such a small window?

[croohcifer]

An interesting approach!  The counter should be resolute to 10 ns, so a 450 ns pulse should be within its capability.  However, just because the counter is resolute to this level doesn't mean that the traces actually have the bandwidth to support toggling at 100 MHz and rising to the full logic level.  (TTL has pretty slow edges compared to CMOS or other faster electrical standards.  I believe the TTL edge rate spec is as loose as 50 ns.)  I think you're likely running into a bandwidth limitation somewhere in the signal chain.  You could try to characterize this by firing a single pulse into the analog reference channel and reading the counter results. Start at something like a 10 us pulse, confirm that you get 10 us out of the counter, and then keep shrinking the pulse width until the counter fails.  (You can also use DAQmx Connect Terminals to route the analog comparison event out a PFI line so you can scope the pulse directly.  There's no guarantee that the signal you scope is of the exact same quality and shape that the counter will see, but it should give you an idea.)  It's important that you only send ONE pulse at a time for these experiments so that you're guaranteeing that the counter is only measuring the one pulse that should be generated.  If you're seeing 27 us during your 450 us test, I suspect that you're putting a bunch of pulses in the analog ref channel, and the counter is just happening to grab an edge here and there when the signal happens to cross the threshold or something goofy like that.

[Kevin_Price]

I had to hunt around a bit to find an X-series DAQ device that supported the "Analog Comparison Event" signal.  Though I didn't try to confirm with a scope (do as I say, not as I do...), I got some pretty good confirmation from the use of DAQmx tasks.

1. I hardwired AO0 to APFI0 and AI0.

2. I modified an example to configure AI for an AI Window reference trigger.

3. I configured a counter task to monitor the the Analog Comparison Event.  I tried both edge counting and pulse width modes.

4. I brought up 2 AO examples, and ran 1 at a time.  One was continuous sine wave generation, the other was software-timed on-demand.

Summary: all appearances were that the Analog Comparison Event signal went high when entering the window (either direction) and low when leaving the window (either direction).  Of note: a step change in on-demand AO value seemed to reasonably measure the AO slew rate, showing 250 nanosec for the pulse width (aka, "time in window").  When running AO in sine wave mode, I could see extremely regular (but much longer) pulse widths and make them change live by updating the AO sine wave frequency.

I dunno why you got a 27 usec measurement.  Can you post your code to show the DAQmx configs?   Also of possible note: the AC event signal can toggle as the AI task is started and stopped.  During my experiments, I artificially lengthened the # samples and timeout to be 100 sec worth to avoid seeing these edge effects.

-Kevin P

[Henrik_Volkers]

---

@Jesse278 wrote:

Thanks for all your help! I've got one more idea before I start looking into adding some additional circuitry to perform this measurement.

I was looking at the analog window trigger mode, which will maybe work for my purposes. If I set the bottom and top to my 10% and 90% thresholds and trigger when entering the window, the analog comparison event will be a digital signal that is high while my signal is in that window. I could then use the counter to measure that pulse width to get my rise time. 

I tested it out with a different signal where I expected the window to be ~500 us and the counter seemed to measure it accurately, but when I tried to measure my 450 ns rise time, the counter reported 27 us instead. Perhaps it isn't accurate enough to measure such a small window?

---

A big question (as always, when it comes to shorter rise times) is signal integrity.

Cables, impedances, terminations ... 

A nice cheap puls source with 10MHz 50% duty cycle and <40ps(!) risetime

to fast for your 6363 .. but just in case you digg deeper 😄

[croohcifer]

---

A big question (as always, when it comes to shorter rise times) is signal integrity.

Cables, impedances, terminations ... 

A nice cheap puls source with 10MHz 50% duty cycle and <40ps(!) risetime

to fast for your 6363 .. but just in case you digg deeper 😄

---

Firstly, as I've stated many times above, no matter how fast the signal rises externally, the DAQ board may have internal low pass filtering that will attenuate the edges.  You could put as sharp a wave as you want into the DAQ board.  If it has a 500 kHz low pass filter, it doesn't matter how sharp the edge is.

Secondly, I think you're misunderstanding the problem.  The OP is not looking for a pulse generator.  The OP has a signal whose pulse width needs characterizing.  I'm not sure how recommending a pulse source is of any use in this conversation...

[Jesse278]

Thanks for all the responses! As suggested, I tested my code by injecting single square pulses to my system and I was able to verify that my code is measuring the pulse width as expected with the counter. When injecting a single burst, 1 MHz, 100 mVpp square wave with the analog window set to [0.01, 0.2], my expected pulse width is 500 ns and my code reported 530 ns.

However, when testing it with my signal of interest, it reports ~27 us. I've attached screenshots of my block diagram, front panel, and also my signal of interest. The circled part of the signal is where I am trying to measure the 10% to 90% time.