Why am I getting phantom signals with the counter?

[dav2010]

Hi, I am measuring period using the NI 9401 on a cDAQ9174 chassis.  I have a sensor whose output is 50mV LO, and 4500mV HI, and this is easily measured with a scope and DMM.  Also, the scope shows very clean transition, no noise near the 2.5V threshold for TTL.  The sensor is monitoring reflective pattern on a spinning wheel.  The period measurements are in the range of less than 0.3second, but, oddly, the period measurement seems to be fine for a few cycles, and then suddenly these values of nearly ZERO are observed. (Excel data shows these values literally "0".  What is this?  Where are these junk readings originating from?

Attached, see the code I am using to record the period data, and a typical example of the data, plotted in Excel.  One thing I am confused about is the timer in the WHILE loop.  How can the counter return a value that is smaller than the WAIT function setting in the WHILE loop?  The WAIT function is set to 100ms, but, the counter is returning values far less than 50ms.

Is there any way to remove these values in software?  For example, can I simply throw away any value less than 0.050second?  This kind of fix would be fine for our application; it's a bit crude, but, it would get me to the next stage in our project.

I greatly appreciate your input!  This photointerrupter is supposed to have the advantage of being a photo device, and be immune from environmental noise, the only noise in our environment so far is the small DC motor turning our wheel on our lab bench....not a rough environment at all.

Dave

[dav2010]

Sorry for the typo...the wait function is set to 50 ms, and it is returning period values of zero!

[Brian-G]

Hi dav2010,

The period measurements are stored in a buffer and the DAQmx Read function simply pulls data out of memory.  No matter the delay you set in the while loop, the Read function will stall until there are measurements available to read.  I think your problem is coming from the way you are using your Array Subset function.  I would simply try the following and see if this solves your problem.

Brian

[dav2010]

Hi Brian,

Thanks for the suggestion, but, the issue persists.  Take a look at the screen capture that shows WAVEFORM GRAPH for the first ~500 points.  I am still getting this pegging at ZERO that happens, and makes no sense physically.  It is impossible for my wheel to ever register such a short period.  Notice that the noise is not too bad when the period is about 100 ms, but, when I turn up the wheel speed to make the period about 75ms, there are tons of errors...lots of zeroes.  More zeroes occur when I speed it up further to 50ms periods.

Is it possible the 9401 counter that I have is defective and is producing these crazy results?  My code is attached here; I believe it matches yours.  My hardware guy and I spent HOURS this afternoon on our scope and we cannot find any noise like this anywhere in our circuit, and certainly not at our signal output, which is connected to the 9401.

Thanks,

Dave

[Brian-G]

Hi Dave,

I have run into similar issues as this doing counter measurements before, and the problem usually occurs when the signal undergoes a few high frequency switches before outputting a stable HI or LO.  If the signal switches on the same order of time as the internal timebase used to measure the period, its very possible to see 0 or near 0 period measurements.  To find if this is the problem, try to create a simple event counter task in DAQmx and run the fan at a known speed.  Match the number of HI pulses you should see over a certain time period with the count you get.  If the event count is significantly higher you are probably measuring preswitching oscillations in your signal.  This problem can often be remedied by ensuring that you have good connections between all of your terminals.  You can try disconnecting and reconnecting all of the connection points in your setup to make sure there are no bad contact points.

One more thing that might help narrow down the problem would be to use a different onboard counter for these measurements.  Also try to leave the maximum and minimum period terminals unwired so the measurement will run in the default configuration.

Brian

[dav2010]

Brian, the hardware was carefully checked, and tested with a scope, and the rise signal was very clean...we could not find any kind of noise or jitter.  Instead, I added a digital filter to the VI and that has solved the problem for me.

Dave

[Brian-G]

Hi Dave,

This is from the DAQmx Help file:

"The digital filter rejects state transitions that do not stay at a state for a specified amount of time. For example, for an edge counting measurement with digital filtering, the device does not count an edge if the pulse width is not at least the specified time. For digital input tasks, the device does not recognize that a signal changed from one state to another unless the signal remains at that state for the specified amount of time."

I imagine that the digital filter solved the problem by not counting transitions at very high frequencies.  MHz order oscillation may not have been detected with your scope, but I still think that this was probably the issue.  Regardless, I'm glad you were able to come up with a solution.

Brian

[dav2010]

Brian, this issue has been very confusing for me.  WE put a "write to spreadsheet" function into the VI to capture the period measurements, and what we observed is that the spreadsheet would list "0" maybe 10 in a row...so, how can the counter return "0" 's?  Even if the rise signal had some noise, it would show up as very short periods in the spreadsheet.   The rise time that the manufacture describes for the sensor is about 6 ns, so, how could the counter even sense noise on a such a fast rising signal? 

This is a very troubling statement:  ""For digital input tasks, the device does not recognize that a signal changed from one state to another unless the signal remains at that state for the specified amount of time."   But, what I observed is that it COUNTED the "0"'s and indicated them, both in MAX and using my VI.  This appears to contradict the statement offered in the help...how could it count rising edges that are associated with a period of ZERO duration?

My thing is working now, but, it would be good to understand why the "0"'s appear in the spreadsheet.  They are intermittent, follow no specific pattern.

Dave

[Brian-G · Accepted solution]

Hi Dave,

This is what I believe is happening here.  In the period measurement configuration of a DAQmx Counter Task, the signal source is wired to the gate of the counter and the internal timebase is used as the source.  When the input signal is HI at the gate terminal, a count is registered for every rising edge of the timbase at the source terminal.  When the gate signal goes LO the count is pulled from the register into the buffer and subsequent source pulses are ignored until the gate is HI again.  

Now let's assume that your gate signal was oscillating very quickly before staying at the HI or LO state.  Every time that a HI to LO oscillation occurred, a count would be pulled from the register of the counter.  If this rise and fall of the gate happened fast enough it is quite possible that very few or none of the timebase pulses were actually counted at the source terminal, thereby registering an extremely small double value in the computer's buffer.  When these series of values were pulled from the buffer and written to the spreadsheet, the precision of the Write to Spreadsheet VI may have been set to the default 3 decimal places, therefore writing "0"s to the file.

The speed of the oscillation may be on the order of 10-100 ns, fast enough for your scope not to register.  The quote that I copied from the help file describes the behavior with the digital filter enabled.  When you apply the digital filter, a count is not pulled from the register unless the gate signal stays HI for a set minimum amount of time.  With the filter, the 0 period counts are not sent to the buffer because the gate is not HI for the minimum time period. 

Brian