Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-6216 intermittent zero voltage

I am using a USB-6216 to sample a low-voltage (+/-3V) differential signal.  I am occasionally, and unpredictably, seeing a strange pattern on multiple channels that I thought someone might recognize as symptomatic of a particular problem with the DAQ:

 

ekgsignalsmall.jpg

 

 

This is about 5 seconds of data, sampled at 1kHz differential, so the intermittent jumps to 0V are each on the order of "ten to hundreds of milliseconds".

 

The source signal is continuous; a scope shows that the intermittent jumps to 0V are not present in the source signal.  But more importantly, when I change *nothing* about the source hardware and sample instead on a 9206 through a cDAQ-9171 *or* a USB-6009 (yep, I have three different DAQs on my desk :)), plugged into the *same* breadboard and the *same* USB cable on the *same* PC, this pattern never emerges.  This makes me concerned that this is a problem with the DAQ.  I see this pattern (when it happens, which is maybe 5 out of every 60 seconds) on multiple channels, which rules out things like "the wire is loose" (although it doesn't really look like that anyway).  The device is not moving around.

 

Does anyone recognize this as symptomatic of a particular underlying hardware issue?

 

Thanks!

 

-Dan

 

0 Kudos
Message 1 of 4
(3,234 Views)

What's the code look like that is creating this data?  Is it possible that there's some kind of error or you are getting a padded array (array with zeros to make up for samples that aren't present)?

Chris
Certified LabVIEW Architect
Certified TestStand Architect
0 Kudos
Message 2 of 4
(3,214 Views)

I can't quite come up with a software-side explanation: some of the gaps are just a few samples, much smaller than a single buffer (e.g. a few chunks of ~10 zero'd samples in the same 200-sample buffer).  Also - not evident in the graph I posted - the "missing samples" are not *exactly* 0V, they're just very close.

 

That's not to say it's impossible that it's a software-side issue, but it's unlikely... FWIW the code is based nearly verbatim on the "Cont Acq-Int Clk" sample.  Highlights include:

 

DAQmxCreateTask(...)

DAQmxCreateAIVoltageChan(...)

DAQmxRegisterEveryNSamplesEvent(...,DAQmx_Val_Acquired_Into_Buffer,...)

 

The buffer size is 200 samples @ 1kHz (so I'm getting data every 200ms).

 

In the data callback, highlights include:

 

DAQmxErrChk (DAQmxReadAnalogF64 ( ... ) )

 

...and I check the actual number of samples read (the second-to-last parameter of DAQmxReadAnalogF64) to make sure I'm not getting partial buffers.

 

I take it this doesn't look like anything folks have seen as familiar hardware issues?  Like "oh, yea, you must have fried the [insert thing we must have fried]".

 

Thanks!

 

-Dan

0 Kudos
Message 3 of 4
(3,198 Views)

Hi dmorris,

 

Could you do some frequency analysis on this signal to see if it is at a certain frequency? I want to see if there is some kind of grounding issue where you might be getting line noise. What is the output signal supposed to look like and what is the range of that picture you posted? 

 

-KP

Kurt P
Automated Test Software R&D
0 Kudos
Message 4 of 4
(3,174 Views)