Measurement Studio for VC++

cancel
Showing results for 
Search instead for 
Did you mean: 

Raw data format for DAQ

Hi,

 

I hope this is the right location for putting this post. If not, please let me know a more appropriate place. I am trying to read raw analog sample data using ANSI C and would appreciate if someone could clear up some questions I have after reading the documentation for NI-DAQmx (NI-DAQmx C Reference Help). To read from the card's buffer, I need to allocate a buffer, and for that I need to know the size of the samples for each scan. It appears that this is done with DAQmxGetReadRawDataWidth(), and that as each measurement is added to a task with DAQmxCreateAIVoltageChan(), the width will get larger. Is this correct? If not, how is the data width found? I would like to allocate everything before starting to add measurements to the channel, so I would also like to know if there is any way to find the width for an arbitrary card without first adding the measurements.

 

The data is read from the DAQ cards buffer using DAQmxReadRaw(). The documentation for this function states, “Refer to the specifications for your device to determine the format of the incoming samples.” The current cards of interest are E-series (although I would like to write code that will also handle others), so I looked in their manual (http://digital.ni.com/manuals.nsf/websearch/1A2B0F938B5B895086257BEB006FE5BEI) and in family specifications for the specific cards. I did not see the format in these and would like to know where it is located.

 

It appears that by using DAQmxReadRaw(), I will be making an identical copy of the data in the card's buffer. Would it be possible to directly work with the original data to avoid the copy? Thanks for any information.

 

Jim

 

0 Kudos
Message 1 of 10
(5,795 Views)

Hi Jim,

 

It looks like the link in your post is dead. Which cards are you currently looking at using?

Tom D.
Staff Software Engineer
NI
0 Kudos
Message 2 of 10
(5,765 Views)

Sorry about the bad link. I thought I had worked when I tested it. Maybe something was cached. I am using two E-series cards, a PCI-6031E and a PCI-6071E. Regarding my original post, by testing, I did find that the data width as returned by DAQmxGetReadRawDataWidth() does grow as each new measurement channel is added. I was a bit surprised to find that the 6071 uses 2 bytes per channel despite having a 12-bit A/D. I had thought it would compact each 2 channels (24 bits) into 3 bytes.

 

Jim

0 Kudos
Message 3 of 10
(5,762 Views)

Hi Jim,

 

No worries! All I'm seeing in the spec sheet for the 6301E is the size of the FIFO buffer used to read samples (512 samples). So I would think that you'd have to be reading into a buffer that was at least 512 samples for each channel. One of DAQmxReadRaw()'s outputs is an int32 called numBytesPerSample, so that should tell you how many bytes to reserve for each sample.

Tom D.
Staff Software Engineer
NI
0 Kudos
Message 4 of 10
(5,745 Views)

Hi,

 

Thanks for the reply. I had seen that the size of the internal buffer is 512. As an application that information does not seem particularly useful since as far as I have read, we have no access to the internal buffer. My understanding is that when DAQmxCfgSampClkTiming() is called, the size of the buffer that is used to save the contents of the internal 512-byte buffer uses is set and that buffer is the one that is used for reading by an application. Is this incorrect? Also, is there a way to avoid this triple-buffering of data (internal 512-byte buffer, internal allocated buffer, application read buffer)?

 

DAQmxReadRaw() documentation does not have any restrictions on numSampsPerChan. I believe as long as you are keeping up (for continuous sampling), you can read as few or as many samples as you want per read.

 

numBytesPerSample is the width of the entire sample with all of the measurements of a single scan. I have confirmed that by testing. But I did not see any documentation on the ordering of the data returned. Is it ordered by order of adding channels, by enumerated order of channels, grouped into blocks of measurements per channel and ordered by one of the earlier methods, or is it something else? Is the ordering the same for all cards? If so, why does the documentation to DAQmxReadRaw() state "Refer to the specifications for your device to determine the format of the incoming samples?"

0 Kudos
Message 5 of 10
(5,738 Views)

Hi Jim,

 

You can avoid the triple-buffering of data by using direct memory access (DMA). Many of the E-series cards support DMA. You can read more about it here: http://digital.ni.com/public.nsf/allkb/E396FCBFFEB3297586256F660074B63C.

 

As for your second question, is there any reason you can't read the data using one of the other DAQmx read functions instead of DAQmxReadRaw()? The read functions can be found here in the help: http://zone.ni.com/reference/en-XX/help/370471W-01/TOC20.htm.

Tom D.
Staff Software Engineer
NI
0 Kudos
Message 6 of 10
(5,709 Views)

Hi Tom,

 

I read the web page at your first link, but I did not see any way to directly control the DMA transfers. I had assumed that the DMAs are being used to transfer from the internal card buffer to the memory allocated by the card and from this memory to the application memory. Is there an API function to directly move data from the internal buffer to an application buffer using DMA transfers? The alternative would be an API function to return the address and length of the data to process in the buffer allocated by the card in the computer's RAM. Is there any such function available?

 

I wanted to use the raw reads for performance reasons. They allow block copies of the data from one buffer to another, and while that is not as good as avoiding the copy altogether, it is better than copying in small pieces to reorganize or transform the data as the other read methods might do. Of course, I do need to know what the format of the data is when I start using it, which is why I asked my original question.

 

Jim

0 Kudos
Message 7 of 10
(5,697 Views)

Hi Jim,

 

It appears that 12-bit resolution devices will return a 16-bit integer with the 4 MSB's being 0. 16-bit devices will obviously return a 16-bit integer. 

 

I hope that help!

 

Regards,

 

Kevin

Applications Engineer

National Instruments

0 Kudos
Message 8 of 10
(5,667 Views)

I had found  through experimenting that the width of the data is 16 bits despite the fact that the resolution is only 12 bits on the PCI-6071E. But is there documentation describing the organization of the individual measurements among themselves for any card as referred to in the description of DAQmxReadRaw()?

 

Jim

0 Kudos
Message 9 of 10
(5,653 Views)

Hey Jim,

 

Unfortuantely, I cannot find any public facing documentation that decribes the raw data format for specific cards. The closest documentation I can find is http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/rawdata/ which describes the Raw Data in general returned by DAQmxReadRaw.

 

In general, E-Series cards which are 12 or 16-bit resolution will return a 16-bit integer. Other series cards which have up to 24-bit resolution will return a 24-bit integer.

 

I'm sorry I couldn't better answer your question, but I hope this helps for your specific application!

 

Regards, 

 

Kevin

Applications Engineer 

National Instruments 

0 Kudos
Message 10 of 10
(5,633 Views)