LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem in time discrepancy while acquisition of data at 2.5KHz with multiple sensors

Solved!
Go to solution

I'm having a problem while acquiring the data at 2.5kHz of sample frequency as my real time doesn't match with time which is shown on the graph. Can someone please guide me? How to match these both timings in the below images attached. For example I'm running my experiment for 100 seconds but it is collecting (showing) the data for around 50 seconds on the x-axis of the graph.

Could it be a problem of software collecting capability at high rate or is there any other possible configuration that I can opt for?

Thanks in advance.

Tom147_0-1655115655827.png  

Tom147_1-1655115686571.png

 

 

0 Kudos
Message 1 of 9
(2,247 Views)

What module are you using to sample this data?  There are modules that have a minimum sample rate.  So even though you are trying to set it to 2.5kHz, the actual sample rate is 5kHz.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 9
(2,227 Views)

Additionally, I *highly* recommend that you do your DAQmx Read calls as N Channel N Samples instead of reading only 1 sample at a time.  Typically, things work well when N represents 1/10 sec worth of samples -- which is what you get when you divide the sample rate by 10.  Take heed of crossrulz' advice about actual vs. requested sample rate though.  I'd also recommend adding a DAQmx Timing property node to query the sample rate right after the call to DAQmx Timing.  That will confirm the actual sample rate of your task.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 9
(2,210 Views)

Chassis NI SCXI 1000

Module SCXI 1102B

Terminal Block 1303 

NI DAQ card PCI 6024E 

 

0 Kudos
Message 4 of 9
(2,201 Views)

@ and @ thanks for your availability. 

I'm trying with N samples and the discrepancy is gone. 

1. Can you guide me in saving data at the required frequency (2.5kHz) please?

2. Can you please let me know how this "number of samples per channel" is affecting my data (for example I'm taking 10000 samples per channel are these the total number of samples collected during the overall time or these are the samples collected at each 0.0004 seconds (that is given by 1/2500Hz)?

Tom147_0-1655131901395.png

Download All
0 Kudos
Message 5 of 9
(2,198 Views)

1. Can you guide me in saving data at the required frequency (2.5kHz) please?

I'd recommend you use the built-in DAQmx logging feature.   It's pretty simple to set up, as you can see in the shipping example for continuous voltage input.

 


2. Can you please let me know how this "number of samples per channel" is affecting my data (for example I'm taking 10000 samples per channel are these the total number of samples collected during the overall time or these are the samples collected at each 0.0004 seconds (that is given by 1/2500Hz)?

Actually it's neither of those.  In the call to DAQmx Timing, 'samples per channel' is mostly related to the size of the task buffer DAQmx should create.  However, in the case of continuous sampling, this value is often ignored and DAQmx will use a default instead.  Shipping examples for continous sampling tasks typically don't even wire this up.

    By its very nature, a continuous sampling task is used when you do not know in advance what total # samples you want to collect.  You run the task indefinitely, until some condition indicates that it's time to stop.

    When sampling at 2500 Hz, DAQmx captures 1 sample per channel every 0.0004 sec and delivers them to your task buffer.  This happens in the background.  You bring those samples into your app by calling DAQmx Read and specifying 250 as the 'number of samples per channel' (according the the rule of thumb I mentioned previously) to retrieve from the buffer.

 

This dual use of 'samples per channel' has long been a source of confusion in threads about DAQmx tasks.

 

-Kevin P

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 6 of 9
(2,174 Views)

Hello @  Many thanks again for the response.

1) I have implemented as you suggested the Data Logging as you can see in the following picture only the y-axis results (sensors data). REFER Figure 1.

2)Is it possible to write the time (1/rate) on the first column in the saving file as shown in the attached document? REFER Figure 2.

3) Is there any possible way to save the data directly from the graph after clicking the stop button automatically?

 

FIGURE 1 

Tom147_0-1655199058432.png

 

FIGURE 2 (this data is exported directly from the graph to Excel)

Tom147_1-1655199149532.png

 

0 Kudos
Message 7 of 9
(2,142 Views)
Solution
Accepted by topic author Tom147

2. When you use DAQmx Logging, you can't *directly* add other info to the file (such as a channel representing time).  However, the file will already contain the info you need -- the timestamp at the start of acquisition and the dt interval between samples.  The Excel plugin puts this in the first worksheet.

 

3. You can right-click a graph and choose Export from the menu to get some easy built-in options for saving graph data.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 8 of 9
(2,132 Views)

 @ thanks for your help!!

0 Kudos
Message 9 of 9
(2,110 Views)