Clarifying unscaled analog read API

[dmorris]

I'm using a USB-6009, and I'd like to read integer data right off of the device using the NI-DAQmx C API.  I understand that this bypasses the scaling and offset that is applied when doing floating-point reads.

Ideally, I'd like to read signed, 16-bit data, so I'm using:

DAQmxReadBinaryI16

But I'm a little confused about the way the documentation around this function is structured... it says:

DAQmxReadBinaryI16

"Reads multiple unscaled, signed 16-bit integer samples from a task that contains one or more analog input channels."

When I click on "unscaled", the docs say:

"Unscaled data is in the native format of the device, read directly from the device or buffer without scaling. The native format of a device can be an 8-, 16-, or 32-bit integer, signed or unsigned."

So does that mean that no matter whether I call DAQmxReadBinaryI16, DAQmxReadBinaryU16, DAQmxReadBinaryI32, or DAQmxReadBinaryU32, I get the exact same bits, and only one of them is meaningful?  I.e., do I have to pick the function corresponding to the native format of the device?  If so, how can I find the native format (it doesn't appear to be in the device manual)?

Also, what does setting the minimum and maximum voltage range (in my case using DAQmxCreateAIVoltageChan) do when reading unscaled integer data?  Is the relevant range of integer values scaled into this range?  I.e., if I set the voltage range to [-2,2], and I call DAQmxReadBinaryU16, should I expect a value of 0 to correspond to -2V, and a value of (2^16 - 1) to correspond to +2V?  (I know this scaling may be non-linear, and that's what I'm losing out on by not using a floating-point read.)

Thanks!

-Dan

[enderWiggin10]

Hi Mark,

For the second part of your question, a couple of good search terms are "raw data" and "interleaving" in DAQmx help or DAQmx C Reference help.  The raw data help file explains the following:

If you use a different integer size than the native format of the device, one integer can contain multiple samples or one sample can stretch across multiple integers. For example, if you use 32-bit integers, but the device uses 8-bit samples, one integer contains up to four samples. If you use 8-bit integers, but the device uses 16-bit samples, a sample might require two integers. This behavior varies from device to device. Refer to your device documentation for more information.

However, for the first part and latter part of your question you are desiring 16-bit data from your analog input.  With that said, your USB-6009 has 14-bit Analog Input.  Therefore you have 14-bits of resolution on your ADC.  The most typical way that our DAQ hardware works is that you set the input range and then it is coerced to the next higher actual range possible on the card, and then the input is cut-off at that voltage level and the signal is amplified using an onboard amplifier to maximize the resolution.  This is because the ADC is typically set to receive a -10 to +10V signal.  Therefore, you will not sacrifice resolution of your reading by lowering the input range, provided that the range is an actual set rage for the hardware.  You can view the detailed specifications of the 6009 here: http://www.ni.com/pdf/manuals/371303l.pdf  I will have to look into the details of how to interpret the integer binary data, and what the native data format is for the USB 6009, because it is not evident form the manual.

Best,

Adam F

[dmorris]

This is helpful, thanks.  I had been wondering about the relationship between the (continuous) voltage ranges specified in channel creation and the (discrete) voltage ranges allowed by the device.  I expected - but wasn't sure - that it was rounding the voltage range up and doing a hardware select among the available amplification/ADC levels (8 different levels in the case of the 6009 in differential mode).

Basically what I'm getting from the first part is that any time you want to read non-floating-point data from a device, you can call whichever integer-read function you want, but you get the same bits back regardless, and it's probably best to treat it conceptually as a void* and cast to the native device format (which I also couldn't find in the manual).  Seems like an odd way to structure the API, but it will work fine so long as the native format is documented somewhere.

Let me know if you find the native format of the device... thanks!

-Dan

[enderWiggin10]

Good morning Dan,

A little bit of clarification on the bit representation of the data:  If the card is a 14-bit card, such as the USB-6009, you will read in a 16-bit signed integer value where the two Least Significant Bits will be irrelevant to the actual reading.

As for the rest of the post, it might be best to understand more of your application.  It is possible that it could be in your best interest to read in the scaled and calibrated floating point values and then convert the data to a signed integer value.  Can you please describe your application in a little more detail?  Would it be possible to read in floating point values and convert back to binary integers?

Best,

Message Edited by cyclone2k9 on 04-06-2010 10:24 AM

Message Edited by cyclone2k9 on 04-06-2010 10:25 AM

[enderWiggin10 · Accepted solution]

Hi Dan,

If you are reading the unscaled binary data, you can then apply the calibration constants applied to the card after calibration using a DAQmx Channel Property Node.  Configure the property node as follows: Analog Input»General Properties»Advanced»Device Scaling Coefficients»Device Scaling Coefficients.  You can then input these value to an array indicator or use them as described in a the knowledgebase article.

Here is the KnowledgeBase article that explains how to interpret the unscaled data and scale it and calibrate it accordingly.

Best, 

[dmorris]

Thanks!  NI's responsiveness on the forum has been amazing, BTW.

Yes, I can probably use floating-point values.  I would guess there's some performance cost associated with this that does start to add up, but for now I can work with that.

Primarily I just wanted to understand the transformations happening to my data, since (as discussed in another thread) I'm seeing some artifacts, and without getting at (relatively) raw data, it's hard for me to debug.  First and foremost, I'm seeing a DC offset on some channels and it's hard to disambiguate problematic calibration from problematic ADC readings unless I take a look at the raw data.

But you've given me plenty of information to work with; I think I can replicate the transformation now and directly compare both performance and offset calibration.

Thanks!

-Dan

dan@microsoft.com

http://research.microsoft.com/users/dan

[enderWiggin10]

Hi Dan,

I am glad to hear that everything is up and running for you and that we were able to help out.  Thank you for using the NI Discussion Forums, and do not hesitate to post a new question/thread in future if necessary.  Best wishes with the rest of your application, and have a nice rest of the day.

Best,