Reading unscaled, calibrated AI values from M series cards in DAQmx using ANSI C

[Larry X]

How do I create an AI channel to read unscaled values (raw binary sample values) in DAQmx, using the ANSI C APIs?  All the DAQmxCreateAIXXXChan functions appear to imply scaled units.  I know what the calls are to do the actual read of unscaled values, e.g. DAQmxReadBinaryI16, but how do I create an unscaled channel in the first place?

Also, the documentation says that if I'm reading from an M series card, I have to read scaled values in order for calibration to be applied, whereas E series cards still return calibrated unscaled values in DAQmx, as in Traditional NIDAQ.  Is there no way to read calibrated unscaled device values from an M series card?  Please tell me that I don't have to read 64 bit floating point values from a card with a 12 or 16 bit A/D and then convert them back to 16 bit integers myself to get calibrated values.

Thanks,

Larry

[Aaron_W.]

Larry,

Thank you for posting on the NI Forums. Unfortunately, there is no way with the M-Series to get unscaled, calibrated data. This is because the scaling and the calibration both happen together in software. You are performing the correct calls with the DAQmxReadBinaryI16, but as far as creating an unscaled channel there is no such thing. You must just create a channel and then use the DAQmxReadBinary function call to get the unscaled data. Is there a specific reason why you need an unscaled, calibrated representation of your data? 

[Larry X]

There are two reasons why I need unscaled integer sample values.  The first is that I am converting a legacy app which uses 16 bit integers, and it would require massive amounts of rewriting and break our public APIs to convert it to use 64 bit double precision floating point values throughout.  The other is that it's simply a waste of memory, bandwidth, and file space to use a 64 bit floating point value to store what is actually a 12 or 16 bit integer sample value (even an 18 or 24 bit sample value could be stored as a 32 bit int or float -- why were 64 bit doubles chosen?).  For example, recording 64 channels of 16 bit A/D samples at a 40 kHz sampling rate requires approx 5 MB/sec, whereas 64 bit doubles use 20 MB/sec.  Our recording files would become four times as large, to maintain the same accuracy as with Traditional NIDAQ and E series cards.  So in order to avoid this, we will have to read F64 and then perform a multiply and a double-to-int conversion on each sample so that we can save it as a 16 bit integer.  Ugh!

Thanks,

Larry

[Brad_K]

Hi Larry,

If your application logs unscaled values to disk, then converts them to floating point when they are read from disk, it is definitely possible to make this work with devices that use software calibration (like M Series and SCXI), provided that you can save some additional data. Use the function DAQmxGetAIDevScalingCoeff() for each channel to retrieve the device scaling coefficients (which take software calibration into account), and save the coefficients to disk in addition to the unscaled data. When you read the unscaled data, apply the scaling coefficients to get calibrated floating point values. More information about this is available in How Do I Dynamically Choose the Size of an Array to be Passed to a NI-DAQmx C Function? and Is DAQmx Raw Data Calibrated and/or Scaled? There are also some DAQmx shipping examples written in LabVIEW that demonstrate this (Cont Acq&Graph Voltage - Write Unscaled Data to File (TDMS).vi and Cont Acq&Graph Voltage - Graph Unscaled Data from File (TDMS).vi), but these don't appear to have been ported to C.

If your application processes unscaled directly using integer math, converting scaled values to integers or to single-precision floating point numbers might be your best bet. (Edit: oops, single-precision floating point wouldn't help you here.)

You don't have to create an unscaled channel (and indeed, there is no way to do that). Any AI channel can be used to read scaled or unscaled data.

The reasons that M Series uses software calibration are described in New NI-MCal Calibration Methodology Improves Measurement Accuracy: using third-order polynomials allows DAQmx to correct for ADC non-linearity, and the hardware calibration correction circuitry on E Series doesn't allow different gains to use separate calibration constants in the same acquisition (since the amplifier and calibration circuitry are shared between all channels).

If you have suggestions regarding additional data formats for DAQmx read functions, I recommend going to ni.com, clicking on "Contact NI" at the top right corner, and clicking "feedback" to file a product suggestion.The more requests we get for a certain feature, the more likely we are to implement it.

Brad

Message Edited by Brad K on 01-16-2009 05:08 PM

[Larry X]

Thanks Brad -- I was just about to ask if there was any way to retrieve the calibration coefficients.  That's very useful information.