Datasheet Question

Randy Yates <yates@digitalsignallabs.com> wrote:
> Mauritz Jameson <mjames2393@gmail.com> writes:
>>> Where did these two equations come from?

>> The two equations come from me. They're an expression of how I think
>> the conversion scheme described in the PDF (section 7.2.1) is supposed
>> to be interpreted. Either the 2 bytes represent a Q2.12 number of they
>> represent a Q1.13 number. I'm leaning towards Q2.12 but I'm not sure..
 
> It's a Q2.12 (note I would denote this as an A(1, 12)). The maximum
> positive scaled (unscaled) value is 2 - 1/4096 (8191), and the minimum
> negative scaled (unscaled) value is -2 (-8192).
 
> To get the scaled value x from the unscaled value X, 
> divide by 2^12 = 4096:

But the original question is how to make a decimal fraction
out of it.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Randy Yates <yates@digitalsignallabs.com> wrote:
>> Mauritz Jameson <mjames2393@gmail.com> writes:
>>>> Where did these two equations come from?
>
>>> The two equations come from me. They're an expression of how I think
>>> the conversion scheme described in the PDF (section 7.2.1) is supposed
>>> to be interpreted. Either the 2 bytes represent a Q2.12 number of they
>>> represent a Q1.13 number. I'm leaning towards Q2.12 but I'm not sure..
>  
>> It's a Q2.12 (note I would denote this as an A(1, 12)). The maximum
>> positive scaled (unscaled) value is 2 - 1/4096 (8191), and the minimum
>> negative scaled (unscaled) value is -2 (-8192).
>  
>> To get the scaled value x from the unscaled value X, 
>> divide by 2^12 = 4096:
>
> But the original question is how to make a decimal fraction
> out of it.

You mean with a computer program (as opposed to, e.g., on your
calculator)? Wouldn't

  double DecimalFraction(int16_t x) 
  {
    return x / 4096.0;
  }

do it (where x is the Q2.12 input value)?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

>> Where did these two equations come from?
>> 
>
>
>The two equations come from me. They're an expression of how I think the
>conversion scheme described in the PDF (section 7.2.1) is supposed to be
>interpreted. Either the 2 bytes represent a Q2.12 number of they
represent a
>Q1.13 number. I'm leaning towards Q2.12 but I'm not sure..

the end of section 7.2.3 shows some c code of how to do it on this
device.
checks the sign, checks if integer bit is set, shift fraction bits to left
justified, then checks each fraction bit and increments the sum with those
macros. The code is missing for outputting the fraction sum, I guess it
can be done by splitting the nibbles from the word sum into bytes a,b and
c , checking for leading zeros (as shown), then using the nibble out
routine for a,b,c. By the way the q is 1.12 for signed g2 mode, one
integer bit, and 12 fractional bits. typically a q12 signed would be 3,12
on 16 bit since you have 3 integer bits and 12 fractional bits, but since
you only have 14 bits its different from the norm.   
---------------------------------------
Posted through http://www.DSPRelated.com

Randy Yates <yates@digitalsignallabs.com> wrote:
 
(snip)  
>>> It's a Q2.12 (note I would denote this as an A(1, 12)). The maximum
>>> positive scaled (unscaled) value is 2 - 1/4096 (8191), and the minimum
>>> negative scaled (unscaled) value is -2 (-8192).
  
>>> To get the scaled value x from the unscaled value X, 
>>> divide by 2^12 = 4096:

>> But the original question is how to make a decimal fraction
>> out of it.
 
> You mean with a computer program (as opposed to, e.g., on your
> calculator)? 

Yes.

> Wouldn't
 
>  double DecimalFraction(int16_t x) 
>  {
>    return x / 4096.0;
>  }
 
> do it (where x is the Q2.12 input value)?

That converts, at least on most machines, to a binary floating
point value.

For machines supporting IEEE 754-2008, that could be decimal
float, but usually I expect to convert to fixed decimal.

Since 12 bits are about four decimal digits, you might convert
to a fixed point decimal value with four digits after the decimal
point.

If you mulitiply x by 10000, then divide by 4096, you have
the integer value of 1/10000ths (truncated) of the quantity in x.

