Timing BUG in 'DAQmx Read(Analog 2D DBL NChan NSamp).vi'?

[latenighter]

For an inexplicable reason, I'm getting an incorrect sampling delta when I read with the 'DAQmx Read(Analog 2D DBL NChan NSamp).vi'. When reading the same data with 'DAQmx Read(Analog 1D Wfm NChan NSamp).vi', the error is not produced.

A DAQmx based test routine that compares these two vi's in action is attached. I ran this routine sampling an accelerometer attached to an NI-9234 module. The accelerometer was undergoing 100 Hz sinusoidal vibration. The results of running the routine are shown in the pdf attachment for three test cases sampling at the following rates: 10000 samples/sec, 20000 samples/sec, 30000 samples/sec. The pdf attachment also includes the Block Diagram code of the test routine.

As observed in the results on the Front Panel of the test routine, in each case, the power spectrum graph produced from the 'DAQmx Read(Analog 1D Wfm NChan NSamp).vi' data correctly shows a peak frequency of 100 Hz. Conversely, the peak frequency on the power spectrum graph produced from the 'DAQmx Read(Analog 2D DBL NChan NSamp).vi' varies, depending on the sampling rate.

Based on these results, is there a bug in the 'DAQmx Read(Analog 1D Wfm NChan NSamp).vi' routine?

[Dennis_Knutson]

The reason is very explainable. When you use 2D DBL data, you have no timing information. It's just amplitude measurements. When you use waveform data types, there is t0 and dt information in the cluster and the power spectrum function uses that. When there is no timing information provided, the dt will default to 1.

[latenighter]

<<you have no timing information...>>>

Your answer is unfortunately inadequate, but it truly may reveal a MAJOR deficiency with the way NI-DAQmx is documented, if not its careless use of generically applying timing information to a NI-DAQmx Read , without clearly revealing that the timing information is not truly passed to all types of NI-DAQmx Read's consistently.  At worse case, this is an outright BUG.

Regardless of which type of NI-DAQmx Read  is used, the timing information, including the sampling rate, is set by the NI-DAQmx Timing vi, as explained in this publication: http://zone.ni.com/devzone/cda/tut/p/id/2835, which states:
"The NI-DAQmx Timing function configures the timing for hardware-timed data acquisition operations. This includes specifying whether the operation will be continuous or finite, selecting the number of samples to acquire or generate for finite operations, and creating a buffer when needed."

The sampling rate of the acquisition is clearly mapped to the NI-DAQmx Timing vi. It is not set in the 'NI-DAQmx Read' vi's. So how does an NI-DAQmx 'READ' know what the timing sampling rate is? Through the TASK ID passed to it. Regardless of the type of NI-DAQmx 'READ', whether it is 'Wfm READ' or a '2D DBL READ', they both receive the same TASK ID. It is through the TASK ID that the 'Wfm READ' gets its dt information. That dt is established when the acquisition is started by the NI-DAQmx Start Task .

In my sample routine, prior to determining the frequency spectrum of the acquired 2D DBL data, I assembled it into a waveform with the 'Build Waveform' function found on the waveform palette.  The dt I used in building this waveform was the inverse of the sampling rate at which the data was supposedly acquired. Nonetheless, the resultant spectrum was erroneous.

Therefore, even though timing information, including the sampling rate of acquired data, is explicitly set in the NI-DAQmx Timing  , it is nonetheless apparently not sampled according to that information, depending upon how the data is eventually read.  If that is indeed the case, then the documentation certainly lacks in making that clear. 

[RavensFan]

I'm happy to see you marked Dennis' reply as the solution.  Perhaps he could have written a longer reply, but I disagree that is reply is inadequate.  And even more so disagree that there is a bug in the DAQmx Read VI's.

You are confusing data types with the the kinds of data they contain.  The DAQmx Read VI knows what the timing information is because it gets the purple DAQmx task wire.  That wire is a reference to the task and the DAQmx Read looks up the data.

Now when you get the data out of the Read, you can request a Waveform type of data.  That is just a special cluster that contains an array of Y values, a T0 start time and a dt sampling interval time.  Great.

But when you request an array of doubles, where do you expect to get the sampling data.  An array is just raw data.  It doesn't have any timing information built into it.  Nor should it.  An array is a basic programming construction that is used in far more instances then just the special case where it comes out of a data acquisition VI.

[Dennis_Knutson]

The different data types in LabVIEW are fully and completely documented. It is your choice as a programmer to decide which type of data you want the function to return. The format of the data returned has no bearing on the setting of the DAQmx read timing. Whether you return waveform data, DBL, or unsigned, the acquisition is identical. I don't have the sound and vibration toolkit so I can't immediately explain why your spectrums are different. Set a breakpoint on each and look at the waveform data being passed to each.

edit: I think I see your mistake. It's in the for loop. The autoindex function of a for loop will index row by row. The 2D DBL format returns each row as a single scan and a column is a channel. Try doing a Transpose 2D Array before the data enters the for loop.

Message Edited by Dennis Knutson on 03-07-2009 05:40 PM

[latenighter]

<<I'm happy to see you marked Dennis' reply as the solution.>>

If I did so, it was a mistake. He did not, in my opinion, provide a solution.

