Measuring short (faster than the clock) pulse width fails with NI DAQ USB 6363

[Yomach]

Hello,

I'm using NI DAQ USB 6363 with C++/Matlab.

I'm trying to do a pulse width measurement with a known finite sample size (on the order of 2000).

The problem is that some of these pulses might be very short, shorter than my clock.

I would like the DAQ card to simply report those pulses with width 0 and I know it works with other NI DAQ cards that some of my colleagues use.

However, for me, it simply returns an error saying that not all of the samples have been received.

I've searched the help but couldn't find anything about it...

Is it some configuration that can be changed?

If not, can anyone recommend me another similar DAQ card in which it works?

Thanks in advance.

Yoav

[Yomach]

Hello,

I'm using NI DAQ USB 6363 with C++/Matlab.

I'm trying to do a pulse width measurement with a known finite sample size (on the order of 2000).

The problem is that some of these pulses might be very short, shorter than my clock.

I would like the DAQ card to simply report those pulses with width 0 and I know it works with other NI DAQ cards that some of my colleagues use.

However, for me, it simply returns an error saying that not all of the samples have been received.

I've searched the help but couldn't find anything about it...

Is it some configuration that can be changed?

If not, can anyone recommend me another similar DAQ card in which it works?

Thanks in advance.

Yoav

[Kevin_Price]

It sounds like you might be encountering a side-effect of the DAQmx channel property called "duplicate count prevention."   I never particularly liked that name for the property but can't say I have a better one in mind either.

It can be set for either True or False, though I believe I recall that the exact behavior may sometimes also depend on the specific family of timer being used (DAQ-STC, NI-TIO, DAQ-STC2, DAQ-STC3).

You should be able to find more help now that you know the otherwise-unguessable phrase to search for.  Meanwhile, I would simply drop the property in my config call chain along with a boolean control to change the setting so you can experiment and observe.  You can find the property using a DAQmx channel property node and navigating to:

Counter Input->General Properties->More->Advanced->Duplicate Count Prevention

-Kevin P

[Yomach]

Hey Kevin,

Thanks for your help.

I was half familiar with that property, but not to it's exact function, thanks for pointing me to it!

In our code it is set to 1, so it should work.

However, it does seem like this property does not work properly...

Moreover, when we try to set it to 0 we get the following error message:

Error -200077:Requested value is not a supported value for this property. The property value may be
invalid because it conflicts with another property.

Now this is weird... The values supported should be 0 or 1, so maybe something is messed up?

Any ideas?

Thanks!

[Kevin_Price]

Sorry, no specific ideas.  I've never used your particular board and have only used the DAQmx functions in LabVIEW, not the direct driver dll function calls you'd be using in C++ or Matlab.

FWIW, I did a quick experiment with a simulated device and saw the same error regardless of whether I simulated a USB-6363 or a PCIe-6363.  Intrigued now, I just did some more poking around the site.

According to this post, the X-series devices don't support the ability to set that property.  They are said to behave in a manner consistent with having the property turned ON though, so it seems to me like you should be able to measure 0 values when you get pulses that "hide" between active clock edges.

Can you post your code and the exact error number/msg you mentioned in your original post?  Your description of the message sounds like there could be a different problem going on.

-Kevin P

[John_P1]

As a workaround, you could configure an edge count task.  The clock signal would be configured as the source for the edge count task, and the signal which is having its pulse width mesured would be configured as the sample clock as well as the pause trigger.  

The main difference is that the counter value wouldn't be reset on every period (there is a count reset terminal as well, but I'm not sure offhand if you can use it alongside a pause trigger).  So to compute the period (in ticks) you would read back the data as U32 and subtract the current count from the previous count (rollovers will be OK as long as you have a sample at least once per 2^32 clock cycles).  If you want, multiply the result by the period of your signal to obtain the value in seconds.

EDIT:  It would be worth getting additional information as well... how short are the periods you are trying to measure for example?  The workaround might not actually be necessary.

Best Regards,

[Yomach]

Hey,

Interesting...

Our exact setup is as follows:

We have a single photon counter connected as the clk signal, it produces pulses with a width of about 20-25ns.

We use it in a pulse width measurment with a gate signal that can be anywhere from 300ns to 1ms.

The error we get is -200284: "Some or all of the samples requested have not yet been acquired."

The code is more or less as follows, I think it's pretty understood and all of the variables have clear names, so it should be clear what they do.

'N' can vary, but lets say it's a 1000.

'DAQmxSet' is a function we wrote that basically calls the relevant set function and checks for errors, nothing fancy.

