Fixed Point Data

[JLewis · Accepted solution]

Hi nos,

The fixed-point type is not directly configurable from the node, but you are free to discard or round off bits you don't need. The type was chosen to be compatible with several different modules, including I think 24-bit modules.

Although it seems intuitive that you would need only 16 bits to represent 16-bit ADC data, you actually need more than that. Part of the reason is dynamic range expansion (ie, you are now representing +-16 V even though the ADC full range is +-10 V) and part is due to the error in resolution introduced by the scaling operations. The raw data is perfectly scaled such that 1 LSB is the resolution of the converter, but with the scaled data each bit pattern doesn't map exacly to an ADC code.

That's a poor explanation, but the bottom line is that to meet the hardware specs you'll need to retain conservatively 20 bits. To do this, use a To Fixed-Point conversion function at the output of the IO node, configured to <s,20,5>. If you application's accuracy requirements aren't that stringent, you can also try converting to <s,16,5>, recognizing that you have degraded the accuracy of your ADC data somewhat.

Jim

[srm@viewpointusa.com]

your interpretation of the fixed point representation is correct.  I believe the reason is to handle the multiple ranges of the A/D

without changes to the 26.5 type.  the module is capable of +-10 down to +- .2 V over 16 bits. at the higher range, a resolution

of 6 uV would be required. even so, the 26.5 seems excessive.  the setting of 26.5 is not selectable.  your subsequent use of

the fxp number is, however.  You may want to convert to fxp yourself.

[nos]

Jim / Stu,

Thank you both for your messages, which have finally brought my original query to a conclusion.

It seems to me that the simplest approach for me to adopt is to leave the sampled data as I16 on both the FPGA and RT targets and  convert directly to engineering units when the data has been transferred to the Windows PC.

In addition,  this quite lengthy thread, which began on 11 March, has made me aware of the difficulty of finding basic technical information in either the Labview Help or the NI website. For example, I have not been able to find in either of these resources something that clearly says "The fixed-point type is not directly configurable from the node", as Jim does in the first line of his message.

It seems to me that NI assume that other users will go to the trouble to supply information that NI itself should really be providing.

Best regards,

nos

[srm@viewpointusa.com]

There is an example showing how to convert to engineering units in the example directory for this module.  there are linearization coeffs that I would assume are unique to the module.  I do not know how much of a compensation these are providing.  If you do the conversion in windows, you will need to read these coeffs in RT and send them to windows as well.  If you don't need to worry about the compensation, a gross conversion is easy to do.

NI, what does the compensation provide in terms of system accuracy? does it go from .1% to .01%?

[Coq_Rouge]

I think it took some time to find the answer because you were somewhat imprecise then you asked your question. And also not aware about the inherent inaccuracy then using floating point numbers. That is the reason why it is not advisable to use do an exact compare then using floating point numbers (A=B). For instance a a multiplication between two number may give the result 1.00000000000001 then the expected result was 1.0. But in a compare 1.00000000000001 is NOT equal 1.0

Also remember then working with A/D and D/A conversion the accuracy is given by the converter unit. Not the number format used then expressing the result. You may downgrade the accuracy by rounding off digits. But you can never increase the accuracy by simply showing more digits behind the decimal point

[nos]

Thank you for your message but I do not agree that the length of time it took to find an answer was due to some imprecision in my original query.

The original question was "Is it possible to specify the word and integer length for the fixed point data format and if so where is this done?" which seems to me to be a straightforward question.

Best regards,

nos

[subir]

this thread was interesting to me, as i am a beginner and nos's questions pointed to a general query that one will have at somepoint, while using LView. As i understand, i will do a short summery..please correct me

I am using NI 9205 and it has the fxp representation <s,26,5>..now although the max o/p is +-10V, the integer bits of 5 make it possible to obtain 16 V..however, the theory explains what is important (http://zone.ni.com/devzone/cda/pub/p/id/303)

of the 5 integer bits, the 1st one is to indicate the sign + or -..now we are left with 4 bits, which can deliver a maximum of 15.0 V as the decimal output..the rest of 26-5=21 bits indicate the precision in the digits after the decimal, i.e., 1/2^21 = 0.477 microV. 

now, if one decides to use 4 bits instead of 5 for the integer, one would be left with only 3 real bits indicating the leading digits ( the 'V' digits) and will be equal to max of +-7V..no one would want that, so we must stick to 5 bits for the integer..now the question of the remaining 21 bits for the mantissa. if you calculate the raw o/p, then we will have 1/(2^15)= 30.5 microV resolution..so there is no way we can achieve a resolution of 0.477 microV..hence we can decrease the overall number of mantissa bits to 15 which would correspond to the hardware, and also reduce the computation load on the FPGA.

when u decide if conversion from <s,26,5> to <s,20,5> is good, then just place a "to fixed-point" icon after the output of input node and change it..i use fifo to transfer data, so i configured FIFO accordingly..

anyone with any corrections, suggestions regarding the above summery? 

[Pete.Dunc]

Hi Subir,

I would recommend that you open a new thread for your query - referencing this one as similar.  Although a brief read what you have explained seems perfectly reasonable.