<<But when you request an array of doubles, where do you expect to get the sampling data.>>

You are confusing the semantics terminology when you say "sampling data". The documentation states that the data will be sampled at a rate set according to the Sample Clock. I quote:

"For operations that require sample timing (analog input, analog output, and counter), the Sample Clock instance of the NI-DAQmx Timing function sets both the source of the sample clock, which could be an internal or external source, and its rate."

To be clear, in the routine I attached to this thread, I used the 'Sample Clock' instance of the polymorphic NI-DAQmx Timing vi. Furthermore, the rate input in the 'Sample Clock' instance of the polymorphic NI-DAQmx Timing vi is explained in the LabView help literature as follows:

rate...specifies the sampling rate in samples per channel per second.

<<"But when you request an array of doubles, where do you expect to get the sampling data.">>

Again, you are messing up the terminology with the phrase "sampling data". Your question can be rephrased more explicitly as follows:

(Q1) "When you read an array of data from a DAQmx task, what rate was it sampled at?"

(A1) According to the NI literature, the data was sampled according to the rate mapped to the 'Sample Clock' in the NI-DAQmx Timing. According to the dataflow paradigm, the acquisition of the data, at the rate previously specified in the NI-DAQmx Timing , is initiated with the NI-DAQmx Start Task , which occurs prior to the NI-DAQmx Read . This is clearly explained in NI-DAQmx Start Task explanation (cited here http://zone.ni.com/devzone/cda/tut/p/id/2835#toc5) which reads:

"The NI-DAQmx Start Task function explicitly transitions a task to the running state. In the running state, the task performs the specified acquisition or generation. ...using the NI-DAQmx Start Task function to explicitly start a task involving a hardware-timed acquisition or generation is preferred."

Again to be clear, my routine attached to this thread includes an NI-DAQmx Start Task prior to the NI-DAQmx Read .

<<An array is a basic programming construction that is used in far more instances then just the special case where it comes out of a data acquisition VI.>>

And consequently, that is why one may wish to read the sampled data in either waveform format, or in array format.  But, as stated earlier, if we want to later assemble that array into waveform, we can use the 'Build Waveform' function on the Waveform Pallete.

(Q2) "In using the 'Build Waveform' function, what dt value should be applied?"

(A2) It should be the inverse of the rate at which the data was supposedly sampled at.

Based on the explanatory information that NI has provided for the LabView DAQmx routines, which I have provided in this thread, we can only conclude that the sampling rate, for some inexplicable reason, is not being properly set, depending on how the data is read later, which therefore appears to be a BUG.

[latenighter]

<<I don't have the sound and vibration toolkit so I can't immediately explain why your spectrums are different.>>

As an alternative, if in possession of the 'Full Development System', one can substitute 'FFT Power Spectrum VI' in place of the 'SFA Power Spectrum VI'.  I've done so, and it is attached.

<<"edit: I think I see your mistake. It's in the for loop. The auctioned function of a for loop will index row by row. The 2D DBL format returns each row as a single scan and a column is a channel. Try doing a Transpose 2D Array before the data enters the for loop.>>

Intuitively, I suspected this would not work, since my g levels and power levels appeared to be correctly plotted previously (albeit with the incorrect dt as discussed above) .  I went ahead and confirmed that; inserting the 'Transpose 2D Array' function before the data enters the loop produces worse (unplottable) results.

I do appreciate you taking the time to try and address this issue.

Message Edited by latenighter on 03-07-2009 08:34 PM

Message Edited by latenighter on 03-07-2009 08:35 PM

Message Edited by latenighter on 03-07-2009 08:35 PM

[Dennis_Knutson]

With simulated data, I see no differences in the spectrums except for the differences caused by two different sets of samples. Instead of a pdf, why don't you post the VI with data saved with it?

[Mcdan]

latenighter,

I think the issue you are seeing here is a combination of two things.  First, as Dennis suggested, the waveform data type contains sample timing information.  This timing information comes from a *verified* DAQmx task. Second, if you look at the specifications for the 9234 under the heading "Understanding NI USB-9234 Data Rates" you'll see that the device can be programmed to one of 31 sample rates.  Using the device's internal timebase, those rates are defined by the following equation:

Sample Frequency = (13.1072e6 / 256) / n   where n = integers from 1 to 31. 

Due to the discrete set of possible sampling frequencies available on this device, DAQmx must decide what to do if the sample rate you request in the DAQmx Timing.vi does not match one of the supported rates on your device.  To error is not practical, as many devices' sample clocks are derived by dividing down some other clock, resulting in a discrete set of possible sampling frequencies.  Therefore, DAQmx will coerce the value to the nearest possible sample clock frequency which is at least as fast as the requested frequency.  This coerced value is used for the 'dt' element of the waveform data type.  If you don't choose to use the waveform data type, the way you can get this information is to query this property back after the task has been verified.  DAQmx Control Task.vi can be used to explicitly verify the task, though simply querying the attribute should be sufficient to cause DAQmx to verify the task.  To query the attribute, drop the DAQmx Timing Property node, and read back the Sample Clock->Rate property.  If you base your calculations on this coerced sample rate, I believe you'll see the same results as when using the waveform versions of DAQmx Read.

Hope this helps,

Dan