What happens you sample at a higher rate than your card is designed for

[LSUgrad85]

I'm using a 6251 card using the 16 inputs in differential mode. I'm sampling at about 78 kS/s, which is nearly 1.25 MS/s for 16 channels. This was a mistake before I understood in multiplexed mode you can only sample 1 MS/s. I don't get an error message... so In differential mode, do you not actually sample each channel? Do you just sample each differential group? If so, is it important for the differential input to have ground connected?

[Dennis_Knutson]

When you select differential mode, you have only 8 channels as mentioned in the manual and specs. You would only specify Dev1/ai0:7. The driver takes care of everything else.

What gnd are you talking about and what pins are you thinking about connecting to it?

[LSUgrad85]

Thanks, sorry I missed that. I try to read the manual before asking questions.

The ground I'm speaking of is the one when you use differential output coming from a speaker. So you've got two hot wires (one negative and one positive) and a ground wire. I currently do not have the ground connected. Would it be wise to or does it make a difference?

[Dennis_Knutson]

I've never connected to speakers but I don't think you would use the ground.

[LSUgrad85]

All channels but one work more or less fine without the ground. If you normally don't use ground in differential input (though most diagrams show it), then I won't worry about it.

To be more specific, we're amplifying accelerometers through a couple amplifiers before hitting the DAQ, the last of which is an audio amplifier which is what I meant by speakers. That was unclear (and is probably still a little fuzzy).

[HeatherBaker]

Hi LSUgrad85,

The 6251 has one ADC which means there is one AI sampling rate, i.e. 78 kS/s, configured for the board.  A multiplexer (mux) is used to scan through the channels to take a measurement.  This board is a member of the M Series family and has a diagram in the M Series User Manual that may help explain the circuitry.

The maximum sampling rate for the 6251 is 1.25 MS/s for a single-channel; however, acquiring from multiple channels is 1 MS/s (aggregate).  If you were to configure a task with a sampling rate above these values, then you should receive an error.  Quality of data acquired by operating any hardware beyond the specifications cannot be guaranteed to its accuracy, resolution, etc.  Hopefully this helps!

[LSUgrad85]

This is different from the original question, but in the same vein. When I upped my sample rate to 100kS/s, and am recording 1000 samples on 8 differential channels, the computer often crashes to a blue screen of death, saying something has happened with the hardware and to contact the vendor. This has never happened at 78kS/s recording 780 samples (ideally .01s, for any setup). Naturally I'd like to sample at the highest sample rate I can afford (account for things in the manual like impedance and settling times). I think it always crashes at 120kS/s (1200 samples, 9600 total).

I don't know much about the hardware, but I immediately consider a buffer issue. I don't know enough from the spec document to understand it (the 4095 FIFO buffer and the 4095 scan list memory). I'm sort of assuming the maximum number of samples you can take in a short period of time is 4095, but I don't know.

It's worth mentioning that I stack the data 100 times and have between 40 and 140 ms between each stack and it writes the data to the same file between each stack.

[Seth_B.]

The DAQmx driver shouldn't allow you to do anything that leads to a BSOD.  Which version of the driver are you using?  Also, could you get a kernel memory dump and post it for our developers to look at?

[HeatherBaker]

Hi,

I would also recommend running one of the DAQmx examples without modification at the 100kS/s to narrow down the issue to hardware, software, or system.  In the analog measurements examples, I would look at Con Acq & Graph Voltage- Int Clk for all 8 channels, i.e. dev1/ai0:7.  If the BSOD behavior does not occur, then look at what is different in your code to narrow down the cause of the behavior.  The FIFO buffer is the onboard memory where data is held until it is transferred to the PC.  The M Series user manual elaborates on this topic.