LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sampling rate - too much data points

Solved!
Go to solution

Hello community, 

 

I am running a pressure force sensor signal on DAQmx using labview 2014. My rate from the hardware timing function is 50 KHz. The samples per channel for timing and read vis are the same set at 5 Khz while the channels are set to continuous sampling. The problem that I encounter is that when i run labview for a couple of seconds, say 5 seconds, I am getting half million of data points. I tried to run it for 10 seconds and the points were more than a million where its hard to do the analysis. I think the vi is generating too much data points and the buffer is large. Am I right? Can you please help me solve this problem?

 

Kind regards,

Mike

 

aa.png

 

0 Kudos
Message 1 of 17
(7,896 Views)

Can *you* make out any details in that blob?

0 Kudos
Message 2 of 17
(7,884 Views)

Just to help with the examination of your code can you attach a snippet of your code or the VI? If you have information that you don't want to share than you could create a simplified version that represents the same problem.

 

How many channels are you running? From the look of your code it seems that you are going to be extracting the full 50k samples a second given that you have no timing control in your loop, so you will simply wait until you have the 500 samples in your buffer and then present those to the graph and repeat.

 

How many samples are you trying to get if the half million or million is too many? This shouldn't really be too many if you are going to perform any sort of smoothing or processing to your recieved signal.

 

What makes it too hard for analysis with this many samples?

Do you have any logging or processing that is not presented in your picture?

0 Kudos
Message 3 of 17
(7,865 Views)

What can you say about the "signal" (the values from your sensor) that you are recording?  Specifically, how rapidly does it change?  A "rule of thumb" is you should sample about 10 times faster than the highest frequency you expect in your signal.  Do you expect the pressure change has significant power at 5KHz?

 

One way of cutting down the number of data points is to sample at a lower rate.  If the pressure changes take milliseconds to occur, then you could probably get away with a much lower sampling rate (1-5KHz, perhaps lower).

 

Bob Schor

 

P.S. -- I'm not going to go on my usual rant about attaching code, not pictures of code.

Message 4 of 17
(7,842 Views)

Hi users :). 

 

Cheers for getting back to me. I am using two channels for pressure measurements. Indeed, the extraction will be 50000 points per second and the more samples the better for processing the received signal. I do have a logging but I want to check the rate and points, then logging comes. The trial test last for approximately 4-5 seconds, but the change is within milliseconds with the pressure sensor and I want to extract as many samples as possible but not overflow the buffer (well, this would be possible for finite acquisition). I am aware that I need to extract some points in the read vi from the buffer on the timing vi. Is there any relationship between the sampling rate and samples per channel as I specified 50000 Hz for sampling rate so to specify 5000 Hz for the samples per channel for read and timing vis?

After I do the test, I will do some fft analysis to check the signal components. Attached is the vi. 

 

Kind Regards, 

Mike

 

0 Kudos
Message 5 of 17
(7,801 Views)

Basic question: How fast do you NEED to sample your signals?  (Bandwidth of the sensor, dynamic range of your signal?)

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 6 of 17
(7,787 Views)
Solution
Accepted by topic author MikeCamer

You are now ready to learn some of the power of LabVIEW and DataFlow Programming.  LabVIEW is an inherently parallel language -- two loops can run independently and in parallel, allowing you to do time-sensitive (like data sampling) and time-intensive (like data logging and plotting) at the same time, using queues to pass data between the loops and provide the necessary buffering.

 

If you open LabVIEW and click on the File menu on the tool bar, then select New ... (the dots are important!), you will have the opportunity to Create New (VI) From Template.  Choose Framework, Design Patterns, Producer/Consumer Design Pattern (Data).  This is what you want to do.

 

You basically set up a "pure DAQ Acquisition Loop" (without TDMS logging) as the Producer, creating 5000-element Arrays of data every tenth of a second (if you are sampling at 50KHz).  You create a Data Queue outside the Producer Loop whose elements are a 1D Array of Waveforms (the output of your DAQmx Read) and instead of sending the data to a Waveform Graph, you put it into the Queue.

 

You have, below this loop, a parallel loop that gets the same Queue and dequeues elements.  This loop will sit idle (taking no CPU time) until data is enqueued.  It then dequeues it, displays it, and saves (logs) it into a TDMS file.  Incidentally, you should open the TDMS file before entering this (Consumer) loop, write to the file inside the loop, and close the file when the loop exits.  Study the example in the VI you create with the Template and you'll see how this works.

 

The beauty of this is that you can certainly "keep up" with writing data points to a TDMS file at 50KHz.  You might not be able to display all of those points, but there's nothing to keep you from processing the data (by, say, decimating or "block averaging" it) to make a more "human-friendly" display (can your eyes "see" a 50KHz signal?) -- you've got a whole 100 msec to work with before the next packet comes in from the Queue.  Also, note that the Producer loop probably takes very little CPU time -- most of the time the hardware is waiting for its clock to "tick", gathering points in a buffer, then transferring it to the loop.

 

Now you can Have your Cake and Display It, Too.

 

Bob Schor

0 Kudos
Message 7 of 17
(7,775 Views)

Hi users, 

 

I definitely need to sample the acquisition at 50kHZ. Bob_Schor you mentioned for a pure daq acquisition loop to create 5000 element arrays of data every tenth of a second in the DAQmx Read vi. Why samples per channel not to be of the same value in the DAQmx Timing vi as below? Can you clarify to me the difference of assigning 5000 Hz in the DAQmx Read vi and not assign 5000 Hz in the DAQmx Timing vi (Not the rate)? The DAQmx Read vi is used to get the data from the buffer. 

 

aaaaa.png

Cheers. 

0 Kudos
Message 8 of 17
(7,705 Views)

Your system will sample at the 50kHz that you set in your timing configuration.

The 5000 that you are setting for your read is not a 5000Hz simply 5000 readings.

So 5000 Samples / 50000 (Samples/Second) = 0.1 Seconds to read in your 5000 readings.

0 Kudos
Message 9 of 17
(7,696 Views)

Do not attach pictures -- I can't see anything on my laptop (it is too tiny).  Attach the VI.  I need to be able to see the code to make comments on the code.

 

Bob Schor

0 Kudos
Message 10 of 17
(7,670 Views)