For a more common example, multiply x by 100, integer divide by 4096, 
and if X is in dollars and binary fractions of dollars, you get the
value as an integer number of cents. Add 2048 before the divide
to get the rounded up value.

   int x,y
   x=123456;  /* that is 123456/4096ths */
   y=(x*100)/4096;
   printf("%d.%02d\n",y/100, y%100);

Analogous to the Q2.13 form, the y value has two decimal digits
after the decimal point, even when stored as a binary value.

(PL/I would call it FIXED DECIMAL(5,2), where X might 
be FIXED BIN(15,12)).

-- glen

So do everybody agree that the PDF states that the 2 bytes together form a Q2.12 number and *this*:

double x = ((double) ((((int16_t)(MSB << 8)) | LSB) >> 2)) / 4096.0; 

is how the two bytes should be interpreted (as a double value) ?

(I guess I'm having a hard time asking the right question)

> routine for a,b,c. By the way the q is 1.12 for signed g2 mode, one
> integer bit, and 12 fractional bits. typically a q12 signed would be 3,12
> on 16 bit since you have 3 integer bits and 12 fractional bits, but since
> you only have 14 bits its different from the norm.   

Table 13 (Full Scale Value with Corresponding Integer Bits and Fraction Bits) om page 11 states that bit 0 to 11 are fractional bits and bit 13 is the sign bit. Furthermore, it is also stated that "Bit 12 is the only bit that will contribute to an integer value of either 0 or 1". 

So - to me - that sounds like a Q2.12 number and not a Q1.13 number.

Mauritz Jameson <mjames2393@gmail.com> wrote:
> So do everybody agree that the PDF states that the 2 bytes together 
> form a Q2.12 number and *this*:
 
> double x = ((double) ((((int16_t)(MSB << 8)) | LSB) >> 2)) / 4096.0; 
 
> is how the two bytes should be interpreted (as a double value) ?
 
> (I guess I'm having a hard time asking the right question)

OK, why the >>2? 

Seems to me that loses the two low order bits. 
That, combined with the /4096, means 14 bits after the binary point,
only 12 of them actually get into x.

-- glen

> OK, why the >>2? 
> 
> Seems to me that loses the two low order bits. 
> That, combined with the /4096, means 14 bits after the binary point,
> only 12 of them actually get into x.
> 
> -- glen


The MSB byte has 8 bits of data where the most significant bit is the sign bit.

The LSB byte has 6 bits of data where the most significant bit of those 6 bits is placed at bit 7 (counting from 0). 

So the logic behind the C-expression is:

1. Cast MSB to a 16-bit signed value and shift it up by 8
2. OR the LSB with the result of [1]
3. Now we have a 14-bit value where the 2 least significant bits are 0 (remember that the LSB only had 6 bits of data)
4. So shift the result of [2] down by 2
5. Typecast the result of [4] to a double
6. Divide by 4096.0 (since it's a Q2.12 value)

Does it make sense?

Mauritz Jameson  <mjames2393@gmail.com> wrote:

>Table 13 (Full Scale Value with Corresponding Integer Bits and Fraction
>Bits) om page 11 states that bit 0 to 11 are fractional bits and bit 13
>is the sign bit. Furthermore, it is also stated that "Bit 12 is the only
>bit that will contribute to an integer value of either 0 or 1". 

Wow, that is brain-damaged.

Either the binary point is to the right of the MSB, or it's one
position to the right of that.  From this description, one cannot
tell which.

People need to get a grip.


Steve

Mauritz Jameson <mjames2393@gmail.com> writes:

> So do everybody agree that the PDF states that the 2 bytes together form a Q2.12 number and *this*:
>
> double x = ((double) ((((int16_t)(MSB << 8)) | LSB) >> 2)) / 4096.0; 
>
> is how the two bytes should be interpreted (as a double value) ?
>
> (I guess I'm having a hard time asking the right question)

I don't think that's right. I would say this:

  double x = ((double) ((((int16_t)(MSB << 6)) | LSB) >> 2)) / 4096.0; 

The operation above (from the datasheet) would put the most-significant
8 bits of the input into the most-significant 8 bits (15:8) of the temporary
int16_t, then the two bits 7:6 would be zero, then bits 5:0 would be the
six least-significant bits. In other words there would be a two-bit hole
in that operation - that's hosed. I think...
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com