National Instruments DAQ Attack


They say no plan survives contact with the enemy.  I think that pearl of wisdom applies to engineering.  In my experience the enemy takes the form of everything with wires as well as software running on anything with wires.
It certainly applies to a project we’re currently working on.  We can’t go into too much project detail, as the design is part of a contract we’ve been hired to complete. But we can cover some of the broad concepts that describe the battle we just survived.

This project requires the measurement of 8 analog signals in rapid sequence.  We determined that measuring the analog signals every 500-1000nS was in the ballpark of what we needed.  Measuring the samples simultaneously was also necessary.  On top of all of that the samples had to be accurately timed from our analog trigger.  We were able to locate a National Instruments Data Acquisition system (NI 6366) whose specifications seemed to meet our requirements.  Here’s a rather long, and boring, video related to the DAQ… enjoy.

Seems pretty straight forward.  Connect some stuff, write some software, head out for some beers with the project completed.

Obviously, for our project the really important (and tough) parts were measuring 8 signals about 900 times every millisecond, keeping those signals referenced to an analog trigger, and getting that data to a PC for processing.  We were a little hesitant in using the USB version of this DAQ system, but National Instruments claimed this device had enough throughput.

The original plan was to trigger on an analog signal and take the measurements at every trigger.  We ran into two issues with this approach.  First, the National Instruments driver introduces a delay when you restart what are called “finite” acquisitions.  When we configured the DAQ to read 900 samples (each sample being 8 analog measurements) each time the analog trigger occurred it would throw in 10-20mS of delay.  That meant we were getting our measurements around 50 times per second (50 * 900 samples * 8 channels = 360,000 voltage measurements per second).  That’s a lot of data, but unfortunately 20 times too slow.

We were able to increase the rate of measurements by running the analog acquisition in “continuous” mode.  Unfortunately our analog trigger signal is not steady (it’s generated by machinery outside of our control).  After the first 900 samples the data was junk, as it couldn’t be associated with the timing of the analog trigger.  At this point we had to get into the technical weeds of the NI 6366.  It was determined that we had to run the analog samples as a continuous acquisition to get the speed we wanted.  But we had to somehow associate those samples with the analog trigger.

Here’s how we did it.  First, we converted the analog trigger to a digital voltage.  Then we programmed the NI 6366 to generate a series of pulses when it received a digital trigger (the modified analog trigger).  This uses the DAQ’s counter function, which can be set to be re-triggerable with a digital trigger.  In essence this programming caused the DAQ to output 900 pulses (1uS period) each time the analog trigger occurred.  The final step to make this work was to program the pulse output from the counter to be our analog sample clock.

Now we had a continuous analog acquisition that sampled 900 times after each analog trigger.  The sample clock was associated with the analog trigger via the counter, and the continuous analog acquisition was delay free.  Using this method we can take about 1000*900 samples of each analog channel each second.  Or 7,200,000 samples per second.  And that data seems to get through to the PC via the USB interface.

While we’re not out of the woods yet, we were able to tackle the first of this project’s major hurdles.  It just took a little adjustment to our original plan.


  1. Nice blog post. I Really like the way you are posting here. I get so much information fom this blog post.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.