Showing results for 
Search instead for 
Did you mean: 

How to improve a real high frequency acquisition by USB-6000

Go to solution


I've created this VI that perform a spectral analysis of a 0-1000 Hz sinusoidal signal.

In the "simulation" all works as espected with a very fast response to frequency (manual) changes:


Than I've modified the VI connecting it to a real signal (generated by means a real function generator) and acquiring the signal by means an USB-6000 interface and DAQ Assist and configuring the new VI with the same number of sample (10000) and the same rate (10000 kS/sec).


This real VI, however, is more slow and more inaccurate than the Simulated VI and don't seems to works in the same, reliable, manner.

The question is:

is the hardware inadequate or are there any settings than may I change to make the "real" VI working as the "simulated VI"?

And if the HW is inadequate to wich parameters must I look to purchase an "adequate" acquisition HW?

Thanks in advance 







0 Kudos
Message 1 of 8

LabVIEW uses the Principle of Data Flow.  Among other things, this means that a Loop cannot iterate until every function inside the loop has run.  Furthermore, you have two Express VIs (boooo!!) connected in series (naturally, because the FFT requires the data from the Dreaded DAQ Assistant), which means that the first loop will take 1 sec (for the DDA) + however much time it takes to process 10,000 points (should be fast, but with an Express VI, who knows?  It certainly won't necessarily be "express").


Two recommendations:

  1. Spend some time learning DAQmx.  There are excellent NI Tutorials and White Papers out there.  My favorite is "Learn 10 Functions in NI-DAQmx and Handle 80 Percent of your Data Acquisition Applications" (or words to that effect).
  2. Learn about the Producer/Consumer Design Pattern (a Template for this is built into LabVIEW).  This lets you run the Acquisition (Producer) in one loop and have a simultaneous second Consumer loop processing the data (say, doing an FFT).
  3. One more recommendation (for free) -- there are excellent VIs in LabVIEW that do FFTs without requiring an Express VI.  As you do the first two steps, I also recommend you learn about the data type LabVIEW calls a Waveform, made for sampled data, and far superior to the Dynamic Data Wire (that black-and-white checkered Wire on your Block Diagram).

Also, next time attach your VI.  There may be other errors "buried" inside your Express VIs that we can't see in the picture.


Bob Schor

0 Kudos
Message 2 of 8

Hi Bob, thanks for your fast reply.

I'll follow all your suggestions and I'll let you know.

Attached to this reply is my VI.

Kind regards.


0 Kudos
Message 3 of 8
Accepted by topic author mforbiz

Thank you for attaching your VI.  I was worried that, as a beginner using the Dreaded DAQ Assistant instead of DAQmx, you might have chosen (as I can now see you did!) to set the Acquisition Mode to "N Samples".  You are sampling 1000 points at 10 kHz, and then passing the data to the FFT.  So let's look at what happens:

  1. The Express VI tells DAQmx to collect 1000 points at 10 kHz and then stop.
  2. 100 msec later, the Express VI loads the samples onto the Dynamic Data Wire.
  3. Essentially instantaeously, the data are passed into another Express VI to make Spectral Measurements.  Let's say this take 2 msec (it might be much faster, I'm just "making up numbers").
  4. You then plot the results on a Graph, which maybe takes another few, say 3, msec.
  5. You've now finished the Loop, and can go back and run it again.  The total elapsed time in the loop is 100 + 2 + 3 = 105 msec.
  6. You now tell the Dreaded DAQ Assistant to take another 1000 samples.  It does, skipping any samples that it didn't take during the 5 msec of additional processing that occurred in your loop.

Do you see the problem?