[ status, ~, task ] = DAQmxCreateTask([]);
DAQmxErr(status);

status = DAQmxCreateCIPulseWidthChan(task, device, '', 0.000000100, 18.38860750, DAQmx_Val_Seconds, DAQmx_Val_Rising, '')

DAQmxErr(status);

status = DAQmxCfgImplicitTiming(task, DAQmx_Val_FiniteSamps , N);

DAQmxErr(status);

DAQmxSet(task, 'CI.CtrTimebaseSrc', device, '/dev1/PFI8');
DAQmxSet(task, 'CI.PulseWidthTerm', device, '/dev1/PFI0');
DAQmxSet(task, 'CI.ResetDupCountPrevent', device, 0); %(We added it to check, doesn't change anything)
DAQmxSet(task, 'CI.DupCountPrevent', device, 1); %(Doesn't matter in this device)

numSampsPerChan = N;
readArray = zeros(1,N);
arraySizeInSamps = N;
sampsPerChanRead = int32(0);%libpointer('int32Ptr',0);

[status, readArray, aux]= DAQmxReadCounterU32(task, numSampsPerChan,timeout, readArray, arraySizeInSamps, sampsPerChanRead );
DAQmxErr(status); %This is the failing line.

It's also worth noting that this code works on other DAQ cards 😕

We also have both the BNC version of the 6363 and the regular one, we get the same results in both.

John, Thanks for the suggestion, we might resolve to doing it, but we prefer to tackle this problem as it seems it should be solveable. We've also contacted NI represntatives but so far we havn't got anywhere.

I'm written the parameters you asked for above, We're trying to measure widths that go down to about 300ns, but we see these failures at 0.5ms as well...

Thanks!

Yoav

[Bellissima]

Hello Yoav, 

Since what you are trying to do isn't technically supported, I wouldn't expect it to work 100% as intended.  I would suggest attempting the work-around first, and then continuing if that doesn't work.  

Best wishes!

[Kevin_Price]

I'm wondering if I derailed this thread with a too-quick leap into discussion of Duplicate Count Prevention...

While the property itself isn't writable on the X-series boards, the default behavior sounds like it should allow you to get meaningful data during those intervals where there are consecutive gate edges with no source edges in between.  Winding all the way back to the beginning (oh wait, using terms like "winding" kinda gives away that I grew up when media came on tape...), the error message you're getting has other possible (and generally more common) causes.

Error -200284 is a read timeout error.  Let me try to eliminate some other suspects before zeroing in on Duplicate Count Prevention so quickly this time.

What is the value of your 'timeout' variable?  Are you sure that 'N' pulses are being generated within that time period?  Can you run an experiment where you loop over the read call, but only request 1 sample each time?  Or lengthen the timeout value considerably?  Or temporarily configure for continuous sampling and do a read that requests "all available samples" (in the LabVIEW API, this is designated with the magic # -1).

You could/should also try John P's suggestions about configuring a different kind of counter task where the roles of the two signals get reversed.  It may take a moment to wrap your head around viewing the problem kinda inside-out, but you'll see that you'll be able to produce the same data,  you just get there a different way.  It's easiest to work out the change in perspective if you think about counter tasks in terms of edges and ticks.

-Kevin P

[Yomach]

Bellissima, 

Not sure what you mean by the fact it's not supported, I saw several threads with people doing exactly that...

For the mean time we did implement the workaround, but we have another case where it will not work, so we prefer to try to tackle the main problem.

Kevin,

Unfortunately, We ruled out the timeout already...

We have it set to about 5 times longer than it should take, and we tried playing it.

If we set it to continuous or just try to see how many pulses we get, we can clearly see that we only get some of the pulses.

By doing a separate edge counting measurement, we can see that all of the gate signal are getting there really fast.

We can simplify the problem:

Trying to read a single pulse (gate) when there is no clk signal should give a count of 0 and should not fail, but it does...

Any other thoughts? 😕

[natasftw]

People doing something doesn't mean it is a supported behavior.

Here's an example.  Apple makes the iPhone.  Many people jailbreak these iPhones.  Jailbreaking my cause unexpected quirks due to using the device in an unsupported way.  That doesn't mean it isn't possible to jailbreak or to use it in ways other than the supported ways.  It just means you're trying something the device wasn't really intended to do.  When you enter into this realm, you should expect quirks and shouldn't expect it to perform the same in every example.

An example using NI, there are some versions of software that aren't supported on 64-bit Windows 7.  Sometimes they install and users can take advantage of them.  Sometimes they don't.  It's hard to say what exactly changes the success to failure. 

That's all she was saying.  Expect quirks.