The alternative to N Samples is "Continuous Sampling".  This means that the underlying DAQmx is told (in effect) "Take 1000 Samples.  As soon as you have them all, output them and start taking the next 1000."  Does this make a difference?  Let's see ...

  1. DAQmx is told to take 1000 samples "Continuously".
  2. Let's say this is the first time through the loop -- the data will be output 100 msec after DAQmx Read finishes and the Data are presented (using the Dreaded DAQ Assistant will be slightly slower because it has to "fuss" with the Dynamic Data Wire).
  3. You do some Spectral Analysis and make a plot.  Unfortunately, this is dreadfully slow, taking 50 msec (I'm changing the assumptions to make an important point).
  4. You finish the loop (having taking 150 msec) and start the next loop.
  5. When the Loop starts the second time, DAQmx has been acquiring samples at 10kHz for 50 msec, so in another 50 msec it will finish collecting all 1000 samples.  It will output all the samples and start on the next acquisition.
  6. You do the additional processing (which takes another 50 msec) for a total loop time of 100 msec, with all the data Present and Accounted For.
  7. You continue acquiring and processing data, with no data loss, until you decide to stop.

Note that the key point is that the processing step must complete before the (next) acquisition step finishes.


Bob Schor

0 Kudos
Message 4 of 8

Hi Bob.

A lot of stuff !

I'll study it and then update this thread with my experiences.

Thanks a lot

0 Kudos
Message 5 of 8

Hi Bob !

I've an update.

I've re-create the VI using normal VI instead Express VI:


The real issue is that when I set sample rate (i.e. 1000 kS/s) equal to # of Sample (i.e. 1000 sample), the refresh rate is equally the same ( 1 sec and than too slow).

The reason because I must set the sample rate = to # of Sample is to prevent the scattering (see this post:


Any idea?

Thanks in advance.

P.S. attached is the new VI

0 Kudos
Message 6 of 8

Thanks.  I found two minor errors -- you originally took 1000 samples at 10,000 Hz, but here you do 1000 and 1000, so I changed it back to 1000 samples at 10kHz.  Second, the FFT plot should (initially, at least) have the X and Y axes set to "Auto-scale" -- who knows what the values really should be.


Now, I don't have a DAQ device (nor signal generator) to test this, but in the true Spirit of LabVIEW, I build a "Dummy Signal Generator" and connected it to my "Dummy A/D" that samples at 10kHz for 1000 samples, taking 100 msec to do so, and fed it to your analysis routine.  It runs just fine, all the Graphs plot (showing we can update the plotting at 10 Hz), and the numbers seem to be reasonable.


Here's the code, in the form of a Snippet (I'll attach the actual VI, as well).

Sim USB-6000 Acq.png

The first While Loop simulates an A/D converter sampling 1000 samples at 10kHz, requiring 100 msec to run (look for the numbers 1000, 10k, and 100).  The Function Block is on the Waveform Palette -- it serves as the Function Generator for "Tones and Noise" -- two Tones at 200 and 433 Hz, amplitudes 1 and 0.3, and RMS noise of 0.2.  So every 100 msec, this function generates 1000 points, as though it were an A/D connected to known (but noisy) signals.  So then what?


So I'm a great fan of Asynchronous Channel Wires, which allow you to send Data across ("asynchronous") the boundaries of LabVIEW Structures.  You can think of them as re-packaged Queues.  The gadget getting the output Waveform from the "A/D" is a Stream Channel Writer -- it packages the data and sends it out of this While Loop and into the next one by means of a "Magic Pipe".  It also has some additional inputs, one of which is "Last Element?", to which I wired the Stop button so that I can stop the A/D.


The next While Loop has the corresponding Channel Reader, whose output will be the data that was place in the corresponding Channel Writer (i.e. from the A/D).  The rest of the processing is just your FFT and two plots.  The Channel Reader also brings over the "Last Element?" signal from the first loop, so when I stop the first loop, it sends the "Stop" signal to the second loop, and everything stops.  Note that if we slow down the first loop (say, by changing the Wait time to 1000), the second loop will "slow down" too -- it cannot run unless the Channel Reader has been given some data, so Loop 2 gets "clocked" by Loop 1.  [I should point out that it can run slower however -- try putting a 200 msec Wait in the second loop, run for a few seconds, and press Stop.  See if you can explain why the program "seems" to have ignored the Stop (Extra Credit)].


You might have heard of the "Producer/Consumer Design Pattern" -- that's exactly what this is, two independent loops running asychronously in parallel, with a data communication path such as a Queue or Channel Wire that "sneak past" the boundaries of the LabVIEW Structures.


So fix up your original code, and try it out.  It should work.


Bob Schor

0 Kudos
Message 7 of 8

Hi Bob.

Sorry for delay.

I've thoroughly studied and tested your suggestions.

I think the your better suggestion is related to the use of normal VI instead of Express VI regarding the DAQ VI.

In fact as you can see in the following video, even using 10000 sample at 10 KHz, I've a satisfactory fluidity and a fast response in the Spectrum Analysis (that is what I was looking for😞


This is very similar to a fully simulated instrument like this:

Using the stream channel (that is a very interesting thing) the results don't changes significantly.

I've very appreciated your help and your suggestions and I thanks you.

Best regards



0 Kudos
Message 8 of 8